<>
Bluesky’s Atmosphere Protocol (ATProto) offers a foundational standard for decentralized applications, yet its current public-first architecture and proposed permissioned data models present significant friction for developers aiming to build local-first software. Discussed extensively at the Local First Conference in Berlin, the protocol successfully addresses identity management at scale, but developer adoption faces structural hurdles when managing private and offline data.
The Local-First Dilemma and Data Ownership
For developers attempting to build utility software—such as decentralized review systems to supplant proprietary platforms like Yelp or Goodreads—user privacy models dictate application viability. According to software discussions at the Berlin conference, users generally fall into three distinct categories: public influencers, hybrid users who alternate between public sharing and private logging, and private-only participants who refuse public visibility entirely.
ATProto functions inherently as a public-only protocol. Storage systems and publishing services assume that all actions broadcast globally. While the development community is actively designing “permissioned data” frameworks to address restricted access, critics argue the implementation creates unnecessary complexity. Rather than treating private data as a subset of public data with restricted read permissions—where world-read is simply one access level—the current proposals construct an entirely separate subsystem for private records.
Consequently, application developers must maintain two distinct data structures and protocols while concealing this technical split from end users. Editing a record from private to public requires deleting the legacy entry and minting an entirely new post in the public subsystem, severing existing likes, replies, and cryptographic references.
Personal Data Servers Versus Local-First Architecture
A core tenet of local-first software is user data ownership paired with offline capability. In distributed systems like Git, users clone local repositories, execute modifications offline, and synchronize changes upstream. However, ATProto’s Personal Data Server (PDS) model operates differently.
As analyzed by software architects, users do not push and pull local repository snapshots; instead, they communicate via remote API protocols with a hosted server. Although the infrastructure utilizes cryptographic integrity guarantees, the network is not optional, and local storage requires custom-built synchronization layers. Developers building offline-first applications must engineer bespoke caching and sync mechanisms to handle local states before broadcasting updates to a remote PDS.
Protocol Adaptation and Future Development
Despite architectural friction between public broadcast assumptions and local-first privacy requirements, ATProto’s identity and lexicon systems continue to attract developer interest. Because the permissioned data framework remains in early design phases, community feedback aims to bridge the gap between open identity graphs and flexible access control.
For application creators seeking interoperable standards reminiscent of 1990s internet protocols, ATProto represents a viable foundational layer, provided upcoming protocol revisions accommodate seamless privacy controls without forcing developers to maintain parallel application stacks.
Worth a look