Storage

Everything in ZephCraft is named by its BLAKE3 hash — the name is the checksum, so deduplication and integrity come for free. Content is stored as RLNC erasure-coded pieces: publish splits an object into k source chunks and spreads n coded combinations across peers (k=8 → n=32 today).

Why RLNC

Random linear network coding has one property no replication scheme matches: repair without decode. Any node holding just two pieces can mint a fresh, verifiably-valid piece locally — no re-downloading the object, no coordinator, no "rare piece" problem. Data survives churn as long as any handful of pieces survives anywhere.

Every piece carries public verification tags (null-space vtags): any node can verify any piece — including freshly re-coded repair pieces — at ingest, before storing. Polluted data never enters the store.

Publish, get

• Publish is fire-and-forget: you get the CID back immediately; the publisher retains its own copy synchronously (the guaranteed replica) and distribution happens in the background under short per-peer timeouts. Your publish is never hostage to one slow peer.
• Get decodes from local pieces when possible, then pulls pieces from up to 16 providers in parallel, verifying every piece and the final whole-content hash.

The lifecycle — five behaviors, one loop

A health scan watches every held CID (hot items every 30 s, healthy ones backing off to ~30 min) and applies:

• Repair — below the durability floor: a deterministic election (hash(node ‖ cid ‖ epoch)) picks exactly one holder to mint one fresh piece. No coordination messages, no thundering herd.
• Degrade — cold surplus above the floor is shed one piece at a time. Scaling up is instant; scaling down is slow and elected — the destructive direction is careful, the safe direction is fast.
• Offload — a publisher's retained copy is dropped only when other nodes hold the full erasure set (not the bare decode minimum) — releasing at the minimum would be zero-margin.
• Scale — the moment a CID's served traffic crosses a threshold, one new provider is recruited. Demand-driven, temporary.
• Fade — content that is not pinned, not wanted, and unfetched simply stops being repaired. Passive death by churn. A later pin or want resumes repair.

Pins, wants, deletes

• Pin = hold the whole content locally, exempt from eviction. A pinner can serve pieces forever (it encodes fresh ones on demand).
• Want = a keep-alive vote without holding — a signed network record that gates the fade.
• Delete = forget locally + withdraw your provider records (re-publishable). Ban = a local tombstone that refuses re-hosting. There is deliberately no network-wide delete: you cannot unpublish what other people want — and equally, the network won't keep what nobody wants.

Private content

Files can be published private: encrypted with a per-object key (XChaCha20-Poly1305), the key wrapped to the owner's re-encryption public key. The network stores, codes, verifies, and repairs ciphertext only; filename and type hide inside the ciphertext. Only the owner's identity can decrypt — proven end-to-end on the live network.