ANTRequest's Foundation Specification (Version 0.4.0)

The ANTRequest's Foundation Specification (Version 0.4.0) Standard is a Meta Standard that defines things all other ANTRequest Standards use.

to use ANTRequest's Foundation Specification (Version 0.4.0) you can use This Specification to insure interoperability. If you do not Like where this is going please fork.

Table Of Contents

Status of this document

this document written on Sun Mar 15 2026 is Semantic version 0.4.0. this document is self-published independently.

i am still Figuring things out. this is not final design and might be vague, impossible, or otherwise not implementable. im still seeking to bring this closer to my vision.

This Specification uses external references

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Scope of The Protocol

When "All interactions" is said i mean all interactions that happen within the protocol-defined-space, whatever happens outside the protocol-defined-space is not in scope and not goverened by these Specifications.

In simpler terms (non-normative), everything that hasnt anything to do with these specifications is not goverened by these Specifications.

Global Rules

All interactions MUST follow these global rules. If these rules are violated, the Implementation MUST abort the interaction and MAY notify the user (if any).

Applications MUST NOT connect to plain HTTP, Applications MUST try to change HTTP to HTTPS.
If TLS fails or Certificate is not valid, the Edge MUST abort the connection.
when a 404 or 500 is encountered Edges MUST read the Content-Type Header, if it states text/html the Edge SHOULD ignore the body and state the feature isnt supported to the user.
Info! on shared hosting 404 or 500 with a text/html mimetype is the default response for a file missing. when a file is missing the Planet cannot properly handle this interaction
Signature Verification MUST be done using the bytes As-Is (As Received), no Normalization, Canonicalization, Encoding change, or altering is allowed.
Info! This is important due to almost all algorithms assuming the bytes havent been altered at all. swapping the keys or changing indentation of a JSON or anything else will break the signature.
Normalization and Canonicalization is complex, and difficult. by Requiring no alteration, i can save a lot of difficulties for those that dont want to. You can Pretty Print it after you verified the thing.
Most Languages and Libraries come with JSON parsers, they do not come with JSON Canonicalization Engines. Most Languages and Libraries come with cryptographic functions that work on bytes. so by not allowing JSON Canonicalization at all, i can save a lot of difficulties for those that dont want to. and again, You can Pretty Print it after you verified the thing.
Interactions MUST be in the encoding UTF-8.

Philosophy

ANTRequest's Specicications MUST follow these.

The core specifications should be minimal, stable, and widely implementable. They define the foundation, the shared rules that let everything else work together.
Everything else belongs in:
- Extensions: Optional additions that build on the core
- Forks: Divergent visions that explore different trade-offs
- Companion specs: Entirely new specifications that depend on this one
This isn't about saying "no" to features. Its about saying "that belongs elsewhere".
When considering changes, i prioritize
- Security vulnerabilities: Anything that breaks safety must be fixed.
- Ambiguities: Unclear specifications lead to incompatible implementations.
- Implementability: Specs that can't be built are useless.
Feature requests are valuable, but they usually belong in extensions or forks, not the core. This keeps the foundation stable while the ecosystem innovates.
Forks Are Features, Not Failures
A healthy ecosystem has multiple approaches. The extends mechanism exists to make forking technical and explicit.
When i say "please fork" i mean it. i will:
- Link to interesting forks from our documentation
- Celebrate divergence that explores new ideas
- Never treat forks as competition
If you need something the core doesn't provide, build it. That's how the ecosystem grows.
Features cannot be bought. Period. ANTRequest Specifications serve everyone, not just those who can pay. Forking can be done instead (which is free!).
Everything MUST work on a Standard Supported Shared Host, however i do not appease anyone who just calls themselves shared host. they must be a Standard Supported Shared Host and MUST support at least this.

Governance

Today and in all future releases as far as i know, all decisions related to the ANTRequest Specifications on this site are made by me. this might have some implications which is why Forking is built into the ANTRequest Specifications. when im gone, the dominant fork probably exists, you can move to them. but if your complaints

raise a security vulnerability?
raise an ambiguity that should have been standardized?
raise ways in how the standard became illegal to implement as written?

i will listen. if you disagree with a core decision, please fork. The extends mechanism exists for this.

Storage Supported Host

A Storage Supported Host MUST (including but not limited to)

Access to At Least 1 Actively Supported PHP Version.
Access to HTTPS. An SSL/TLS certificate is Required for this.
Access to a way to persistent data storage.
Access to the file system. readonly is reasonable but readwrite is better.
Access to a secure Cryptographically Secure Pseudo Random Number Generator.
Access to JSON parsing and writing.

Standard Supported Shared Host

A Standard Supported Shared Host MUST

With Standard Supported i mean a Shared Host that lets you use Web Standards without too much hassle

Qualify for Storage Supported Host.
Access to the database via php.
Access to the file system with readwrite permission.
Access to a way to redirect End User URLs to Actual Files (for example mod_rewrite).
Access to setting the following Headers (including but not limited to):
- HTTP Strict Transport Security.
- Cache-Control.
- All CORS Response headers.
- Content-Type.
- Content-Security-Policy.
- Content-Security-Policy-Report-Only.
- Link.
- Last-Modified.
- Set-Cookie.
- Vary.
- WWW-Authenticate.
- Custom Headers.
Access to getting the following Headers unmodified (including but not limited to):
- Authorization
- All CORS Request headers.
- Content-Type.
- Cookie.
- X-Content-Type-Options.
- Custom Headers.
Access to a secure cryptographical Library. at time of writing: including but not limited to:
- libsodium - for Ed25519 signatures and XChaCha20-Poly1305 encryption.
MUST NOT alter body bytes in transit.

Definitions

FaviSpecs
ANTRequest Specifications: The specifications on this site.
Planet: A Server Implementing is called a Planet.
Edge: A Client Implementing is called an Edge. an edge is a client that interacts with the planet. could be a browser extension, the browser, or an app.
Implementation: A software instance of an Edge or Planet or both.
The Protocol: The Protocol as set forth in This Specification.
The Specification: The Specification is this htmlpage.
/Favicond_/: The Base Path of the protocol interactions. the underscore is a MUST. this path is directly after the domain.
REQUIRE: RFC2119's REQUIRED
Edge-Defined
Planet-Defined: A feature whose specific behavior is determined by the host environment rather than this specification. While this document may provide constraints, the Planet or Edge is free to define the exact behavior within those bounds.
Edge-Approximated
Planet-Approximated: A feature whose specific behavior is determined by the host environment rather than this specification. While this document may provide constraints, the Planet or Edge is free to define the exact behavior within those bounds, but preferably reacts like the recommending an ideal behavior.

Ai Acknowledgement

Thanks to DeepSeek Gemini, Grok, and ChatGPTfor guidance writing all these specifications while proofreading (except LayerZip).