Content-addressed object storage on AT Protocol.

The address is the content. Names resolve through a signed, append-only chain you can verify across time.

payload

bafkreidr3vh5xjlqayw4hmnoi5jmgh3j55resat4m7kbhtzeiz7ykh3wmq

change one byte → the address changes:bafkreidr3vh5xjlqayw4hmnoi5jmgh3j55resat4m7kbhtzeiz7ykh3wmqbafkreigakc2a2gx4jww6k4mljjgmsupobo35obzit2fahedn2zbn2rfkb4

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

A bucket + key resolves to a CID; the bytes underneath stay content-addressed.

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.

What it doesn't prove yet. Today those records are signed by the server's key. That makes the chain tamper-evident to everyone except the operator — who could, in principle, rewrite it. Two things close that: the writer signing each record, and an external party witnessing the head. Both are specified, neither is shipped. We'd rather you read this here than find it in the code.

Every read verifies the signature, the prev-CID link, and byte integrity — or it aborts.

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, and no entry can overwrite an earlier one.

One name's resolved-CID history, in append-only order.

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.

SP-0 2026-06-06 Auth + substrate ADRs ratified
SP-1 2026-06-07 AT Protocol pointer store — signed name→CID chain
SP-5 2026-06-09 Durable content-addressed substrate — filesystem + S3 CAS
SP-6 2026-06-10 Deletion done right — signed tombstones + journal-gated reaper
SP-7 2026-06-17 Multipart assembly — Merkle-root manifests
SP-13 2026-06-24 Hardening — robustness, observability, per-IP rate limiting, security review

Where it stands

Built

Content-addressed substrate (filesystem + S3 CAS)
Signed name→CID pointer chain
Multipart upload with Merkle-root manifests (ADR-0003)
chum put / get / verify CLI

Open, in progress

DID-scoped capability grants
Prefix listing at scale
v1 hardening — read the design journals below

Open decisions

How should DID-scoped capability grants be revoked without breaking historical resolution? SP0 journal →
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.