# Linked Resources profile

**CP 0003 v0.2.0 (2026-10-04T11:01:58Z)**

- Publisher: Cyberplanetary
- Kind: profile
- Version: initial development (major version 0): any change may break
- Cite as: CP 0003 v0.2.0 (this version); CP 0003 (always the latest stable version)

Summary of changes: Restructure published 0.1.0 provisions as a numbered standard; correct informative demonstration names where applicable.

The 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/.

Cyberplanetary standard. Distributed with the project under AGPL-3.0-only; see the canonical repository LICENSE. Standard status is recorded in the series catalogue.

<a id="part-contents"></a>

## Contents

- [Introduction](#part-introduction)
- [1 Function and bases](#clause-1)
- [2 Binding a manifest](#clause-2)
- [3 Reader processing](#clause-3)
- [4 Reference demonstrations](#clause-4)

<a id="part-introduction"></a>

## Introduction

Profile identifier: `https://cyberplanetary.org/profiles/linked-resources/0.1.0/`

The 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.

<a id="clause-1"></a>

## 1 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.

<a id="clause-2"></a>

## 2 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.

<a id="clause-3"></a>

## 3 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.

<a id="clause-4"></a>

## 4 Reference demonstrations

Cipherlot 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.