Building on ATProto: Challenges in Private Data and Local-First Design
Building on ATProto: Challenges in Private Data and Local-First Design
ATProto's current design creates a divide between public and private data
ATProto is currently built as a public-only protocol, meaning it assumes all user activity is intended for global visibility. While the community is developing a "permissioned data" specification to handle private information, the current proposal treats public and private data as two distinct systems rather than different access levels of the same data type. This forces developers to essentially build two separate applications—one for public data and one for private—and manually bridge the gap to maintain a seamless user experience.
The flaw in the "Permissioned Data" approach
According to developer Luke Kanies, the fundamental mistake in the current design is the assumption that public broadcast data is substantially different from permissioned data. Kanies argues that a piece of data, such as a restaurant review, remains the same regardless of whether it is shared with a spouse, a small group, or the entire world.
Under the proposed system, moving a private post to the public sphere is not a simple permission change but requires deleting the record in the private subsystem and recreating it in the public one. This creates significant technical friction regarding the preservation of likes, reposts, and links.
ATProto is not "Local-First" by design
Despite its popularity among the local-first community, ATProto does not adhere to the core principles of local-first software, specifically regarding data ownership and offline availability.
Server-centric data ownership
While ATProto claims users "own" their data via the Personal Data Server (PDS), this is a server-client relationship rather than a local-repository model. Unlike Git, where a user has a full local copy of their data and pushes changes to a server, ATProto users interact with a remote server via a protocol. Ownership is defined by the ability to move data between servers and the fact that the protocols are public, but the data does not reside "at the user's fingertips."
Offline support requirements
Because the network is not optional in ATProto's core architecture, developers wishing to provide offline support must build their own custom local storage and synchronization systems. When combined with the proposed permissioned data split, this adds layers of complexity:
- Custom local storage for offline data.
- Custom sync systems to move data to the PDS.
- Separate sync protocols for public versus private data.
- Separate read/write systems for online usage.
Community Perspectives and Counterpoints
Discussion among developers reveals a divide on whether ATProto should attempt to solve the private data problem or remain a public-only tool.
The argument for public-by-default
Some developers argue that ATProto's primary value is its public nature. If data were private or encrypted by default, the "utility and comfort" of trying new services would vanish, as data would die with a failing startup rather than being available for a successor application to build upon.
The trade-off of complexity
Contributors to the protocol have noted that engineering involves trade-offs. One contributor (@pfraze) mentioned that while they would have loved to make ATProto a local-first protocol, they had to "pick & choose where to spend our complexity budget" for version 1. They suggested that developers could use external tools like iroh in conjunction with ATProto to handle local sync meshes before committing state to the ATProto repository.
Alternative implementations
Some developers have found success using ATProto for specific public-facing use cases, such as board game communities or web-of-trust forums, where the ability to extend an application without adding a custom API is a primary benefit. Others suggest that if a robust identity and access management (IAM) system is required, a ReBAC/Zanzibar-style system might be more appropriate than the current permissioned data proposal.
Summary of Technical Friction
| Feature | ATProto Current State | Local-First/Private Requirement |
|---|---|---|
| Data Model | Public-only / Split Public-Private | Unified data with access control |
| Storage | Remote PDS (Server-client) | Local-first (Client-side ownership) |
| Connectivity | Network required for core functions | Network-optional / Offline-first |
| Identity | Strong, scalable identity system | Integrated with private data flows |