Jump to content

AT Protocol

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Pnh (talk | contribs) at 00:56, 6 September 2024 (Adoption: grammar nitpick: changed "not ran by Bluesky Social" to "not run by Bluesky Social"). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
AT Protocol
Communication protocol
The logo of the AT Protocol, depicting an at sign colored in with an image of a blue sky.
PurposeDecentralized social networking
Developer(s)Bluesky PBC
IntroductionOctober 18, 2022; 2 years ago (2022-10-18)
Port(s)80, 443
Websiteatproto.com

The AT Protocol (Authenticated Transfer Protocol, commonly shortened to atproto)[1][2] is a protocol and open standard designed for building federated social networking services.[3] It is currently under development by Bluesky Social PBC, a public benefit corporation that was originally created as an independent research group for Twitter to investigate the possibility of decentralization,[4] and powers its Bluesky social network.[5][6]

The protocol has been designed to address perceived issues with other decentralized protocols, addressing account portability of user data and social graphs, as well as platform interoperability and customizable algorithms. Bluesky Social has promised to transfer development of the protocol to a standards body such as the IETF in the future, as declared by CEO Jay Graber.[7]

Design

A diagram of the AT Protocol federation architecture as of February 2024.

The AT Protocol aims to create a decentralized, interoperable, and scalable online ecosystem where users can retain and manage a single federated online identity across various online platforms and services. The protocol's design prioritizes discoverability and an integrated, customizable, user-centric online experience. Bluesky Social describes the protocol as being "modeled after the open web itself".[8]

Compared to other protocols for social networking such as ActivityPub, where implementations are typically designed as a monolithic server that hosts both user data and the application, it splits up these elements into smaller microservices, which can be used as needed.

AT Protocol clients and services interoperate through an HTTP API called XRPC that primarily uses JSON for data serialization.[9]

User identity

The AT Protocol utilizes a dual identifier system: a mutable domain name handle and an immutable decentralized identifier (DID). Handles serve as user-end identifiers and are verified by querying a domain's resource records. DIDs resolve to DID documents, which contain references to key user metadata, such as the user's handle, public keys, and data repository.[10]

Services can assign handles to new users upon signup using subdomains (e.g. @username.bsky.social). Alternatively, users can set a custom domain or subdomain as their handle (e.g. @username.com or @username.wikipedia.org) by adding a TXT record to the domain's records associating the domain or subdomain to the user's DID.[11]

AT Protocol's identity infrastructure.

The protocol's dual identifier system provides both user-friendly identifiers for use in end-user services and consistent cryptographic identities within the protocol, while also providing a robust TCP/IP-based account verification mechanism at the protocol level.

User data repositories

User data within the protocol is stored in dedicated data repositories. Each user is associated with a single repository, over which they have exclusive management rights. Repositories contain mutable collections of records which represent user actions such as posts, likes, follows, and blocks. Records are persistent and can only be added or removed at the explicit request of the user.[12]

Repositories do not themselves contain media files such as images or videos uploaded by the user, instead storing references to the associated media files within the server.[3]

Repositories and their associated media are designed to be fully migrated between host servers by users with no loss of data, even in the event of an adversarial host server. Users can also choose to back up their repositories and media in a secondary server.[13]

Personal Data Servers

Personal Data Servers (PDSes) host user repositories and their associated media. They also serve as the network access point for users, facilitating repository updates, backups, data queries, and user requests.[8]

Users access the protocol by querying their PDSes, which, in turn, fetch the requested data from other services within the network. This design differs from ActivityPub, where interactions and services are typically handled by monolithic hosting providers. Since repository updates are resolved through the protocol's network-wide indexing infrastructure, PDSes are largely inconsequential to the user experience.[14]

The design of PDSes within the protocol results in low computational requirements for operation, allowing individuals or groups to run their own PDSes without the need for significant computational resources.[3]

Although most users' repositories reside in PDSes ran by Bluesky Social, many independent PDSes exist within the network.[15]

Relays and the firehose

Relays are a key component of the protocol's indexing infrastructure, serving as the core indexers within the network.[8] Relays crawl the network by continuously fetching repository updates from PDSes before aggregating, indexing, and forwarding these updates into a single network-wide data stream called the firehose.[16] The firehose is available to all network agents, and can be consumed by any service within the network.[3] Relays can choose to index all or part of the network.[8]

Relays simplify the development and reduce the computational overhead of applications and services in the protocol by enabling efficient access to network updates through the firehose and eliminating the need to store user data or crawl individual PDSes.[17]

Relays have been criticized as being the most centralized component in the protocol's design, given their near-indispensable role in the network, high computational overhead, and the lack of clear incentives for running a relay. Bluesky Social currently operates all known relays in the network.[18][19]

App Views

App Views, analogous to current-day social networking services, are end-user platforms and services within the protocol that consume, process, and deliver data from the relay in response to queries from users' PDSes. They utilize network-wide information from the firehose, such as posts, likes, follows, and replies, to create customized user experiences within their clients.[3]

The design of App Views within the protocol allows for significant variation in their implementations. App Views can implement invite systems, custom algorithms, varying monetization and content moderation strategies, and additional off-protocol services.[20] Despite these differences, all App Views operate from the same data sourced from the firehose. This architecture reduces the computational load and storage requirements of App Views, and prevents user lock-in by enabling users to easily switch between App Views while retaining their posts, follows, likes, etc.[21]

The largest App View on the protocol is currently Bluesky, although other App Views, such as WhiteWind (a long-form blogging platform) and Smoke Signal (an RSVP management service) are also available within the protocol.[22][23]

Lexicons

All posts within the protocol follow a specific schema language called a lexicon to support different social media modalities.[24] For example, a microblogging App View would use a different lexicon than a long-form video content App View, as their content requires different sets of attributes.

App Views have the flexibility to either define a unique lexicon for their service, or serve content from one or multiple existing lexicons.[25] This approach allows App Views to design and create new lexicons tailored to their specific use case while maintaining compatibility with the broader network. Additionally, App Views can utilize previously defined lexicons to serve content that is already available within the network, even if the content was originally posted from a different App View.[26]

The most popular lexicon in the protocol, app.bsky, defines Bluesky's microblogging schema.[25]

Opinionated services

Opinionated services are services within the protocol that process data from the firehose to provide subjective judgements on network data for the purposes of content moderation and curation. These services contrast with the intended "unopinionated" nature of relays and App Views.[3] Opinionated services enable users to customize their content consumption and moderation preferences within the protocol while maintaining the neutrality of the protocol's core components.

Users have the ability to subscribe and unsubscribe to these services at any time through their client app (unless they are hard-coded into the user's current App View.)[20] The modularity of these services allows for a customizable, stackable, user-centric approach to content curation and moderation within the protocol.[27]

Labelers

Labelers produce judgements about user-generated content, such as identifying spam or inappropriate material. These labels can be applied to various aspects of the network, including posts, images, or accounts. The output of labelers is consumed by App Views and PDSes, which can then provide various strategies to users for handling labeled content, such as hiding, labeling, or blurring.[28]

Bluesky Social has open-sourced its internal labeler moderation service "Ozone", allowing users to create custom moderation services for the network.[29][27]

Although labelers can be used as a moderation service, they can also serve informational or entertainment purposes, such as labeling a user's pronouns, post topics, or adding positive or playful labels to user profiles and posts.[30]

Feed generators

Feed generators process posts within the firehose for inclusion in custom feeds. They return a list of post IDs to a user's App View, which can then be used to create curated feeds.[31][32]

Adoption

The protocol's reference implementation was first released to GitHub on May 4, 2022 under the name Authenticated Data Experiment (ADX), and is licensed under both the MIT and Apache licenses.[33] It rebranded to the AT Protocol in October 2022.[34]

The AT Protocol has been adopted for use by the Bluesky social network (also developed by Bluesky Social PBC), and is its most popular implementation. The social network itself opened federation with other Personal Data Servers in late February 2024, as it had launched without the ability to federate with other servers not run by Bluesky Social.[35] Additionally, the news aggregator Flipboard allows users to login with their Bluesky account to view and interact with posts from the service.[36] To aid adoption, Bluesky Social funds various projects that use the AT Protocol for federating and/or creating content via grants.[37] A notable application funded by the grants is a proxy server known as SkyBridge, which can convert API calls from Mastodon apps to their equivalent AT Protocol/Bluesky APIs, allowing users to have access to both networks even without official support.[38]

While the AT Protocol is a separate protocol with no major technical similarities to other protocols, there have been services developed that can bridge content across protocols. An example is the Bridgy Fed software, which can crosspost content between ActivityPub and the AT Protocol.[39][40] Posts from Nostr can also be "double-bridged" to the AT Protocol via another bridge that can crosspost notes from Nostr to ActivityPub.[41]

See also

References

  1. ^ "The AT Protocol". Bluesky. Retrieved 2024-07-30.
  2. ^ "Building on the AT Protocol | Bluesky". docs.bsky.app. 2023-10-11. Retrieved 2024-09-05.
  3. ^ a b c d e f Kleppmann, Martin; Frazee, Paul; Gold, Jake; Graber, Jay; Holmgren, Daniel; Ivy, Devin; Johnson, Jeromy; Newbold, Bryan; Volpert, Jaz (2024-02-05), Bluesky and the AT Protocol: Usable Decentralized Social Media, arXiv:2402.03239
  4. ^ Robertson, Adi (2022-10-29). "Will Elon Musk keep funding Twitter's most interesting side project?". The Verge. Retrieved 2024-07-31.
  5. ^ Robertson, Adi (2019-12-11). "Twitter is funding research into a decentralized version of its platform". The Verge. Retrieved 2024-07-30.
  6. ^ Conger, Kate (2022-03-02). "Twitter Wants to Reinvent Itself, by Merging the Old With the New". The New York Times. ISSN 0362-4331. Retrieved 2024-07-31.
  7. ^ Patel, Nilay (2024-03-25). "Bluesky CEO Jay Graber on breaking free from Twitter and competing with Threads and Mastodon". The Verge. Retrieved 2024-08-04.
  8. ^ a b c d "Federation Architecture | Bluesky". docs.bsky.app. Retrieved 2024-09-05.
  9. ^ "HTTP API (XRPC) | AT Protocol". atproto.com. Retrieved 2024-09-05.
  10. ^ "Identity | AT Protocol". atproto.com. Retrieved 2024-09-05.
  11. ^ "Domain Names as Handles in Bluesky". Bluesky. Retrieved 2024-09-05.
  12. ^ "Personal Data Repositories | AT Protocol". atproto.com. Retrieved 2024-09-05.
  13. ^ "Repository | AT Protocol". atproto.com. Retrieved 2024-09-05.
  14. ^ "PDS Entryway | Bluesky". docs.bsky.app. Retrieved 2024-09-05.
  15. ^ "2024 Protocol Roadmap | Bluesky". docs.bsky.app. 2024-05-06. Retrieved 2024-09-05.
  16. ^ "Firehose | Bluesky". docs.bsky.app. Retrieved 2024-09-05.
  17. ^ "The AT Protocol Developer Ecosystem". Bluesky. Retrieved 2024-09-05.
  18. ^ "AT Protocol - First Thoughts - Rusted Gears - Obsidian Publish". publish.obsidian.md. Retrieved 2024-09-05.
  19. ^ Schulman, Rory Mir and Ross (2024-06-18). "What's the Difference Between Mastodon, Bluesky, and Threads?". Electronic Frontier Foundation. Retrieved 2024-09-05.
  20. ^ a b "Moderation in a Public Commons". Bluesky. Retrieved 2024-09-05.
  21. ^ "What is Bluesky?". Bluesky. Retrieved 2024-09-05.
  22. ^ "WhiteWind atproto blog | WhiteWind blog". whtwnd.com. Retrieved 2024-09-05.
  23. ^ "Why atprotocol? | Smoke Signal". docs.smokesignal.events. Retrieved 2024-09-05.
  24. ^ "Protocol Overview | AT Protocol". atproto.com. Retrieved 2024-09-05.
  25. ^ a b "Lexicon | AT Protocol". atproto.com. Retrieved 2024-09-05.
  26. ^ "Bluesky: An Open Social Web". Bluesky. Retrieved 2024-09-05.
  27. ^ a b "Bluesky's Stackable Approach to Moderation". Bluesky. Retrieved 2024-09-05.
  28. ^ "Labeling and Moderation Controls". GitHub. Retrieved 2024-09-05.
  29. ^ Ozone: labeling service for Bluesky and other atproto apps, bluesky-social, 2024-09-05, retrieved 2024-09-06
  30. ^ "Labeling and Moderation Controls". GitHub. Retrieved 2024-09-06.
  31. ^ "Custom Feeds | Bluesky". docs.bsky.app. Retrieved 2024-09-05.
  32. ^ ATProto Feed Generator, bluesky-social, 2024-09-05, retrieved 2024-09-06
  33. ^ Robertson, Adi (2022-05-04). "Twitter's decentralized, open-source offshoot just released its first code". The Verge. Retrieved 2024-07-31.
  34. ^ Pierce, David (2022-10-19). "Bluesky built a decentralized protocol for Twitter — and is working on an app that uses it". The Verge. Retrieved 2024-08-04.
  35. ^ Khalid, Amrita (2024-02-22). "Bluesky starts letting users host their own servers". The Verge. Retrieved 2024-08-04.
  36. ^ Davis, Wes (2023-05-23). "Flipboard is ready to work with Bluesky and Pixelfed". The Verge. Retrieved 2024-08-01.
  37. ^ Perez, Sarah (2024-03-11). "Bluesky is funding developer projects to give its Twitter/X alternative a boost". TechCrunch. Retrieved 2024-08-01.
  38. ^ Perez, Sarah (2024-04-25). "Bluesky backs a project that would let Mastodon apps, like Ivory, work with its network". TechCrunch. Retrieved 2024-08-09.
  39. ^ Perez, Sarah (2024-06-05). "Bluesky and Mastodon users can now talk to each other with Bridgy Fed". TechCrunch. Retrieved 2024-08-04.
  40. ^ Silberling, Amanda (2024-02-14). "Bluesky and Mastodon users are having a fight that could shape the next generation of social media". TechCrunch. Retrieved 2024-08-04.
  41. ^ Perez, Sarah (2024-05-21). "The 'vote Trump' spam that hit Bluesky in May came from decentralized rival Nostr". TechCrunch. Retrieved 2024-08-04.

Further reading