RFC: Capsule catalog (signed distribution + discovery)

[joshuajbouw]

Specifies the capsule catalog: a signed, statically-served index mapping capsule names to verified releases, and the client-side resolution and verification rules that consume it.

Publishers stay on their own infrastructure — a release is a signed tag in your own repo — and a catalog is a derived, signed materialization of many publishers' releases. Astrid defines the document formats and ships the verifier; it operates no index. Anyone can run a catalog, clients can configure several. The first instance is expected to be AOS's; nothing here privileges it.

Opening as a draft for discussion, not to merge.

What motivates it

Three gaps in what we have today:

• No discovery. Nothing lists the capsules that exist, so the website can't show a catalogue and finding a capsule means already knowing its repo.
• No integrity on the release path. Distro.lock records the BLAKE3 that arrived; no install path takes an expected digest — ExpectedCapsule carries id and version only. Sealed .shuttle archives are signed and trust-pinned, but nothing signs an individual capsule release.
• latest is GitHub's, by publish date. Not semver order, and republishing an old release silently changes it.

Shape

• Publisher key = authority over content; catalog key = freshness and consistency only. A compromised CI key can serve a stale view, never forge a release.
• TOFU namespace binding from .astrid/publisher.toml on the default branch, recorded in a transparency log.
• Rotation to a pre-declared successor is immediate; rotation to an undeclared key is timelocked; revocation by the successor is immediate — otherwise a stolen key means permanent namespace theft.
• Log entries are hashes and metadata only, so takedown never conflicts with append-only.
• Metadata lives in git normatively (every clone is a witness); blobs may move, since they're hash-verified.
• Names are catalog-scoped and never merged — dependency confusion reaches us through constellation manifests.
• Static documents throughout: signed root, per-name shards, search projection, mirrored blobs and source snapshots.

Section 10 splits v1-normative from reserved, so the formats carry their fields from serial 1 but implementations can defer consistency proofs, quarantine, advisories, and reproducibility without a breaking change later. The full design is deliberately heavier than 30 capsules in two orgs warrants; the tiering is how it ships.

Relationship to other RFCs

• Depends on RFC: Cargo-like manifest schema with WIT refs, registry, and BLAKE3 lock #26 (cargo_like_manifest) for manifest shape and WIT refs, and adds categories/keywords there.
• Supersedes RFC: Cargo-like manifest schema with WIT refs, registry, and BLAKE3 lock #26's "What the registry actually is" — that section sketches an unsigned git index under unicity-astrid/registry. This replaces it with a signed one, and drops the org coupling, since the spec should be neutral and the index is a product.
• Constellation semantics lean on the distro work in RFC: Distro system #21.

Worth flagging: #26 has been open since May and distro-manifest/distro-system both define Distro.toml independently. This RFC's dependency is a moving target until some of that lands.

Open questions

Delay constants (14d rotation, 7d quarantine) are placeholders. Alias expiry, catalog-identity attestation for non-default catalogs, and the both-keys-lost recovery bar are all undecided. Whether catalog config reuses #26's [[registry]] block or supersedes it needs a call.

https://claude.ai/code/session_01LGoBGfwiZnv6xnTyrMN1er