Rustory: What Local-First Costs Under Partial Failure
Keeping shell history local is the easy promise; deletion, offline peers, relay-only paths, and installed-shell behavior are the real design.
CENTRAL QUESTION
What complexity must a local-first tool accept when the network is only a replication path and no server is allowed to become the authority?
WORKING THESIS
Local-first is not the absence of a server. It is a commitment to preserve local authority through replication, deletion, membership change, and partial failure.
PUBLICATION BOUNDARY
What this piece can honestly claim.
GROUNDED IN
The public Rustory implementation, protocol and security documentation, acceptance tests, release gates, and use across the author's own machines.
DOES NOT CLAIM
Rustory is not presented as a novel consensus protocol, an internet-scale service, or proof that peer-to-peer storage is universally safer than a hosted system.
DRAFT ARCHITECTURE
The argument, section by section.
- 01
Begin where the user feels the system
Shell history is valuable because it disappears into a daily keystroke, but it also contains paths, hosts, secrets, and mistakes.
EVIDENCEStart with the Ctrl-R workflow and a threat inventory grounded in actual stored data.
- 02
Define local authority precisely
Each device owns a usable SQLite history while discovery and relay services remain replaceable coordination and transport.
EVIDENCEDiagram what each component may know, persist, and decide—and what it explicitly may not.
- 03
Make deletion a replicated event
A delete that exists only as absence cannot converge when peers are offline.
EVIDENCETrace device ownership, cursors, tombstones, acknowledgments, and the garbage-collection floor.
- 04
Isolate partial failure per peer
One unreachable or stale machine should not block healthy peers or corrupt their progress.
EVIDENCEUse bounded peer budgets, preserved cursors, retry rules, and a relay-only acceptance scenario.
- 05
Treat membership change as a security boundary
Encryption secures transport, but device enrollment, revocation, and retained local copies define the real trust model.
EVIDENCEState what revocation prevents, what it cannot erase, and how the implementation communicates that limit.
- 06
Prove the installed experience, not only convergence
A protocol can be correct while the product is broken if hooks, reload, diagnostics, or recovery fail in the user's shell.
EVIDENCEConnect acceptance tests and release health to the exact interactive workflow.
EDITORIAL GATE
Evidence required before publication.
Executable path
Link every major claim to a public protocol rule, implementation boundary, acceptance test, or release check.
Failure matrix
Online, offline, stale, revoked, relay-only, and partially synchronized peers with expected local behavior.
Deletion trace
One history entry from creation through tombstone propagation, acknowledgment, and safe garbage collection.
User-level proof
Connect protocol convergence to hook installation, live shell reload, search, diagnostics, and recovery.