Fly 2026-06-11 — Seven Ideals, Seven Years: Local-First Software's Unfinished Ledger
Local-first software's founding document is a 2019 Ink & Switch essay that proposed seven ideals for software that respects user ownership. Seven years later, the field has made asymmetric progress — three ideals solved, one broken open with surprising insight, two under active construction, one still deferred.
The Scorecard
The three that worked out are the ones you'd expect. No spinners: CRDT writes are local, so the UI never waits on a network round-trip. Multi-device sync: production sync engines (Yjs, Automerge, ElectricSQL, PowerSync) are real tools in real products. Network optional: SQLite in WebAssembly (PGlite), native offline SDKs, and the offline-first pattern are mature enough to be boring.
Seamless collaboration is where the progress claim gets complicated. CRDTs guarantee syntactic convergence — every replica eventually holds the same bytes. That's not the same as semantic consistency. arXiv:2510.18893 (CodeCRDT, a multi-agent LLM code generation study) found 100% byte-level convergence alongside 5–10% semantic conflicts in the merged output. Structurally valid code, wrong behavior. The CRDT solved the merge; the application still needs a coordination protocol on top of it. The field knows this and is building toward it, but the layer doesn't exist as a general primitive yet.
The Deletion Problem
Standard CRDTs have a dirty secret: tombstones accumulate forever. Delete an item and you leave a permanent deletion marker so other replicas know not to bring it back. The structure grows without bound. For a system that promises you own your data, "you can never truly purge it" is a poor answer.
Willow takes a different architectural path. Its data model organizes entries in hierarchical namespaces (namespace → subspace → path), and deletion works by prefix pruning: deleting /blog collapses the entire /blog/* subtree to a single tombstone at the root. Old values are overwritten, not flagged. Storage stays bounded. This is Willow's most important departure from the CRDT mainstream — the deletion right is treated as a first-class design constraint, not an afterthought.
The Security Problem (The Hardest Ideal)
Ideal 6 — "security and privacy by default" — was the one the field mostly deferred. Encryption needs key management; key management needs a trusted authority; local-first explicitly avoids central authorities. The tension looked intractable.
Two 2025–2026 systems attack it directly.
Keyhive (Ink & Switch) introduces convergent capabilities: access control that travels with the data itself. Standard capability systems or certificate systems both assume a coordinator you can query when checking a permission. Keyhive encodes the capability chain cryptographically — a "stateless self-certifying" proof that doesn't require a phone-home. Group membership is itself a CRDT, meaning two offline peers can both add a collaborator and sync without conflict.
The deeper problem is key agreement. Normal encrypted group messaging (Signal, MLS) uses sequential key updates — adding a user generates a new group key, and everyone needs to be online and in sync to process it. Offline local-first breaks this immediately: two replicas diverging and both adding group members creates an inconsistent key state. Keyhive's BeeKEM makes group key agreement concurrent-safe: group key updates can happen with arbitrary divergence between replicas and converge correctly. The concurrency problem in key management was as hard as the concurrency problem in data — it just received attention five years later.
Willow's companion system, Meadowcap, takes a similar approach: a capability system for fine-grained access control with no central authority. Where Keyhive extends Automerge, Meadowcap is built into the Willow data model from the start.
The Long Now Problem (Still Open)
Ideal 5 — "your work should continue to be accessible indefinitely, even after the company that produced the software is gone" — has a component that sync engines can't solve. A Willow store or an Automerge document is a binary blob. Without the application that interprets it, it's unreadable. The data lives; the meaning doesn't. This is a format and schema problem, not a sync problem. The local-first community doesn't have a strong answer to it yet. It may require something like a slow-moving registry of data format interpreters — closer to archival science than distributed systems.
The Ecosystem Moment
FOSDEM 2026 ran a full local-first devroom (20+ talks on February 1). Local-First Conf 2026 exists as a standalone event. Automerge 3.0 shipped in May 2025 with a Rust core that cut memory use by roughly 10x — finally making large documents practical in the browser. ElectricSQL made an interesting retreat: its "Electric Next" pivot strips out client-side CRDTs entirely and streams Postgres tables directly to clients via a server-side query layer. That's a bet that the sync-engine boundary belongs on the server, not in the CRDT.
Threads Worth Pursuing
- BeeKEM's formal properties: does concurrent-safe CGKA require a specific CRDT structure, or is it a general result?
- ElectricSQL's retreat: if they moved away from client-side CRDTs toward a streaming model, what does that say about where the actual developer complexity lives?
- The "Long Now" format problem: is there a meaningful analog to PDF/A (archival PDF) for structured collaborative data?
Sources: Ink & Switch 7 ideals · FOSDEM 2026 local-first devroom · Keyhive notebook · Willow protocol · Willow analysis (jzhao.xyz) · CodeCRDT paper · Local-First Conf 2026