chum

Architecture

Every diagram below is a frozen, verifiable assertion about how chum behaves. Each maps to one or more numbered claims (CL-*) defined at the foot of this page.

Mental model

The two layers, and the atproto nouns they are built from.

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

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: a new pointer record is signed by did:key, links the previous CID, is dedup-checked, and committed.

  • CL-5
  • CL-8

did:key identity

Authority to mutate a name is cryptographic: did:key → public key → signature verification → authorized mutation.

  • CL-5
  • CL-8

The chain

An append-only, 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 → verify signature → verify prev-CID link → fetch bytes by CID → integrity check, with failure branches.

  • 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

Proving what a name resolved to, and when.

Verification over time

An auditor walks previous-CID links backward, verifies each signature, and asserts history intact.

  • 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

A chum instance inside the wider ATProto ecosystem: PDS, relay, DID resolution, peer repos.

  • 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
The chain is append-only; history cannot be rewritten.
CL-5
Pointer records are signed by the owner's did:key.
CL-6
Integrity is intrinsic, not a bolt-on checksum.
CL-7
Audit is provable, not hoped-for.
CL-8
Identity is cryptographic, not proprietary IAM configuration.
CL-9
You can prove what a name resolved to, and when.
CL-10
CHUM is ATProto-native (lexicons, repos, DIDs).