Database
CraftSQL — real SQLite databases stored as content-addressed pages, durable and recoverable from the network
CraftSQL puts a real SQL database on the grid. It is genuine SQLite — same SQL, same semantics — running over a custom filesystem layer that stores every 16 KB page as a content-addressed object.
How it works
Pages are indexed by a radix tree whose root hash is the database's version: commit a transaction and you get a new root CID; unchanged pages and subtrees keep their hashes (structural sharing), so each commit costs only what changed. The rollback journal lives in RAM and WAL is off — the atomic root swap is crash safety.
One writer per database
Every database is owned by one identity — only the owner writes; anyone can read. This is the consensus-eliminating move: instead of many writers agreeing on one table (a blockchain problem), each participant writes their own database and readers aggregate across them. A federated app is many sovereign databases + cross-node reads, proven live with no shared writer anywhere.
Readers open lazily: they sync only the tiny page index, then fetch page contents on demand straight from the owner — a point query pulls a handful of pages, not the whole database.
Durability — generations
Each commit's diff (changed pages + index path) is packed into one generation blob and published to the storage grid as a system object — erasure-coded, distributed, and repaired like any content. The generation list itself is published as a durability manifest. Every ~16 generations, compaction folds history into a single base snapshot and lets the old generations fade.
Recovery is the point: from (owner, database-name) alone, any node can resolve the manifest, reconstruct every generation from coded pieces, and rebuild the database — a live node can resurrect a dead owner's data. Validated on the real cluster, including across node restarts.
Heads on the registry
A database's current root (and its durability manifest) is published to the head registry — so resolving someone's database needs neither the owner online nor a DHT record, and the head survives writer rotation and node churn.
Private databases
open_private creates a database whose pages are encrypted under a per-database key wrapped to the owner. Readers holding the key decrypt transparently; anyone else gets ciphertext. The node's own indexes (your drive listing, your app list) are private by default.