Two-layer architecture
A mutable, signed pointer layer resolving names to CIDs, atop an immutable, content-addressed object layer.
- CL-1
- CL-2
- CL-6
Architecture
Every diagram below maps to numbered claims (CL-*); each claim is traced to the code, and listed at the foot of this page. Where a diagram shows the target design rather than the public instance today, its caption says so.
Mental model
The two layers, and the atproto nouns they are built from.
ATProto data model
The nouns and their cardinalities: DID, Repo, Collection/Lexicon, PointerRecord, CIDObject.
- CL-1
- CL-3
- CL-10
Write path
Who signs what, and where authority comes from.
Pointer write (PUT)
On a write: the bytes are dedup-checked, and a new pointer record linking the previous CID is signed by the instance's did:key and committed. Diagram shows the target design (writer-held signature); today the instance signs.
- CL-5
- CL-8
did:key identity
Target design: authority to mutate a name is cryptographic — did:key → public key → signature verification → authorized mutation. Built behind capability auth; not enabled on the public instance.
- CL-5
- CL-8
The chain
A hash-linked ledger with a legal lifecycle.
Pointer chain ledger
An append-only, hash-linked sequence where each record references the previous record's CID.
- CL-3
- CL-4
Pointer lifecycle
The legal lifecycle of a pointer record: draft → signed → committed → superseded / tombstoned.
- CL-3
- CL-4
Read & dedup
Verifying reads, and why identical bytes converge on one CID.
Verifying read path
Resolve name → pointer → fetch bytes by CID → integrity check, with failure branches. Signature and prev-CID checks run when you verify the chain (in the browser verifier), not on every read.
- CL-1
- CL-2
- CL-6
Dedup fan-in
Distinct names/pointers carrying identical bytes converge on a single CID-addressed object.
- CL-1
Across time
What a name resolved to, in order.
Verification over time
An auditor walks previous-CID links backward and verifies each signature; a truncated or withheld head is only detectable once the external witness ships.
- CL-3
- CL-4
- CL-5
- CL-7
- CL-9
Single-name timeline
One name's resolved-CID history as dated entries, in order.
- CL-4
- CL-9
Ecosystem
Where a chum instance sits inside ATProto.
ATProto topology
Where a chum instance sits in ATProto: it resolves DIDs through the directory and reads revocations from issuers' repos. The PDS and relay edges are the target design; it does not yet publish to a PDS or relay.
- CL-8
- CL-10
Claims
- CL-1
- "The address is the content" — bytes are addressed by CID (immutable, deduped).
- CL-2
- A name resolves to a CID via a pointer record; bucket + key → CID → bytes.
- CL-3
- Each pointer record links the previous record's CID (hash-linked chain).
- CL-4
- Each record commits to its predecessor's CID, so changing any past record breaks every link after it.
- CL-5
- Pointer records are signed by the instance's did:key; at Tier 1 the writer's did:key also signs the write intent each record commits to.
- CL-6
- Integrity is intrinsic, not a bolt-on checksum.
- CL-7
- Given a name's exported history, an auditor can walk the prev-CID links, verify each signature, and confirm no record in it was altered.
- CL-8
- Identity is a DID and its keys, not a proprietary IAM (DID-signed auth built; the preview instance is operator-only).
- CL-9
- A name's history shows what it resolved to, in order; timestamps are the operator's until the head-witness ships.
- CL-10
- Chum uses ATProto lexicons, DAG-CBOR records and DIDs.