How to Build More Resilient Local-First Applications With AT Protocol Infrastructure

Jake Lazaroff built a travel planning app on a managed sync server. A year later the provider was acquired and shut down. The app still ran locally. Multi-device sync died. Users passed files by hand. That story frames the entire argument: the server that enables collaboration also becomes the single point of failure. Lazaroff's talk at the AT Protocol summit did not propose a better sync server. It proposed removing the need for one.

The AT Protocol (atproto) is marketed as social networking infrastructure. Lazaroff reframes it as a generic distributed systems layer. Each user runs a personal data server (PDS) — storage, fine-grained auth, push updates. Applications request access. No app-specific backend required. The standard architecture includes an App View, a per-application server that mediates logic. Lazaroff calls it optional. He calls it the weaker point in the stack. His experiments cut it out entirely.

Three prototypes. Static applications. PDSs. Relays. Nothing else.

First: a collaborative text editor. YJS plus ProseMirror. Every YJS update writes a record to the author's PDS. Collaborators live in a metadata record. Peers fetch and replicate through the relay in near real time. The protocol becomes a YJS sync server without running YJS. The catch: document state fragments across many records. Interoperability suffers. Another application cannot easily reconstruct the document without understanding YJS's internal model. The protocol carries the bytes but not the semantics.

Second: a collaborative to-do list. Native CRDT records. Plain JSON — fields for type, listId, text, done, createdAt. CRDT metadata sits apart. Lazaroff argues this makes records self-explanatory. An app that ignores the metadata still sees a todo item. Last-write-wins registers per field avoid conflicts when concurrent edits touch different fields. When concurrent writes target the same record, compare-and-swap rejects the loser. The client fetches latest, merges locally, retries. The challenge: handling concurrent writes to the same record without losing updates or breaking the CRDT model. The protocol provides the atomic primitive. The application builds the retry logic.

The third experiment used atproto as an encrypted file sync layer. Each file version writes a record. The relay pushes encrypted blocks. The PDS never sees plaintext. The app handles decryption and conflict resolution locally. This pushes the trust boundary to the client — exactly where Lazaroff wants it.

The pattern across all three: the relay provides availability and ordering. It does not provide logic. It does not hold keys. It does not decide merge outcomes. That stays on device. The App View traditionally sits between relay and client, mediating schema, permissions, aggregation. Removing it means each application implements its own merge strategy. That is more work per app. It also means no single service upgrade breaks every app at once.

Lazaroff acknowledges the trade-off. Interoperability requires shared record schemas. The to-do list's plain JSON approach helps. The text editor's YJS records do not. He suggests a middle layer — not an App View, but a schema registry — could let applications discover one another's data shapes without centralising control. That idea remains unbuilt.

The deeper claim: resilience is not redundancy. It is architectural independence. A managed sync server offers operational convenience and a business model. It also creates a choke point. When that provider disappears, the application's collaborative features disappear with it. Local-first means the app works without the network. The network only improves the experience. Atproto's relay network is operated by multiple parties. No single operator can kill sync for everyone. A user can migrate PDS providers without changing applications. The protocol's identity layer (DIDs, handles) survives provider churn.

Critics will say this pushes complexity to the client. It does. Critics will say most developers want a backend they control. They do. Lazaroff's response: the backend you control is the backend that becomes your liability. The AT Protocol infrastructure already exists. It already handles auth, storage, push, replication. Using it as a generic sync fabric costs less than building and operating your own. The question is whether application developers will accept the constraint that their merge logic runs locally, not on a server they own.

The experiments are not theoretical. They run. They demonstrate that the protocol's primitives — records, repos, relays, DIDs — compose into collaborative applications without an App View. That is the proof. The rest is adoption.

If the local-first model spreads, the dominant application architecture inverts. Today: thick backend, thin client, centralised trust. Tomorrow: thick client, protocol relay, distributed trust. The server does not vanish. It becomes a commodity relay. The application becomes a local-first tool that happens to sync. When the relay fails, the tool keeps working. That is the resilience Lazaroff demonstrated. Not fault tolerance. Independence.