rfc-1 · schema

manifest schema

versão 0.1 · atualizado 2026-04-15 · status: publicado

§1

escopo

Este documento define o schema canônico de manifestos do protocolo Aevia. Todo cliente criador MUST produzir manifestos que validam contra o schema de §3. Todo verificador MUST rejeitar manifestos que violam §3 ou §5.

As palavras-chave MUST, SHOULD, MAY seguem RFC 2119.

§2

terminologia

manifest: documento JSON assinado que enumera um item de conteúdo.
canonical encoding: representação byte-determinística do manifesto, conforme RFC 8785 (JCS).
manifest hash: SHA-256 da canonical encoding do manifesto com o campo signature removido.

§3

schema canônico

O manifesto MUST obedecer o schema JSON abaixo:

{
  "version": 1,
  "cid": "<string — CID do corpo do manifesto>",
  "creator": "<string — endereço Ethereum EIP-55>",
  "created_at": "<string — timestamp RFC 3339 UTC>",
  "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>"
}

Regras de presença (MUST):

version MUST ser inteiro igual a 1 para este RFC.
cid MUST ser o CID do manifesto canonicalmente codificado excluindo o próprio campo cid e o campo signature.
creator MUST ser endereço EIP-55 válido.
created_at MUST ser timestamp RFC 3339 em UTC com sufixo Z.
exatamente um dos campos estruturais (hls, image, document) MUST ser não-nulo, correspondendo ao content_type declarado.
signature MUST ser assinatura secp256k1 EIP-712 conforme RFC-3.

§4

tipos de conteúdo

video/hls — manifesto aponta para master playlist HLS e enumera segmentos. Cada segmento MUST ter CID próprio.
video/vod — alias de video/hls com indicação de que o conteúdo não é ao vivo.
image — campo image MUST ser preenchido. Formatos aceitos: png, jpeg, webp, avif.
document — campo document MUST ser preenchido. Pode ser pdf, markdown ou html.

Clientes SHOULD rejeitar content types desconhecidos. Clientes MAY sinalizar conteúdo de tipo não suportado como não-renderizável sem invalidar o manifesto.

§5

canonicalização

Para garantir que duas partes produzam o mesmo hash sobre o mesmo manifesto, a canonicalização MUST seguir RFC 8785 (JSON Canonicalization Scheme — JCS):

chaves de objeto ordenadas lexicograficamente em UTF-16 code units;
nenhum whitespace entre tokens;
números em forma canônica (sem zeros à esquerda, sem sinal + explícito);
strings em UTF-8, com apenas os escapes obrigatórios por RFC 8259;
antes do hash: campos cid e signature REMOVIDOS;
hash: SHA-256 da sequência de bytes UTF-8 canônica resultante.

§6

versionamento

Manifestos são imutáveis por CID. Uma revisão produz um novo manifesto com novo CID, novo timestamp e (tipicamente) novo signature. O Content Registry MUST preservar ambos. Clientes SHOULD resolver para o manifesto mais recente publicado pelo mesmo creator no slot lógico de conteúdo, quando referido pelo slot.

Incrementos no campo version deste RFC serão propostos via Conselho (RFC-7) e MUST manter retrocompatibilidade para verificadores: um manifesto version=1 MUST continuar verificável mesmo após a publicação de version=2.

§7

considerações de segurança

ordenação não-canônica de campos produz hashes divergentes e invalida a assinatura; verificadores MUST canonicalizar antes de verificar.
timestamps futuros além de registeredAt + 5 minutos DEVEM ser tratados como suspeitos pelos clientes.
campos extensão desconhecidos MUST ser preservados byte-a-byte por proxies e relayers; descartar campos invalida a assinatura.

§8

referências

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