Authors:
(1) Martin Kleppmann, University of Cambridge, Cambridge, UK ([email protected]);
(2) Paul Frazee, Bluesky Social PBC United States;
(3) Jake Gold, Bluesky Social PBC United States;
(4) Jay Graber, Bluesky Social PBC United States;
(5) Daniel Holmgren, Bluesky Social PBC United States;
(6) Devin Ivy, Bluesky Social PBC United States;
(7) Jeromy Johnson, Bluesky Social PBC United States;
(8) Bryan Newbold, Bluesky Social PBC United States;
(9) Jaz Volpert, Bluesky Social PBC United States.
Table of Links
Abstract and 1 Introduction
2 The Bluesky Social App
2.1 Moderation Features
2.2 User Handles
2.3 Custom Feeds and Algorithmic Choice
3 The at Protocol Architecture
3.1 User Data Repositories
3.2 Personal Data Servers (PDS)
3.3 Indexing Infrastructure
3.4 Labelers and Feed Generators
3.5 User Identity
4 Related Work
5 Conclusions, Acknowledgments, and References
3 THE AT PROTOCOL ARCHITECTURE
Bluesky is the social app with the features explained in Section 2, while the AT Protocol is the underlying decentralized foundation. We maintain this separation because the AT Protocol is designed to support multiple social modes, not just Bluesky. For example, besides a Twitter-style microblogging app, atproto could also be used to implement Reddit-style forums, long-form blogs with comments, or domain-specific social applications such as link sharing or book reviews. The same user identity, social graph, and user data storage servers can be shared between all of these apps.
The data types and concepts for a particular social mode are defined by a lexicon, which specifies the schema of the data and the request endpoints involved in providing that social mode [7]. At the moment, the com.atproto lexicon defines the core AT Protocol concepts such as user identity (Section 3.5), and the app.bsky lexicon defines the microblogging mode. Anyone can define a new lexicon, allowing new social modes to coexist alongside the Bluesky social app on a shared infrastructure. The purpose of a lexicon is to provide documentation, to allow code generation and type-checking in applications, and to facilitate the process of specifying and versioning an interoperable protocol.
The biggest constraint for new social modes is that atproto is currently designed for content that users want to make publicly available. In particular, Bluesky user profiles, posts, follows, and likes are all public. Blocking actions are also currently public; however, we are investigating mechanisms for making these private [16, 41]. At present, Bluesky does not support private communications, such as direct messages, though we plan to add this in the future. Only a small amount of user state is currently private: any muted accounts and threads, notifications and their read/unread status, and user preferences such as pinned feeds and content filtering settings.
