Version 0.1.0 · experimental implementation release · 2 October 2026
Profile identifier: https://cyberplanetary.org/profiles/linked-resources/0.1.0/
Function and bases
A 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.
Binding a manifest
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.
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.
A resource requires:
| Field | Constraint |
|---|---|
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. |
href | Absolute HTTP(S) URL, following the core URL constraints. |
mediaType | Plain media-type string, 1–128 code units, such as model/gltf-binary or application/json. |
bytes | Nonnegative integer, at most 33554432 in this profile version. |
sha256 | 64 lower-case hex digits committing to the fetched representation data. |
label | Optional human-readable text, 1–160 code units. |
role | Optional descriptive token, 1–160 code units. Additional profiles may specify its meaning. |
Other 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.
Reader processing
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.
A 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.
Before 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.
Reference demonstrations
The Conservatory offers an original GLB scene. Commonplace 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.