Jake Lazaroff presented a talk arguing that the AT Protocol (atproto) could be used as a foundation for distributed applications, rather than only as infrastructure for social networking. The session focused on a local-first architecture in which users stored their own data in personal data servers (PDSs), while applications used shared protocol infrastructure for storage, authorisation, synchronisation, and updates. His central claim was that the AT Protocol could reduce dependence on app-specific backend services and help avoid single points of failure.
Lazaroff opened with a story from a travel planning app he had built during a sabbatical. The app used YJS together with a managed sync server. Roughly a year later, the sync provider was acquired and shut down. The app still worked locally, but multi-device synchronisation no longer worked, leaving manual file passing as the fallback. He used that example to illustrate the broader tension between collaborative infrastructure and resilience: the same server that enabled syncing across devices also became the application’s weakest dependency.
He then described atproto as an alternative architectural model. Instead of each app maintaining its own siloed backend, each user kept data in a PDS and granted apps access to it. In this model, the PDS provided storage, fine-grained authentication, and push updates. Lazaroff described the App View, a bespoke per-app server in the standard atproto architecture, as optional and as the weaker point in the stack.
The main body of the talk covered three experiments that removed the App View entirely and relied only on static applications, PDSs, and relays. In the first, Lazaroff built a collaborative text editor using YJS and ProseMirror. Each YJS update was written as a record to the user’s own PDS. Collaborators were listed in a metadata record, and peers fetched and replicated one another’s updates through the relay in near real time. He said this effectively used atproto as a YJS sync server. The main challenge in this approach was that document state was spread across many records, which made interoperability with other apps harder.
The second experiment implemented a collaborative to-do list using native CRDT records. The records were plain JSON objects containing fields such as `$type`, `listId`, `text`, `done`, and `createdAt`, with CRDT metadata attached separately. Lazaroff argued that this made the records self-explanatory, even for applications that ignored the CRDT metadata. The design used last-write-wins registers for each field, which avoided conflicts when concurrent edits touched different fields. When concurrent writes targeted the same record, compare-and-swap logic rejected the write, after which the client fetched the latest state, merged locally, and retried. The main challenge in this case was handling concurrent writes to the same record without losing updates or breaking the CRDT model.
In the third experiment, Lazaroff used atproto as a signalling mechanism for WebRTC video chat. One peer wrote ICE (Interactive Connectivity Establishment) candidate records to a PDS naming the intended recipient, the other peer listened through the relay and responded, and the peers then established a direct WebRTC connection. During the live demonstration, conference Wi‑Fi conditions required the use of a TURN (Traversal Using Relays via NAT) relay, which he referred to as a "TURN server of shame." He also suggested that WebRTC data channels could complement atproto by providing real-time transport for local-first applications. The main challenge here was network traversal, since unreliable conference connectivity prevented a clean, direct peer-to-peer connection and forced fallback to TURN infrastructure.
Across the talk, Lazaroff argued that developers should build on shared infrastructure rather than on per-app servers. He cited the idea that servers should remain simple, generic, and fungible. He pointed to multiple independent PDS hosts, free public relays, and community-supported aggregation efforts as signs that atproto already supported that direction. In the closing discussion, audience questions centred on the trade-offs of interoperability, synchronisation, and WebRTC deployment. The key takeaway remained consistent throughout the talk: atproto was presented as a viable foundation for distributed applications, not only for social platforms.