Authors:
(1) Martin Kleppmann, University of Cambridge, Cambridge, UK (martin.kleppmann@cst.cam.ac.uk);
(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. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Martin Kleppmann, University of Cambridge, Cambridge, UK (martin.kleppmann@cst.cam.ac.uk); (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. Authors: Authors: (1) Martin Kleppmann, University of Cambridge, Cambridge, UK (martin.kleppmann@cst.cam.ac.uk); (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 Abstract and 1 Introduction 2 The Bluesky Social App 2 The Bluesky Social App 2.1 Moderation Features 2.1 Moderation Features 2.2 User Handles 2.2 User Handles 2.3 Custom Feeds and Algorithmic Choice 2.3 Custom Feeds and Algorithmic Choice 3 The at Protocol Architecture 3 The at Protocol Architecture 3.1 User Data Repositories 3.1 User Data Repositories 3.2 Personal Data Servers (PDS) 3.2 Personal Data Servers (PDS) 3.3 Indexing Infrastructure 3.3 Indexing Infrastructure 3.4 Labelers and Feed Generators 3.4 Labelers and Feed Generators 3.5 User Identity 3.5 User Identity 4 Related Work 4 Related Work 5 Conclusions, Acknowledgments, and References 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. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

How AT Protocol Repositories Secure and Store User Actions

The AT Protocol Architecture

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Advancements in Memes Analysis: Scene Graphs and Multimodal Approaches

Be Happy on Social Media Again!

blue(sky)print

How to Decentralize Twitter

How Web3 Can Empower Users and Communities in Social Media

Twitter Bluesky: A Decentralized Protocol Proposal

Advancements in Memes Analysis: Scene Graphs and Multimodal Approaches

Be Happy on Social Media Again!

blue(sky)print

How to Decentralize Twitter

How Web3 Can Empower Users and Communities in Social Media

Twitter Bluesky: A Decentralized Protocol Proposal

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps