Content-addressed object storage on AT Protocol.

What conventional object stores ask you to trust

• Integrity as a bolt-on. A checksum in metadata you have to trust is intact.
• Audit as hope. A mutation log you hope was never rewritten.
• Identity as configuration. A proprietary IAM standing between you and your bytes.

Two layers, one substrate

the pointer layer is signed and mutable; the object layer is immutable and deduped.

Verifiable across time

Each pointer record links the previous record's CID and is signed. The chain is append-only, so anyone can walk it offline and prove what a name resolved to, and when — that no record was altered and no link removed.

Who signed it — stated, not assumed. Every record now carries its trust tier, and the verifier reads it out. Tier 1: the writer signs with a self-custody key (did:key, did:web, self-hosted PDS) the operator never touches — shipped, zero ceremony. Tier 3: operator-signed, tamper-evident to everyone except the operator — what the public demo instance writes today. The tier is a machine-readable property of the chain; forging one upward is rejected. What's still open is the other half — an external party witnessing the head, so the operator can't omit or equivocate. Specified (anchor + writer's-PDS counter-ledger), not yet shipped. We'd rather you read this here than find it in the code.

Verify a record yourself →

See the pointer record lexicon →

Prove what a name resolved to — and when

A name's history is a list of dated, signed entries. Each one states the CID the name resolved to at that time, in append-only order. Today the operator signs that order; an independent external head-witness (in progress) is what will make omission and reordering detectable without trusting the operator.

See the full architecture →

It's live

chumd is deployed and serving — content-addressed reads and writes behind a TLS edge. The metrics endpoint stays private; only the API is public.

$ curl https://api.chum.blue/health
ok

this instance signs its pointer records as
did:key:zDnaeoYeKmUPkJLf3TUnDyvBgR11mto8xGjAL5nm4g9VyaMvp

For builders

chum put ./photo.jpg            # → bafy… (the CID is the receipt)
chum get bafy… > out.jpg        # content-addressed read
chum verify bafy… ./photo.jpg   # bytes match the address, or they don't

What's shipped

Built in public, decision by decision. Each milestone links its design journal where one exists.

1. SP-0 2026-06-06 Auth + substrate ADRs ratified
2. SP-1 2026-06-07 AT Protocol pointer store — signed name→CID chain
3. SP-5 2026-06-09 Durable content-addressed substrate — filesystem + S3 CAS
4. SP-6 2026-06-10 Deletion done right — signed tombstones + journal-gated reaper
5. SP-7 2026-06-17 Multipart assembly — Merkle-root manifests
6. SP-13 2026-06-24 Hardening — robustness, observability, per-IP rate limiting, security review
7. SP-4b 2026-07-04 Capability enforcement — attenuable, revocable DID-scoped grants (ADR-0007)
8. SP-4e 2026-07-15 Writer-signed records + machine-readable trust tiers (ADR-0008)
9. SP-13e 2026-07-16 Visibility-gated blob reads — the byte endpoint is not an existence oracle
10. SP-17 2026-07-27 Adversarial conformance suite — forgeries replayed against the live target

Where it stands

Open decisions

• Should a proof bundle be self-contained, or carry the authorising capability chain? It can't do both — the server never holds the chain. The hole in my own claim →
• What is the right durability/cost tradeoff for the substrate tiers? SP5 journal →
• How far should the pointer chain be exposed to clients vs. summarized? SP1 journal →

Get involved

Chum is built in the open. The most useful contribution right now is discussion on the open decisions above.

• Read the code — and the open ADRs in docs/decisions.
• Contribute — open an issue before a large PR.
• Follow @chum.blue on Bluesky for build-in-public notes.
• Found a security issue? security@chum.blue — please report privately first.

Get early access