ANTRequest's PlanetSpec Specification (Version 0.0.1)

this Standard Depends on FaviDiD partially.

Feature Testing is the practice of discovering which features a Planet supports. This specification intentionally keeps feature discovery simple.

Table Of Contents

Table Of Contents

Status of this document

this document written on Sat Mar 07 2026 is Semantic version 0.0.1. this document is self-published independently.

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.

planet.json

planet.json is a file in your /Favicond_/ folder. which states some information of the planet. A valid planet.json file follows all these requirements

• At the Root Object in the JSON you MUST have a key called compat with as value an object, this object is called the compat object.
• inside the compat object, keys MUST be absolute HTTPS URLs identifying the specifications and the values MUST be objects. the objects MUST have Feature-Slugs and values MUST be booleans
• These absolute HTTPS URLs identifying the specifications SHOULD define what their Feature-Slugs mean. This Specification makes no demands for meanings.
• Each of the Feature-Slugs MUST have a boolean indicating whether the feature of that specification is supported.
• A Feature-Slug MUST match this ECMAScript flavored RegExp /^[A-Za-z0-9\-_]+$/. slugs are case-sensitive.
• URLs MUST be HTTPS URLs
• A Feature-Slug MUST NOT be
  • extends
• A Feature-Slug MUST NOT start with Favicond_.
• the URL https://antrequest.nl/standard/PlanetSpec/0.0.1/ and the Feature-Slug main MUST be listed as supported.
• An extends key where the Feature-Slugs MUST link to a specification linked in the compat object or be Omitted entirely.

A Feature-Slug is a string set forth by a Specification Linked to by the url which is the parent object's key.

Examples of PlanetSpec

{
    "compat": {
        "https://antrequest.nl/standard/PlanetSpec/0.0.1/": {
            "main": true
        },
        "https://antrequest.nl/standard/FaviDiD/0.0.1/": {
            "keygen": true,
            "auth": true,
            "newProto": false
        },
        "https://antrequest.nl/standard/FaviDiD/0.1.1/": {
            "extends": "https://antrequest.nl/standard/FaviDiD/0.0.1/",
            "newProto": true
        }
    }
}

Error Handling

Edges SHOULD attempt to do the following when parsing:

An URL is HTTP, not HTTPS.

the Edge SHOULD ignore that url and its feature slugs.

An extends URL is HTTP, not HTTPS.

the Edge SHOULD ignore that url and its feature slugs. it SHOULD also ignore any children of the extended url.

A REQUIRED feature is listed as unsupported as set forth by the Specification Linked

the Edge SHOULD do as set forth in that Linked Specification, otherwise the Edge MAY ignore the entire Specification and its Feature-Slugs.

An OPTIONAL feature is listed as unsupported as set forth by the Specification Linked

the Edge SHOULD do as set forth in that Linked Specification. otherwise the Edge SHOULD ignore the section of that Specification and not too much else and its Feature-Slugs.

a Feature-Slug is absent.

the extends Feature-Slug (key) is a boolean.

the extends Feature-Slug (key) points not to a standard listed in the compat object.

a Feature-Slug (which is not extends) is not a boolean.

ignore it, and treat it as if it was false.

the planet.json isnt valid json or it wasnt served with 200

Resolve {"compat":{}} instead, basically nothing is supported

Extendable Features

if a standard is forked (like i encourage mine to be) you might inherit features from them. which is where the extends comes in. it if a feature doesnt exist in this feature object the Edge MUST go to the extends object and look there.

Author's Notes

please tell me how i did. it was my first time writing something like this. this is self-published independently.