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

Olimpiu Pop · rss · 2026-07-13 source ↗ Reader 🖥️

AT Protocol's personal-data-server-plus-relay infrastructure can serve as a general-purpose, resilient foundation for local-first distributed applications of any kind, not only social networking, by letting apps offload storage, sync, and auth to shared, fungible infrastructure instead of fragile app-specific backend servers.

practical · mixed — Secondhand conference-talk reporting: Olimpiu Pop (InfoQ) recounts a talk by Jake Lazaroff. The piece is structured as narrative (a cautionary anecdote, three build experiments) in service of an argumentative/practical recommendation (build distributed apps on shared atproto infrastructure instead of per-app backends). Claims are Lazaroff's as filtered through the reporter; the reporter adds no independent scrutiny of them.

Structure

Part	Role
Opening claim	thesis statement
Waypoint travel-app anecdote (managed YJS sync vendor acquired and shut down)	motivating narrative / problem case
Description of atproto architecture (PDS, App View optional and fragile)	conceptual framework
Three build experiments: collaborative text editor (YJS+ProseMirror), collaborative to-do list (native CRDT records), WebRTC video chat signalling	evidence / proof-of-concept
Closing argument for shared/generic/fungible infrastructure + audience Q&A mention	conclusion, with a nod to unresolved trade-offs

Key terms

PDS (personal data server)
A user-owned, protocol-standardized data store that apps read/write to via shared atproto infrastructure, replacing app-specific backend storage as the place where a user's data lives.
App View
The optional, bespoke per-app server layer in the standard atproto stack, singled out as the weakest, least resilient part of the architecture and the thing all three experiments deliberately remove.
local-first Local-First Software
Here narrowed to mean specifically: user data lives in a PDS and apps sync via shared atproto infrastructure, as opposed to the broader local-first movement's general principle of offline-capable apps that own their local data.
fungible (infrastructure)
Servers/hosts that are simple, generic, and interchangeable — any PDS host or relay can substitute for another without breaking the app — contrasted with purpose-built, irreplaceable backend services.

Propositions

explicitAT Protocol can serve as a general foundation for distributed applications, not only for social networking.
explicitdevelopedStoring sync-critical application state in a managed, centralized backend service creates a single point of failure that can silently break the app when the vendor is acquired or shut down.conf: high
extends ←Presentation: Understanding Progressive Collapse: How To Avoid A Cascading Failure · p5 — Extends the single-point-of-failure critique of a centralized backend to any shared dependency — identical code, shared vendor infrastructure — as a general interconnection-based blast-radius risk.
explicitThe App View, the bespoke per-app server in the standard atproto architecture, is optional and is the weakest point in the stack.
explicitA collaborative rich-text editor can be built using atproto as a YJS sync transport, with CRDT updates written as records to the user's PDS and replicated to collaborators via the relay.conf: high
explicitSplitting document state across many small PDS records improves per-user data ownership but makes interoperability with other apps harder.conf: medium
explicitUsing native, self-describing CRDT JSON records (with fields like $type, listId, text, done, createdAt) rather than opaque CRDT blobs lets other apps read and use the data even if they ignore the CRDT metadata.conf: high
explicitField-level last-write-wins registers combined with compare-and-swap-and-retry on writes is a workable conflict-handling strategy for collaborative apps built on atproto records.conf: high
explicitatproto's PDS-plus-relay infrastructure can be used purely as a signalling channel to establish direct WebRTC peer-to-peer connections.conf: high
implicitReal-world network conditions (NAT/firewall traversal) can still require a centralized TURN relay fallback even in a nominally decentralized, PDS-based signalling design.conf: high
explicitDevelopers should prefer building on shared, generic, fungible infrastructure over per-app bespoke backend servers.

Arguments

AT Protocol is a viable general-purpose foundation for local-first distributed applications, not just social platforms. strength: medium

Explicit premises:

The Waypoint travel-app's managed sync vendor was acquired and shut down, breaking multi-device sync while local use kept working — demonstrating the fragility of app-specific backend dependencies.
Three separate experiments (collaborative text editor, collaborative to-do list, WebRTC signalling) show that core app functions — real-time sync, structured CRUD with conflict handling, and peer connection signalling — can be implemented using only a PDS and a relay, without an App View.
Multiple independent PDS hosts, free public relays, and community-supported aggregation efforts already exist, evidencing that the infrastructure is already somewhat fungible in practice.

Implicit premises:

Removing a custom backend server reduces the number of things that can fail or be discontinued, and this reduction in surface area is itself equated with increased resilience — a causal link that is asserted rather than demonstrated.
The interoperability, performance, and security properties shown in small prototypes will hold up at production scale — an assumption never tested or addressed in the piece.
The relay/PDS ecosystem itself will remain healthy, funded, and available over time — the article never turns the same scrutiny it applies to the shut-down commercial sync vendor onto atproto's own infrastructure providers.

Inferences:

If the App View can be made optional, atproto's architecture is not inherently tied to social-networking use cases and can generalize to arbitrary local-first app categories — implied by the experiments but stated more confidently by the article's framing than the evidence (three small demos) directly supports.

Narratives

Lazaroff built a travel-planning app (Waypoint) during a sabbatical using YJS with a managed sync server; about a year later the sync provider was acquired and shut down, breaking multi-device sync while the app kept working locally, leaving manual file-passing as the only fallback.
→ Motivating anecdote that establishes the problem — vendor dependency as a single point of failure — which the rest of the talk's atproto-based architecture is proposed to solve.
During the live WebRTC demo, unreliable conference Wi-Fi prevented a clean direct peer-to-peer connection, forcing fallback to a TURN relay, which Lazaroff jokingly called a 'TURN server of shame.'
→ A self-deprecating admission that quietly undercuts the talk's decentralization framing — even the most 'peer-to-peer' of the three experiments needed centralized relay infrastructure to work reliably in practice.

Questions addressed

✅ Can AT Protocol be used as general infrastructure for non-social distributed apps?
Reported as yes, per Lazaroff: three experiments (text editor, to-do list, WebRTC signalling) show core patterns working without an App View.
✅ How should concurrent writes to the same underlying record be reconciled without an app-specific backend to arbitrate?
Field-level last-write-wins registers plus compare-and-swap-and-retry on conflicting writes.
⭕ What happens to cross-app interoperability when application state is split across many small protocol records instead of centralized in one app-controlled database?
Named as 'the main challenge' of the first experiment but left unresolved in the text.
⭕ What are the security, performance, and cost trade-offs of running production apps on public PDS hosts and relays versus dedicated backends?
⭕ Who bears the responsibility and cost of keeping 'free public relays' available and healthy at scale, and is that itself a new single point of failure?

Gaps

incompleteThe piece never addresses production-readiness concerns — the security model of PDS access grants, the cost and scaling behavior of relay infrastructure under real-world traffic, or how 'free public relays' stay funded and available — despite building its entire resilience argument on a comparison to a shut-down commercial sync vendor.
Read next: Look at atproto's own specs/documentation on PDS auth scopes (OAuth-style grants) and relay economics, or follow-up writeups/benchmarks of atproto apps actually running in production (not conference demos), to test whether the resilience claim holds beyond prototypes.
incompleteThe 'TURN server of shame' moment is reported almost as a joke, but it is evidence against the article's throughline: even the most 'decentralized' of the three experiments needed a centralized relay to work reliably under real network conditions. The piece never examines what this implies for the resilience claims behind the other two experiments — do PDS/relay availability guarantees actually hold up better than the vendor infrastructure the talk criticizes?
Read next: Investigate whether atproto relays and PDS hosts have documented uptime/SLA characteristics, or whether they carry the same vendor-dependency risk the talk criticizes — i.e., is the central risk (single point of failure) actually eliminated, or just relocated to a different, still-centralized operator?
incompleteThe interoperability cost of experiment 1 (document state spread across many records) is explicitly named as 'the main challenge,' but the article reports no proposed resolution, design pattern, or even acknowledgment from Lazaroff of how the tension between fine-grained per-user data ownership and cross-app interoperability might be architecturally resolved.
Read next: Look for Lazaroff's own materials (talk recording, slides, blog posts) or atproto community discussion on record/schema design patterns that balance granular ownership with interoperability — a known distributed-systems trade-off worth connecting to the persona's architecture and distributed-systems interests.
uninformedAs InfoQ reporting on a talk rather than the talk itself or Lazaroff's own writing, the article gives no real content from the audience Q&A beyond naming three topic areas ('trade-offs of interoperability, synchronisation, and WebRTC deployment') — it is unclear whether anyone directly challenged the core resilience claim (e.g., whether a PDS host is itself just another centralized dependency).
Read next: Find the original talk recording or Lazaroff's own blog/notes to see the actual Q&A content and whether the 'shared infra reduces single points of failure' claim was scrutinized directly by the audience.