One Canonical Store, Many Readers
The Delta store lives on one Mac: whichever Mac holds the family's pippa role, the one that runs Pippa's services. Every other Mac (the workbench, the laptops, the build machines, Pippa's own home Mac, Mom's Mac, two Windows boxes through WSL) needs to load identity too, often several times an hour. A store that only one machine can read would put a network hop and a single point of failure in front of every session start.
So other Macs read through Delta, the family's own data channel between machines, and keep a local copy. The whole design question is how a Mac knows its copy is still the vault.
The Manifest Is the Truth About Bytes
The canonical store publishes, for each vault, a manifest: every note's id and the SHA-256 of its current bytes. A reader on another Mac asks its own Delta for that manifest, then for each note it needs:
- If it holds a local copy whose hash matches the manifest, it serves that copy, labeled
validated. No bytes cross the network. - If its copy is missing or behind, it fetches the canonical bytes, checks them against the manifest, keeps them, and serves them as
validated. - If the canonical bytes themselves do not match the canonical manifest, that is
integrity_error. Something is wrong at the source, and no answer is better than a wrong one.
A note written between the manifest and its read is read against a fresh manifest once before its bytes are called damaged, so an ordinary concurrent write does not masquerade as corruption.
When the Canonical Mac Is Away
Travel, a sleeping Mac, a restarting Delta: sometimes the manifest cannot be fetched. Dad's rule for this case is called D4 in the design, and it is carried through every layer:
- A note this Mac verified earlier may still be served, labeled
offline_replicawith the cause. The label appears on the read, on the identity card, and in machine-readable output. - A note this Mac never verified is
backend_unavailable. It is never fetched from anywhere else and never guessed. (If the manifest this Mac saved last time does not list the note at all, the answer isnote_not_foundinstead, as it would be online.) - A write is
canonical_unreachable, at once. Nothing is queued (lesson 4). - The next process that can reach the canonical Mac reads
validatedagain. Nothing has to be reset.
The rare-path trial on 2026-11-10 exercised both halves. With only this Mac's Delta out of reach, the client asked the canonical Mac's Delta gateway directly over the tailnet and still read validated. With both out of reach for one process (its Delta client pointed where nothing listened, no service or network setting touched), a verified note was served as offline_replica with the cause on the read, the card and the JSON, a never-verified note was backend_unavailable, a write was canonical_unreachable with nothing queued, and the next process read validated.
A Soul That Leaves
One more rule keeps replicas honest: when a soul is removed on the canonical store, every other Mac drops its kept notes, manifest and rendered bundles for that vault the next time it reads a vault list that no longer names it. Not offline, and never on a list that lacks the shared vault, so a truncated answer cannot make a Mac throw away a soul that still exists.