{
  "format": "cyberplanetary/standard-release/1",
  "designator": "CP 0003",
  "title": "Linked Resources profile",
  "kind": "profile",
  "publisher": "Cyberplanetary",
  "version": "0.2.0",
  "released": "2026-10-04T11:01:58Z",
  "canonical_url": "https://cyberplanetary.org/standards/cp-0003/0.2.0/cp-0003-0.2.0.md",
  "canonical_sha256": "34c55ff020bf1c675643e7e8fb8da26b35e21570229b0e2997cf6fa3be0bf1de",
  "release_digest": "a5dccffa362761082ede7f1cd24f759e9ab4fe4ef33a3ddcbc4e2eaa02b3196f",
  "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 0003",
    "parts": [
      {
        "id": "contents",
        "role": "front",
        "generated": "contents"
      },
      {
        "id": "introduction",
        "role": "front",
        "file": "introduction.md"
      },
      {
        "id": "function-and-bases",
        "role": "clause",
        "file": "function-and-bases.md"
      },
      {
        "id": "binding-a-manifest",
        "role": "clause",
        "file": "binding-a-manifest.md"
      },
      {
        "id": "reader-processing",
        "role": "clause",
        "file": "reader-processing.md"
      },
      {
        "id": "reference-demonstrations",
        "role": "clause",
        "file": "reference-demonstrations.md"
      }
    ]
  },
  "document": {
    "format": "cyberplanetary/resolved-document/1",
    "work": "CP 0003",
    "parts": [
      {
        "id": "part-contents",
        "content_markdown": "## Contents\n\n- [Introduction](#part-introduction)\n- [1 Function and bases](#clause-1)\n- [2 Binding a manifest](#clause-2)\n- [3 Reader processing](#clause-3)\n- [4 Reference demonstrations](#clause-4)\n\n"
      },
      {
        "id": "part-introduction",
        "content_markdown": "## Introduction\n\nProfile identifier: `https://cyberplanetary.org/profiles/linked-resources/0.1.0/`\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 Function and bases\n\nA publisher offers a bounded collection of downloadable resources with explicit media types and byte commitments. A generic client can list and check the resources without knowing the world's internal ontology. This profile selects the registration core's signed profile claims, HTTP GET/HEAD semantics (RFC 9110), the C-JSON subset, and SHA-256 from the signature core's hash machinery. Resource retrieval does not transfer assets between economies or authorize execution.\n\n"
      },
      {
        "id": "clause-2",
        "content_markdown": "## 2 Binding a manifest\n\n**R-CLAIM.** A participating publisher includes a profile support claim whose `profile` equals this exact version identifier, whose `target` is the statement's world token, and whose `parameters.manifest` contains `href`, `bytes`, and `sha256`. `href` is an absolute HTTP(S) URL without user information. `bytes` is a nonnegative integer at most 1048576. `sha256` is exactly 64 lowercase hexadecimal digits. The hash covers the HTTP representation data after removal of transfer framing/content coding, exactly as exposed to an ordinary Fetch API body reader; intermediaries MUST NOT transform the resource. Reference servers use identity content encoding. Header values themselves are not included.\n\n**R-MANIFEST.** The referenced bytes decode as C-JSON with `format:\"cyberplanetary.resources/0.1\"`, `world` equal to the signed claim target, optional `title`, and an array `resources` of 0–100 resource objects. The publisher MUST publish exactly the committed bytes. Any change to the manifest bytes requires a revised signed registration before a verifier can accept the new bytes against that registration. An old registration can remain meaningful if its older committed artifacts are still available.\n\nA resource requires:\n\n| Field | Constraint |\n|---|---|\n| `id` | Distinct within this manifest; lower-case ASCII letter followed by up to 63 lower-case letters, digits or hyphens. Not a global cell identifier. |\n| `href` | Absolute HTTP(S) URL, following the core URL constraints. |\n| `mediaType` | Plain media-type string, 1–128 code units, such as `model/gltf-binary` or `application/json`. |\n| `bytes` | Nonnegative integer, at most 33554432 in this profile version. |\n| `sha256` | 64 lower-case hex digits committing to the fetched representation data. |\n| `label` | Optional human-readable text, 1–160 code units. |\n| `role` | Optional descriptive token, 1–160 code units. Additional profiles may specify its meaning. |\n\nOther descriptive members are permitted and do not authorize operations. An individual resource can use any content model or media type. This does not make the manifest a world ontology. In particular, the profile does not require cells, spatial dimensions, avatars or executable content.\n\n"
      },
      {
        "id": "clause-3",
        "content_markdown": "## 3 Reader processing\n\n**R-CHECK.** A reader claiming byte-commitment verification MUST first verify the registration signature and key/world binding, select the applicable world-targeted claim, fetch and size-bound the manifest, check its byte count and SHA-256, parse its required structure, and check its world reference. To verify a resource it then fetches within the stated size bound, computes SHA-256 over the returned data, and compares both length and hash. Checking a manifest does not mean every referenced resource has been checked. A client MUST state which checks occurred.\n\nA reader MAY list resources without fetching their bytes. It MUST NOT execute content or supply credentials merely because a manifest references it. Unknown media types remain listable/downloadable. Failure, timeout, mismatch, unsupported type or a user's decision not to fetch MUST NOT be reported as successful verification. Cross-origin retrieval requires the publisher's CORS support for credential-free GET. The reference implementations reject redirects and use 15-second fetch deadlines; other deliberate redirect policies must preserve the byte checks and credential boundary.\n\nBefore contacting a new origin, an interactive reader should make clear that ordinary request metadata reaches that origin. Server-side catalog intake never performs these fetches. The generic reader in this release performs them in the user's browser only after explicit selection.\n\n"
      },
      {
        "id": "clause-4",
        "content_markdown": "## 4 Reference demonstrations\n\nCipherlot offers an original GLB scene. Journal Vaults offers a locally defined JSON collection of rooms and reading paths. Both use this profile while retaining different internal structures. Their identity/signature and manifest commitments are generated at deployment preparation; no private key is published and no global resource host is required.\n"
      }
    ],
    "canonical_markdown": "# Linked Resources profile\n\n**CP 0003 v0.2.0 (2026-10-04T11:01:58Z)**\n\n- Publisher: Cyberplanetary\n- Kind: profile\n- Version: initial development (major version 0): any change may break\n- Cite as: CP 0003 v0.2.0 (this version); CP 0003 (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-0003/.\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<a id=\"part-contents\"></a>\n\n## Contents\n\n- [Introduction](#part-introduction)\n- [1 Function and bases](#clause-1)\n- [2 Binding a manifest](#clause-2)\n- [3 Reader processing](#clause-3)\n- [4 Reference demonstrations](#clause-4)\n\n<a id=\"part-introduction\"></a>\n\n## Introduction\n\nProfile identifier: `https://cyberplanetary.org/profiles/linked-resources/0.1.0/`\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<a id=\"clause-1\"></a>\n\n## 1 Function and bases\n\nA publisher offers a bounded collection of downloadable resources with explicit media types and byte commitments. A generic client can list and check the resources without knowing the world's internal ontology. This profile selects the registration core's signed profile claims, HTTP GET/HEAD semantics (RFC 9110), the C-JSON subset, and SHA-256 from the signature core's hash machinery. Resource retrieval does not transfer assets between economies or authorize execution.\n\n<a id=\"clause-2\"></a>\n\n## 2 Binding a manifest\n\n**R-CLAIM.** A participating publisher includes a profile support claim whose `profile` equals this exact version identifier, whose `target` is the statement's world token, and whose `parameters.manifest` contains `href`, `bytes`, and `sha256`. `href` is an absolute HTTP(S) URL without user information. `bytes` is a nonnegative integer at most 1048576. `sha256` is exactly 64 lowercase hexadecimal digits. The hash covers the HTTP representation data after removal of transfer framing/content coding, exactly as exposed to an ordinary Fetch API body reader; intermediaries MUST NOT transform the resource. Reference servers use identity content encoding. Header values themselves are not included.\n\n**R-MANIFEST.** The referenced bytes decode as C-JSON with `format:\"cyberplanetary.resources/0.1\"`, `world` equal to the signed claim target, optional `title`, and an array `resources` of 0–100 resource objects. The publisher MUST publish exactly the committed bytes. Any change to the manifest bytes requires a revised signed registration before a verifier can accept the new bytes against that registration. An old registration can remain meaningful if its older committed artifacts are still available.\n\nA resource requires:\n\n| Field | Constraint |\n|---|---|\n| `id` | Distinct within this manifest; lower-case ASCII letter followed by up to 63 lower-case letters, digits or hyphens. Not a global cell identifier. |\n| `href` | Absolute HTTP(S) URL, following the core URL constraints. |\n| `mediaType` | Plain media-type string, 1–128 code units, such as `model/gltf-binary` or `application/json`. |\n| `bytes` | Nonnegative integer, at most 33554432 in this profile version. |\n| `sha256` | 64 lower-case hex digits committing to the fetched representation data. |\n| `label` | Optional human-readable text, 1–160 code units. |\n| `role` | Optional descriptive token, 1–160 code units. Additional profiles may specify its meaning. |\n\nOther descriptive members are permitted and do not authorize operations. An individual resource can use any content model or media type. This does not make the manifest a world ontology. In particular, the profile does not require cells, spatial dimensions, avatars or executable content.\n\n<a id=\"clause-3\"></a>\n\n## 3 Reader processing\n\n**R-CHECK.** A reader claiming byte-commitment verification MUST first verify the registration signature and key/world binding, select the applicable world-targeted claim, fetch and size-bound the manifest, check its byte count and SHA-256, parse its required structure, and check its world reference. To verify a resource it then fetches within the stated size bound, computes SHA-256 over the returned data, and compares both length and hash. Checking a manifest does not mean every referenced resource has been checked. A client MUST state which checks occurred.\n\nA reader MAY list resources without fetching their bytes. It MUST NOT execute content or supply credentials merely because a manifest references it. Unknown media types remain listable/downloadable. Failure, timeout, mismatch, unsupported type or a user's decision not to fetch MUST NOT be reported as successful verification. Cross-origin retrieval requires the publisher's CORS support for credential-free GET. The reference implementations reject redirects and use 15-second fetch deadlines; other deliberate redirect policies must preserve the byte checks and credential boundary.\n\nBefore contacting a new origin, an interactive reader should make clear that ordinary request metadata reaches that origin. Server-side catalog intake never performs these fetches. The generic reader in this release performs them in the user's browser only after explicit selection.\n\n<a id=\"clause-4\"></a>\n\n## 4 Reference demonstrations\n\nCipherlot offers an original GLB scene. Journal Vaults offers a locally defined JSON collection of rooms and reading paths. Both use this profile while retaining different internal structures. Their identity/signature and manifest commitments are generated at deployment preparation; no private key is published and no global resource host is required.\n"
  }
}