AT Protocol as backend: 3 experiments beyond Bluesky

Key Takeaways

• AT Protocol's Personal Data Servers can serve as generic backend infrastructure, not just social networking plumbing
• Three working experiments demonstrate collaborative text editing, CRDT-based to-do lists, and WebRTC signaling without custom App Views
• The architecture trades app-specific control for resilience against provider shutdowns and single points of failure

AT Protocol, the decentralized infrastructure behind Bluesky, can serve as a general-purpose backend for local-first applications. Developer Jake Lazaroff demonstrated this at a recent conference, building three working prototypes that bypass traditional app-specific servers entirely. His experiments suggest a path for developers tired of watching their sync providers get acquired and shut down.

Why atproto instead of a custom backend?

Lazaroff opened with a familiar pain point. He built a travel planning app during a sabbatical, using YJS with a managed sync server. A year later, the sync provider was acquired and killed. The app still worked offline, but multi-device sync broke. His fallback? Manual file passing.

This is the core tension in collaborative software. The server that enables syncing across devices becomes the single point of failure. When it dies, so does the network effect that made the app useful.

AT Protocol offers a different model. Instead of each app maintaining its own siloed backend, users store data in Personal Data Servers (PDSs). Applications request access to that data. The PDS handles storage, authentication, and push updates. Relays propagate changes across the network. Multiple independent PDS hosts already exist, along with free public relays.

The key architectural move: Lazaroff treats the App View, a per-app server in standard atproto architecture, as optional. His experiments run on static applications plus PDSs and relays. No custom backend required.

Experiment 1: Collaborative text editing with YJS

The first prototype was a collaborative text editor using YJS and ProseMirror. Each YJS update gets written as a record to the user's own PDS. Collaborators are listed in a metadata record. Peers fetch and replicate each other's updates through the relay in near real-time.

Lazaroff described this as effectively using atproto as a YJS sync server. The tradeoff: document state spreads across many records, which complicates interoperability with other applications. If another app wants to read that document, it needs to understand your specific record structure.

Experiment 2: CRDT-based to-do lists

The second experiment took a different approach. Instead of wrapping an existing CRDT library, Lazaroff used native CRDT records. The records are plain JSON with fields like `$type`, `listId`, `text`, `done`, and `createdAt`. CRDT metadata attaches separately.

This design makes records self-explanatory. An app that ignores the CRDT metadata can still read the to-do items. Last-write-wins registers handle each field, avoiding conflicts when concurrent edits touch different properties. When two users edit the same record simultaneously, compare-and-swap logic rejects the second write. The client fetches latest state, merges locally, and retries.

The interoperability here is cleaner than the YJS approach. Any app can read your to-do list without understanding proprietary sync formats.

Experiment 3: WebRTC signaling via atproto

The third prototype pushed atproto further: video chat signaling. One peer writes ICE candidate records to a PDS naming the intended recipient. The other peer listens through the relay and responds. The peers then establish a direct WebRTC connection.

During the live demo, conference Wi-Fi forced a fallback to TURN relay. Lazaroff called it the "TURN server of shame," but the architecture held. He suggested WebRTC data channels could complement atproto for real-time transport in local-first apps.

What this means for the atproto ecosystem

Bluesky now has roughly 20 million users, proving AT Protocol can scale. An estimated 2,000 independent PDSs run on the network. The infrastructure already exists for experiments like Lazaroff's.

The argument is straightforward: build on shared infrastructure rather than per-app servers. Servers should remain simple, generic, and fungible. If one PDS host shuts down, users migrate to another. If one relay disappears, others remain.

This doesn't solve every problem. Network traversal remains messy. CRDT conflict resolution has edge cases. The record format decisions you make early will follow you. But for teams building collaborative tools, the alternative is building your own sync infrastructure or betting on a provider that might not exist next year.

Open questions

Conference attendees pushed back on several fronts. How do you handle access control for sensitive data? What happens when CRDT metadata bloats over time? How do you debug sync issues across multiple PDSs?

Lazaroff acknowledged these remain active problems. AT Protocol provides primitives. Building reliable applications on those primitives requires new patterns that the community is still discovering.

Frequently Asked Questions

What is AT Protocol used for beyond Bluesky?

AT Protocol provides decentralized storage, authentication, and sync infrastructure. Developers can use it for collaborative apps, data portability, and any application where users should own their data rather than a single provider.

How does AT Protocol handle offline-first scenarios?

Users store data in Personal Data Servers (PDSs). Apps can read and write locally, then sync through relays when connectivity returns. The architecture separates local storage from network propagation.

Can AT Protocol replace Firebase or Supabase?

For certain use cases. AT Protocol handles storage, auth, and sync, but lacks built-in features like serverless functions or managed databases. It trades convenience for resilience and data portability.

What are CRDTs and why do they matter for atproto?

Conflict-free Replicated Data Types allow multiple users to edit data concurrently without coordination. Lazaroff's experiments used CRDTs to merge edits from different users without a central server resolving conflicts.

Source: InfoQ