rfc-1 · schema

manifest schema

version 0.1 · updated 2026-04-15 · status: published

§1

scope

This document defines the canonical schema of Aevia protocol manifests. Every creator client MUST produce manifests that validate against the §3 schema. Every verifier MUST reject manifests that violate §3 or §5.

MUST, SHOULD, MAY follow RFC 2119.

§2

terminology

manifest: signed JSON document enumerating a content item.
canonical encoding: byte-deterministic representation of the manifest, per RFC 8785 (JCS).
manifest hash: SHA-256 of the canonical encoding of the manifest with the signature field removed.

§3

canonical schema

The manifest MUST conform to the JSON schema below:

{
  "version": 1,
  "cid": "<string — CID of the manifest body>",
  "creator": "<string — EIP-55 Ethereum address>",
  "created_at": "<string — RFC 3339 UTC timestamp>",
  "content_type": "video/hls" | "video/vod" | "image" | "document",
  "duration_seconds": <number | null>,
  "hls": {
    "master_playlist_cid": "<string — CID>",
    "segments": ["<CID>", ...]
  } | null,
  "image": { "cid": "<CID>", "width": <number>, "height": <number> } | null,
  "document": { "cid": "<CID>", "mime": "<string>" } | null,
  "title": "<string | null>",
  "description": "<string | null>",
  "tags": ["<string>", ...] | null,
  "signature": "<string — 0x-prefixed 65-byte secp256k1>"
}

Presence rules (MUST):

version MUST be integer 1 for this RFC.
cid MUST be the CID of the canonically encoded manifest excluding the cid and signature fields themselves.
creator MUST be a valid EIP-55 address.
created_at MUST be an RFC 3339 UTC timestamp with Z suffix.
exactly one of hls, image, document MUST be non-null, matching the declared content_type.
signature MUST be a secp256k1 EIP-712 signature per RFC-3.

§4

content types

video/hls — manifest points to an HLS master playlist and enumerates segments. Each segment MUST have its own CID.
video/vod — alias of video/hls for non-live content.
image — image field MUST be populated. Accepted formats: png, jpeg, webp, avif.
document — document field MUST be populated. MAY be pdf, markdown, or html.

Clients SHOULD reject unknown content types. Clients MAY surface unsupported content as non-renderable without invalidating the manifest.

§5

canonicalization

To guarantee that two parties produce the same hash over the same manifest, canonicalization MUST follow RFC 8785 (JSON Canonicalization Scheme — JCS):

object keys sorted lexicographically by UTF-16 code units;
no whitespace between tokens;
numbers in canonical form (no leading zeros, no explicit + sign);
UTF-8 strings with only the escapes required by RFC 8259;
before hashing: cid and signature fields REMOVED;
hash: SHA-256 over the resulting canonical UTF-8 byte sequence.

§6

versioning

Manifests are immutable by CID. A revision produces a new manifest with a new CID, a new timestamp, and (typically) a new signature. The Content Registry MUST preserve both. Clients SHOULD resolve to the latest manifest published by the same creator in the logical content slot when referenced by slot.

Bumps to the version field of this RFC will be proposed via Council (RFC-7) and MUST preserve backward compatibility for verifiers: a version=1 manifest MUST remain verifiable after version=2 is published.

§7

security considerations

non-canonical field ordering produces divergent hashes and invalidates the signature; verifiers MUST canonicalize before verifying.
future timestamps beyond registeredAt + 5 minutes SHOULD be treated as suspicious by clients.
unknown extension fields MUST be preserved byte-for-byte by proxies and relayers; dropping fields invalidates the signature.

§8

references

IETF RFC 2119 — Key words for RFCs
IETF RFC 8259 — JSON
IETF RFC 8785 — JSON Canonicalization Scheme
IETF RFC 3339 — Date and Time on the Internet
EIP-55 — Mixed-case checksum address encoding
RFC-2 — Content Addressing
RFC-3 — Authentication and Signature