Skip to content
Cyberplanetary

Experimental specification · 0.1.0

HTTP Registration profile

Version 0.1.0 · experimental implementation release · 2 October 2026

Profile identifier: https://cyberplanetary.org/profiles/http-registration/0.1.0/

Function and bases

This optional profile specifies how a publisher submits a signed registration to a catalog and obtains a catalog-local receipt. It profiles World Registration and Discovery 0.1.0, HTTP semantics (RFC 9110), JSON (RFC 8259 under C-JSON), and Problem Details (RFC 9457). It does not require the core to operate a live service. It preserves the distinction between submission, signature verification, publication and conformance. Operator administration is outside the interoperable profile and is documented separately for the reference implementation.

Discovery and request

H-DISCOVERY. A catalog offering this profile includes registrationService in its catalog document with href, profile exactly equal to this identifier, and policy referring to the operator's documented local admission policy. These URLs use the core HTTP(S) rules. A client MUST use the advertised endpoint rather than assume /submissions on every host. It MUST NOT send a private key or catalog-operator credential to this endpoint. The reference CLI additionally requires the service and catalog to share an origin; other implementations may support a deliberately configured different origin.

H-SUBMIT. Submit an HTTP POST with Content-Type application/json and object {"registration":<flattened JWS>,"source":<optional publication URL>}. Only these request members are defined in this profile; an endpoint MAY reject additional request members. The source is submitted metadata, not an instruction to fetch. The endpoint MUST NOT need to fetch the source, profile definitions, key URLs, or world entries to process this request. A world destination need not exist or be online.

This version's reference service requires C-VERIFY to succeed before creating a normal interpreted submission/record. Other catalogs may retain rejected material separately, but MUST NOT label that retention as successful processing of H-SUBMIT. A service can require locally disclosed admission credentials or close intake. The supplied service permits unauthenticated signed submissions into a private moderation queue and does not require platform accounts.

Ordered intake and retries

H-CHAIN. For a previously unknown world, the first interpreted intake MUST be sequence 1 with previous null. Subsequently, a new distinct statement MUST extend that world's latest locally retained interpreted statement: sequence +1 and matching signed-tuple digest. The check and insertion MUST be atomic with respect to other submissions to this catalog. Timestamps are not an ordering mechanism.

H-IDEMPOTENCE. Repeating the same signed tuple MUST return the existing submission and record identity, without creating a new record or republishing a withdrawn one. This check occurs before revision-conflict processing. The original recorded source URL may be retained when duplicates supply a different source. Re-signing different payload bytes is not an idempotent retry, even when the data seems equivalent. Clients should retain the exact signed artifact and retry it after uncertain network outcomes.

A new submission returns HTTP 201; an already retained identical statement returns HTTP 200. Neither status means public listing. The response is a receipt:

FieldMeaning
formatcyberplanetary.submission-receipt/0.1
catalogCatalog identifier.
submissionStable catalog-local reference to the received submission. This may be an identifier without a public GET representation.
recordStable catalog-local record URL. A pending record may return 404 to unauthenticated readers.
statementSigned-tuple digest.
world, sequenceInterpreted world identity and signer sequence.
dispositionLocal handling, such as pending, published, superseded or withdrawn.
duplicateWhether this was an idempotent retry.

The Location response header identifies record. A recipient MUST NOT treat receipt as an endorsement or profile assessment. Local operator actions can later change disposition without changing the signed artifact.

Failures and bounds

H-ERROR. Error responses use application/problem+json with type, title, status, and a human-readable detail; the reference implementation additionally supplies a stable code. Supported categories are 400 (malformed or unsupported representation/key/type/signature), 403 (local refusal), 409 (missing predecessor, competing successor, or revision conflict), 413 (body limit), 415 (media type/encoding), 429 (temporary admission rate), 503 (service unavailable) and 507 (local retention capacity). Failed processing MUST NOT claim a new successful receipt. An explicit admission policy may select other HTTP errors. No error should echo secrets or untrusted full input.

The reference implementation accepts at most 131072 request octets, identity content encoding, and a 15-second request deadline. It rejects duplicate JSON names before interpretation. It has an aggregate rate bound and finite storage policy, neither of which establishes Sybil resistance. A 429 includes Retry-After. A publisher may retain its world offline and use another catalog if intake is refused.

Public reading and local publication

After local publication, an independent client can read the catalog and its record using the core representation and verify the preserved artifact itself. The catalog MUST keep its annotations outside the signed data. Superseded historical records may remain readable. Removing a listing is catalog-local, not a key revocation or universal deletion.

H-CORS. An endpoint claiming browser-based unauthenticated intake support MUST answer its submission endpoint's OPTIONS requests with appropriate CORS permission for POST and Content-Type. It MUST NOT require browser cookies for that unauthenticated mode. Operator actions need not and should not share that CORS policy. HTTPS is the public deployment baseline; private HTTP remains possible with the limitations documented in the core.

Reference-service policy, not universal requirements

The supplied service defaults to queueing all valid submissions. An operator bearer credential publishes or withdraws an exact record through documented administrative routes. Initial worlds use the very same intake path as later worlds. The database starts empty. No code branch recognizes the demonstration world names or keys as automatically approved.

The service does not fetch destinations during registration, process payments, issue signing keys, establish real-world identity, or perform a reputation or profile-conformance assessment. See the source's operational policy and security notes before public use.