Cyberplanetary — World Registration and Discovery

Version 0.1.0 · experimental implementation release · 2 October 2026

This document specifies the first clean-sheet registration-and-discovery exchange. It is not the retired website draft v0.1 or v0.2. Its publication identifier is https://cyberplanetary.org/protocol/registration/0.1.0/. That identifier is a proposed publication target until deployment is evidenced.

The vision is: A future where everyone has the freedom and the means to choose and shape their experiences with technology on their own terms.

The mission is: To expand human freedom and choice by lowering the cost and friction of creating experiences with technology, enabling reuse, and putting discovery in people’s hands.

1. Scope and requirement targets

This release specifies registration statements, a signed representation, world-reference construction, and catalog exchange. It does not specify world contents, cells, resident behavior, common world ontologies, economics, rendering, or application privacy policies. No catalog is compulsory. Any HTTP(S) origin can publish the artifacts; no Cyberplanetary account, naming authority, key service, or runtime is required.

The words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY have the BCP 14 meanings only when capitalized. Requirements target a publisher, registration interpreter, signature verifier, or catalog publisher, as stated. A catalog may retain material that is not interpretable under this version; retention does not constitute successful verification or a conforming registrant statement. The optional HTTP Registration profile specifies a particular submission flow. Its reference service's moderation and capacity policies are not imposed on every catalog.

The semantic basis is the supplied Cyberplanetary concept system 0.1.0 and the current mission and specification charter. This wire contract makes new, explicit engineering selections. It is not generated by converting all ontology properties into fields.

2. Meanings that remain distinct

A world is the actual or planned subject. A world registration statement is attributable information describing it. A signed registration statement is an artifact carrying a representation and signature material, not necessarily a verified artifact. A submission is received input. A catalog record belongs to a particular world catalog.

A registrant can sign before publishing or submitting. The same artifact can appear in two catalog-local records. Catalog annotations do not modify the registrant's signed statement. Receipt, verification, publication, profile support claims, reported assessments, actual conformity, demonstrated interoperability, and authorization remain different outcomes.

Roles can overlap. A key holder can describe multiple worlds. Names need not be unique or independently verified. A world need not have cells, geometry, people, entry links, or an available endpoint.

3. Representation limits and safe interpretation

C-JSON. Core JSON documents MUST use UTF-8 without a byte-order mark, duplicate object member names, isolated surrogate code points, or Unicode noncharacters. Duplicate-name detection applies after JSON string escape decoding and at every nesting level. Nesting MUST NOT exceed 32 levels. Numbers MUST be finite binary64-representable values; integers MUST lie within the inclusive range -9007199254740991 to 9007199254740991. JSON whitespace and member order are not otherwise canonicalized.

Reference byte limits are requirements of this version's signed representation: decoded protected header at most 4096 octets; decoded payload at most 65536 octets; complete flattened envelope at most 131072 octets. These bounds are intentionally unrelated to world size. Interpreters MUST reject an oversized artifact as unsupported input rather than partially interpret it. Catalogs may separately retain opaque input under local policy.

Textual field lengths below are measured in UTF-16 code units for cross-language implementation precision. Human-facing text MUST be rendered as text, not executable HTML. Core location and entry references use absolute HTTP or HTTPS URLs, at most 4096 code units, without user-information components. Interpreters MUST NOT execute, fetch, or authorize anything solely because a URL occurs in a signed statement. URL spelling is preserved; redirects and equivalent hostnames do not merge world identities.

4. World registration statement

C-STMT. The JWS payload is a JSON object with these fields:

A link requires rel (1–256 code units) and href (an HTTP(S) URL). It may include label (1–160) and mediaType (1–128). This document assigns two local relation values: entry for an optional means of encounter, and registration for an optional publication location of a signed artifact. These local values are not claims of IANA link-relation registration. Unknown relations are retained without inferred operations. Multiple entry links are permitted; their order is the registrant's order, not a ranking guarantee.

A profile support claim requires profile, the exact HTTP(S) publication identifier for a profile version, and target, either this statement's world token or an HTTP(S) identifier for a particular implementation. An optional parameters object supplies data whose meaning is defined by that profile. Core interpreters MUST NOT promote claims into findings of conformity or permissions. Unknown profile identifiers MUST be retainable without fetching them. Profile identity is exact string equality here; redirects are not an equivalence rule.

Other payload members are permitted, protected by the signature, and ignored for core behavior. They MUST NOT be interpreted as overriding core fields. New required processing semantics require a different supported format/version or an expressly adopted agreement, not an unknown descriptive extension. No critical payload convention is defined.

5. Keys and world references

C-KEY. The selected public key representation is an RFC 8037 OKP JWK with exactly three members: kty:"OKP", crv:"Ed25519", and x, the canonical unpadded base64url encoding of exactly 32 public-key octets. Private material MUST NOT occur in this JWK. No network key lookup is performed.

The SHA-256 JWK thumbprint is calculated following RFC 7638 and RFC 8037 §2: hash the UTF-8 bytes of {"crv":"Ed25519","kty":"OKP","x":"<x>"} with no spaces, exactly that member order, and no extra fields. Encode the 32-byte result in canonical unpadded base64url. The key identifier is the RFC 9278 URI prefix urn:ietf:params:oauth:jwk-thumbprint:sha-256: followed by that thumbprint.

C-ID. A world reference is the case-sensitive ASCII token cpw1.<thumbprint>.<nonce>. The thumbprint component decodes to 32 octets and the nonce to 16 octets; both use canonical unpadded base64url. The publisher SHOULD generate the nonce with a cryptographically secure random generator. The nonce is independent per newly identified world, not per revision. It is retained through registration updates.

A supported signed statement MUST use a world whose thumbprint equals the embedded verification key's computed thumbprint. This is an explicit engineering rule introduced by this release; the concept system alone did not require it. Two identical cpw1 tokens refer to the same protocol identity; comparison is exact token equality. Equal names, links, content, or key components alone do not establish the same world. One key with two different nonces identifies two worlds. Copying content does not establish a new or continued identity automatically.

This establishes a key-bound namespace, not identity proofing or authority over a named company, domain, or every resource referenced. There is no central allocator. Losing the key does not trigger recovery: a different key produces different cpw1 identities. Key rotation, revocation and automatic continuity across keys are not specified. A catalog may describe continuity as its own annotation without rewriting the prior signature.

6. Signed artifact and protected bytes

C-JWS. The representation is the flattened JWS JSON serialization from RFC 7515 §7.2.2, restricted here to one attached payload and one signature. Required envelope members are protected, payload, and signature. header and signatures MUST NOT occur. Other envelope members are ignored as unprotected data and cannot affect core interpretation or signed-tuple identity.

Each required string MUST be nonempty canonical unpadded base64url: no whitespace, padding, alternate alphabet or nonzero unused pad bits. Decoding followed by re-encoding MUST yield the same string. The decoded protected header MUST be a C-JSON object containing exactly:

No additional protected-header members, including crit, b64, jku, or x5u, are supported. A verifier MUST reject them as unsupported processing, not silently proceed. Detached payloads, MACs, none, encryption, multiple signatures, and other curves are outside this version.

C-BYTES. The signing input is the ASCII byte sequence protected + "." + payload, using the transmitted encoded strings verbatim. The Ed25519 signature is over those bytes using RFC 8032's pure Ed25519 procedure. Its decoded length is exactly 64 octets. Publishers MAY serialize the JSON payload in different member orders; verifiers MUST NOT reserialize or canonicalize that payload before verifying. Transforming signed JSON requires a new signature even when its interpreted values appear equivalent.

C-DIGEST. The statement digest is sha256: plus the lowercase SHA-256 hex digest of the ASCII sequence protected + "." + payload + "." + signature. It identifies the signed tuple, not a catalog record or an entire running world. Formatting or additional unprotected members of the outer JSON envelope do not change this digest. Catalogs MUST preserve the three encoded strings exactly.

HTTP publication of this envelope SHOULD use application/jose+json. Profile submission requests use application/json for their outer request object. No credential or private key is transmitted with a registration.

7. Verification

C-VERIFY. A verifier MUST enforce §3, check the supported envelope/header structure and algorithm, decode and validate the public JWK, recompute and compare kid, and verify the Ed25519 signature over the exact signing input. It then parses and validates the payload under §4 and checks the key-to-world binding under §5. It MUST distinguish a cryptographic failure from unsupported representation and from a correctly signed but structurally unsupported statement. A failed required check MUST NOT be reported as successful interpretation of this version.

A successful result concerns the bytes, key and binding checked. It establishes neither domain control nor ownership in another system, real-world organizational identity, endpoint availability, latest revision globally, valid profile claims, content acceptability, nor permission to act. HTTP transport origin and the signing key are separate evidence.

The reference browser proof utility checks signature/type/key/world binding and byte commitments; it is not the complete core structural conformance validator. The Node interpreter and schema/procedural tests cover the broader payload constraints. Implementations MUST describe their check scope accurately.

8. Revisions and replay

C-CHAIN. A publisher starts a new world at sequence 1 with previous:null. Each subsequent registration statement increments sequence by exactly one and names the preceding signed tuple digest. The key and world token do not change. A publisher MUST NOT intentionally issue two distinct successors at the same sequence for one world identity. A verifier encountering both has evidence of conflicting signed assertions, not a protocol rule selecting the more recent timestamp.

A byte-identical signed tuple is the same statement, not a fresh revision. A catalog MUST NOT imply that receipt time changes signer sequence or signed time. Independently retrieved statements may be verified without possession of every predecessor; that is signature verification, not chain-completeness or freshness proof.

The HTTP Registration profile selects strict catalog-local ordered intake: a new catalog receives sequence 1 first and then every predecessor. Other catalogs may retain out-of-order or conflicting submissions, but MUST not misrepresent them as a verified ordered chain. No cross-catalog consensus, global latest-head service, expiry of old signatures, or replay prevention for operations outside registration is specified.

Metadata locations can change in a new signed revision. This is not a migration rule for contents. A catalog can retain old statements or choose not to publish a newer one. Withdrawal from a catalog does not revoke a key or remove a world from other catalogs.

9. Catalog representation

C-CATALOG. A published catalog page is a C-JSON object containing format:"cyberplanetary.catalog/0.1", id (the catalog's HTTP(S) identifier), name (display text), records (an array), and next (an HTTP(S) URL or null). updatedAt may be a catalog-asserted timestamp or null. The optional registrationService object is interpreted under the HTTP Registration profile. Additional metadata is permitted but cannot override these meanings.

A record requires id (catalog-local HTTP(S) record identifier), catalog, submission (a catalog-local reference), receivedAt (catalog-asserted time), and disposition. The values pending, published, superseded, withdrawn, and retained describe local handling, not universal world status.

A record exposing an interpretable signed artifact contains registration with the original envelope and statement with its signed-tuple digest. Interpreters MUST recompute any digest they rely on; its presence alone is a catalog assertion. Optional source records a supplied location, not proof that the location published the artifact. Optional annotations are separately attributable catalog material. They MUST NOT be inserted into the signed payload.

A retained opaque input may instead use retained:{"encoding":"base64","mediaType":"...","data":"..."} without a registration member or successful-verification assertion. A withdrawn tombstone may expose neither content form. This core capability does not obligate the reference service to accept malformed public submissions.

Assessment annotations SHOULD identify the kind of assessment, assessor, target, method, time, and result. This release's reference catalog uses kind:"signature-verification" and result:"passed" only after C-VERIFY succeeds. It makes no profile conformity assertion. Absence of an assessment is not failure or success.

C-PAGE. A paged reader follows next only within its configured catalog scope. Pagination is not a distributed snapshot transaction. The reference service orders currently published heads by intake ordinal, uses after cursors and limits of 1–100, and offers no cross-page consistency guarantee during concurrent publication changes. Re-reading the catalog can reveal intervening updates. Exporting/importing a complete historical chain is a separate operator task. The total population of possible worlds is not limited by this paging choice.

10. Publication, policy and security

No well-known path or global resolver is allocated. A catalog or world publisher documents its chosen URL. The deployment's paths are examples, not mandatory DNS allocations. HTTPS SHOULD be used for public operation. Local HTTP publication remains supported; signature verification does not encrypt requests, hide IP addresses, or prevent a server withholding newer material.

Catalog publishers decide admission, moderation, retention, price, ordering and presentation. They MAY omit, retain, or dispute records. They MUST NOT conflate their policy decisions with a successful signature or endorsement by the protocol. Unknown profile references do not require network requests. Reference services MUST not fetch arbitrary supplied URLs during intake.

Implementers must separately address bounded parsing, storage limits, network exposure, resource exhaustion, compromised keys, misleading names, hostile links and presentation injection. A valid self-generated key is not an anti-spam credential. The supplied server has an operator-controlled publication queue, an aggregate submission limit and a retained-record cap; these are limited defenses, not protection against a determined distributed denial of service.

The reference implementation has no payment handling, user account federation, token market, external code execution, real-time world protocol, key-recovery service, or trust ranking. Selecting those features is not required to register or discover a world.

11. References and conformance evidence

Normative selected bases: BCP 14 (RFC 2119/8174); RFC 8259 and the selected interoperability constraints of RFC 7493 for JSON; RFC 4648 §5 for base64url; RFC 7515 §§2, 4, 5 and 7.2.2 for JWS; RFC 8032 §5.1 for Ed25519; RFC 8037 §§2–3 for OKP keys, as updated by RFC 9864 §2.2 for the algorithm identifier; RFC 7638 §3 for thumbprints; RFC 9278 §3 for key URIs; RFC 9110/9111 for HTTP and caching. URL syntax is the ASCII HTTP(S) subset of RFC 3986 with the stated user-information restriction. Spaces, backslashes, non-ASCII characters and malformed percent escapes are not accepted as written; publishers encode them rather than relying on browser URL repair. Supporting structural schemas use JSON Schema Draft 2020-12.

The source-selection record identifies each reference, its selected role, and project-specific decisions. Schemas cannot prove signature validity, world availability, or the truth of a claim. Cryptographic vectors, procedural tests, catalog-state tests, separate-runtime verification, and real HTTP exchanges accompany the implementation. Test results state their executed environment and limitations. Publication of this experimental release is not external certification or a general security audit.