{ "format": "cyberplanetary/standard-release/1", "designator": "CP 0001", "title": "Cyberplanetary — World Registration and Discovery", "kind": "specification", "publisher": "Cyberplanetary", "version": "0.2.0", "released": "2026-10-04T11:01:58Z", "canonical_url": "https://cyberplanetary.org/standards/cp-0001/0.2.0/cp-0001-0.2.0.md", "canonical_sha256": "fd02ffd2f9db7e90402d5e7901f9ab48ae1fa414f45f9fa689d6bc2576ed1158", "release_digest": "4d770f21acb10c13ccc09d0a80d19a19ce8f965292965a0b836243ca3639ae89", "change_summary": "Restructure published 0.1.0 provisions as a numbered standard; correct informative demonstration names where applicable.", "source_manifest": { "format": "publication-series-manager/document/1", "work": "CP 0001", "parts": [ { "id": "contents", "role": "front", "generated": "contents" }, { "id": "introduction", "role": "front", "file": "introduction.md" }, { "id": "scope-and-requirement-targets", "role": "clause", "file": "scope-and-requirement-targets.md" }, { "id": "meanings-that-remain-distinct", "role": "clause", "file": "meanings-that-remain-distinct.md" }, { "id": "representation-limits-and-safe-interpretation", "role": "clause", "file": "representation-limits-and-safe-interpretation.md" }, { "id": "world-registration-statement", "role": "clause", "file": "world-registration-statement.md" }, { "id": "keys-and-world-references", "role": "clause", "file": "keys-and-world-references.md" }, { "id": "signed-artifact-and-protected-bytes", "role": "clause", "file": "signed-artifact-and-protected-bytes.md" }, { "id": "verification", "role": "clause", "file": "verification.md" }, { "id": "revisions-and-replay", "role": "clause", "file": "revisions-and-replay.md" }, { "id": "catalog-representation", "role": "clause", "file": "catalog-representation.md" }, { "id": "publication-policy-and-security", "role": "clause", "file": "publication-policy-and-security.md" }, { "id": "references-and-conformance-evidence", "role": "clause", "file": "references-and-conformance-evidence.md" } ] }, "document": { "format": "cyberplanetary/resolved-document/1", "work": "CP 0001", "parts": [ { "id": "part-contents", "content_markdown": "## Contents\n\n- [Introduction](#part-introduction)\n- [1 Scope and requirement targets](#clause-1)\n- [2 Meanings that remain distinct](#clause-2)\n- [3 Representation limits and safe interpretation](#clause-3)\n- [4 World registration statement](#clause-4)\n- [5 Keys and world references](#clause-5)\n- [6 Signed artifact and protected bytes](#clause-6)\n- [7 Verification](#clause-7)\n- [8 Revisions and replay](#clause-8)\n- [9 Catalog representation](#clause-9)\n- [10 Publication, policy and security](#clause-10)\n- [11 References and conformance evidence](#clause-11)\n\n" }, { "id": "part-introduction", "content_markdown": "## Introduction\n\nThis document specifies the first clean-sheet registration-and-discovery exchange. It is not the retired website draft v0.1 or v0.2. The original 0.1.0 publication identifier remains unchanged. This standard restructures the published 0.1.0 protocol text without changing its normative provisions.\n\nThe vision is: **A future where everyone has the freedom and the means to choose and shape their experiences with technology on their own terms.**\n\nThe 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.**\n\nThe preceding text was dated 2 October 2026 and is preserved at its original version URL. Its verified source is the Cyberplanetary protocol repository, commit `eae66fe9ca90f5b0398e16377a0e4cb8a4cb4da7`. This standard’s document version is distinct from the unchanged wire-format strings and exact profile claim identifiers.\n\n" }, { "id": "clause-1", "content_markdown": "## 1 Scope and requirement targets\n\nThis 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.\n\nThe 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.\n\nThe 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.\n\n" }, { "id": "clause-2", "content_markdown": "## 2 Meanings that remain distinct\n\nA **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.\n\nA 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.\n\nRoles 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.\n\n" }, { "id": "clause-3", "content_markdown": "## 3 Representation limits and safe interpretation\n\n**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.\n\nReference 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.\n\nTextual 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.\n\n" }, { "id": "clause-4", "content_markdown": "## 4 World registration statement\n\n**C-STMT.** The JWS payload is a JSON object with these fields:\n\n| Field | Requirement and interpretation |\n|---|---|\n| `format` | Required. Exactly `cyberplanetary.registration/0.1`. |\n| `world` | Required. A `cpw1` world-reference token defined in §5. This is not a newly registered URI scheme or URN namespace. |\n| `sequence` | Required. Integer 1 through 2147483647. Signer-declared revision in this world's registration chain. |\n| `previous` | Required. `null` for sequence 1; otherwise `sha256:` followed by 64 lowercase hex digits naming the preceding signed tuple ([Clause 6](#clause-6)). |\n| `issuedAt` | Required. Signer-asserted calendar timestamp in exact whole-second `YYYY-MM-DDTHH:mm:ssZ` form. Years 0000–9999; leap-second notation is not supported in this version. Not trusted time. |\n| `name` | Optional. Display label, 1–160 code units. No exclusive allocation or real-world identity claim follows from this field. |\n| `description` | Optional. Plain text, 0–4096 code units. |\n| `links` | Optional array, at most 32 link objects. Absence is valid. |\n| `profileSupport` | Optional array, at most 32 attributed profile support claims. An empty array is valid. |\n| `extensions` | Optional object whose member names are operator-chosen absolute HTTP(S) URLs. Descriptive data only under this core. |\n\nA 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.\n\nA 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.\n\nOther 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.\n\n" }, { "id": "clause-5", "content_markdown": "## 5 Keys and world references\n\n**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.\n\nThe SHA-256 JWK thumbprint is calculated following RFC 7638 and RFC 8037 §2: hash the UTF-8 bytes of `{\"crv\":\"Ed25519\",\"kty\":\"OKP\",\"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.\n\n**C-ID.** A world reference is the case-sensitive ASCII token `cpw1..`. 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.\n\nA 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.\n\nThis 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.\n\n" }, { "id": "clause-6", "content_markdown": "## 6 Signed artifact and protected bytes\n\n**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.\n\nEach 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:\n\n| Member | Value |\n|---|---|\n| `alg` | `Ed25519`, the fully specified JOSE identifier from RFC 9864 §2.2. Not the polymorphic `EdDSA` value. |\n| `typ` | `application/vnd.cyberplanetary.registration+json`, an application-defined type marker, not an assertion of IANA registration. |\n| `kid` | The JWK thumbprint URI computed under §5. |\n| `jwk` | The exact public JWK under §5. |\n\nNo 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.\n\n**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.\n\n**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.\n\nHTTP 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.\n\n" }, { "id": "clause-7", "content_markdown": "## 7 Verification\n\n**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.\n\nA 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.\n\nThe 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.\n\n" }, { "id": "clause-8", "content_markdown": "## 8 Revisions and replay\n\n**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.\n\nA 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.\n\nThe 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.\n\nMetadata 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.\n\n" }, { "id": "clause-9", "content_markdown": "## 9 Catalog representation\n\n**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.\n\nA 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.\n\nA 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.\n\nA 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.\n\nAssessment 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.\n\n**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.\n\n" }, { "id": "clause-10", "content_markdown": "## 10 Publication, policy and security\n\nNo 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.\n\nCatalog 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.\n\nImplementers 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.\n\nThe 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.\n\n" }, { "id": "clause-11", "content_markdown": "## 11 References and conformance evidence\n\nNormative 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.\n\nThe 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.\n" } ], "canonical_markdown": "# Cyberplanetary — World Registration and Discovery\n\n**CP 0001 v0.2.0 (2026-10-04T11:01:58Z)**\n\n- Publisher: Cyberplanetary\n- Kind: specification\n- Version: initial development (major version 0): any change may break\n- Cite as: CP 0001 v0.2.0 (this version); CP 0001 (always the latest stable version)\n\nSummary of changes: Restructure published 0.1.0 provisions as a numbered standard; correct informative demonstration names where applicable.\n\nThe status of a version (current, superseded, withdrawn) is not part of this text, because it changes after release. See https://cyberplanetary.org/standards/cp-0001/.\n\nCyberplanetary standard. Distributed with the project under AGPL-3.0-only; see the canonical repository LICENSE. Standard status is recorded in the series catalogue.\n\n\n\n## Contents\n\n- [Introduction](#part-introduction)\n- [1 Scope and requirement targets](#clause-1)\n- [2 Meanings that remain distinct](#clause-2)\n- [3 Representation limits and safe interpretation](#clause-3)\n- [4 World registration statement](#clause-4)\n- [5 Keys and world references](#clause-5)\n- [6 Signed artifact and protected bytes](#clause-6)\n- [7 Verification](#clause-7)\n- [8 Revisions and replay](#clause-8)\n- [9 Catalog representation](#clause-9)\n- [10 Publication, policy and security](#clause-10)\n- [11 References and conformance evidence](#clause-11)\n\n\n\n## Introduction\n\nThis document specifies the first clean-sheet registration-and-discovery exchange. It is not the retired website draft v0.1 or v0.2. The original 0.1.0 publication identifier remains unchanged. This standard restructures the published 0.1.0 protocol text without changing its normative provisions.\n\nThe vision is: **A future where everyone has the freedom and the means to choose and shape their experiences with technology on their own terms.**\n\nThe 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.**\n\nThe preceding text was dated 2 October 2026 and is preserved at its original version URL. Its verified source is the Cyberplanetary protocol repository, commit `eae66fe9ca90f5b0398e16377a0e4cb8a4cb4da7`. This standard’s document version is distinct from the unchanged wire-format strings and exact profile claim identifiers.\n\n\n\n## 1 Scope and requirement targets\n\nThis 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.\n\nThe 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.\n\nThe 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.\n\n\n\n## 2 Meanings that remain distinct\n\nA **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.\n\nA 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.\n\nRoles 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.\n\n\n\n## 3 Representation limits and safe interpretation\n\n**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.\n\nReference 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.\n\nTextual 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.\n\n\n\n## 4 World registration statement\n\n**C-STMT.** The JWS payload is a JSON object with these fields:\n\n| Field | Requirement and interpretation |\n|---|---|\n| `format` | Required. Exactly `cyberplanetary.registration/0.1`. |\n| `world` | Required. A `cpw1` world-reference token defined in §5. This is not a newly registered URI scheme or URN namespace. |\n| `sequence` | Required. Integer 1 through 2147483647. Signer-declared revision in this world's registration chain. |\n| `previous` | Required. `null` for sequence 1; otherwise `sha256:` followed by 64 lowercase hex digits naming the preceding signed tuple ([Clause 6](#clause-6)). |\n| `issuedAt` | Required. Signer-asserted calendar timestamp in exact whole-second `YYYY-MM-DDTHH:mm:ssZ` form. Years 0000–9999; leap-second notation is not supported in this version. Not trusted time. |\n| `name` | Optional. Display label, 1–160 code units. No exclusive allocation or real-world identity claim follows from this field. |\n| `description` | Optional. Plain text, 0–4096 code units. |\n| `links` | Optional array, at most 32 link objects. Absence is valid. |\n| `profileSupport` | Optional array, at most 32 attributed profile support claims. An empty array is valid. |\n| `extensions` | Optional object whose member names are operator-chosen absolute HTTP(S) URLs. Descriptive data only under this core. |\n\nA 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.\n\nA 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.\n\nOther 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.\n\n\n\n## 5 Keys and world references\n\n**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.\n\nThe SHA-256 JWK thumbprint is calculated following RFC 7638 and RFC 8037 §2: hash the UTF-8 bytes of `{\"crv\":\"Ed25519\",\"kty\":\"OKP\",\"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.\n\n**C-ID.** A world reference is the case-sensitive ASCII token `cpw1..`. 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.\n\nA 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.\n\nThis 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.\n\n\n\n## 6 Signed artifact and protected bytes\n\n**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.\n\nEach 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:\n\n| Member | Value |\n|---|---|\n| `alg` | `Ed25519`, the fully specified JOSE identifier from RFC 9864 §2.2. Not the polymorphic `EdDSA` value. |\n| `typ` | `application/vnd.cyberplanetary.registration+json`, an application-defined type marker, not an assertion of IANA registration. |\n| `kid` | The JWK thumbprint URI computed under §5. |\n| `jwk` | The exact public JWK under §5. |\n\nNo 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.\n\n**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.\n\n**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.\n\nHTTP 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.\n\n\n\n## 7 Verification\n\n**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.\n\nA 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.\n\nThe 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.\n\n\n\n## 8 Revisions and replay\n\n**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.\n\nA 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.\n\nThe 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.\n\nMetadata 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.\n\n\n\n## 9 Catalog representation\n\n**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.\n\nA 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.\n\nA 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.\n\nA 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.\n\nAssessment 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.\n\n**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.\n\n\n\n## 10 Publication, policy and security\n\nNo 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.\n\nCatalog 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.\n\nImplementers 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.\n\nThe 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.\n\n\n\n## 11 References and conformance evidence\n\nNormative 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.\n\nThe 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.\n" } }