What we think about AT Protocol

The AT Protocol is the most recent of all the decentralised social media alternatives on this state-of-the-art.

The AT Protocol is an open social network protocol developed by Bluesky, which originally was a side-project started by Jack Dorsey when he was head of Twitter. According to this interview with him, Bluesky was originally not meant to be a full-blown company, but instead Bluesky was supposed to work on R&D to develop an open protocol that Twitter would integrate to remove Twitter’s liability over platform moderation.

Bluesky derived from Jack’s vision over time and especially after Elon Musk's takeover of Twitter, and it is now building its own social network on top of the open protocol named “The AT Protocol”. Jack recently backed away from the Bluesky board, and openly recommends users either to stay on Elon Musk’s centralised X or to join Nostr. Bluesky, powered by AT Protocol, has now more than 6 million users.

AT Protocol's underlying vision is to achieve the following:

• Users should self-own their identifier with which they would log in, so as to never be locked in to a server or a platform.
• Users should self-own their posts and other data that they can plug into an ecosystem of apps.
• Users should be able to choose their feed algorithm.
• Anyone should be able to create new feed algorithms.
• There should be a clear distinction between the un-moderated permissionless data layer and the moderation layer. Anyone should be able to “pick” the data they want from this open data lake.
• Moderation should be decentralised: anyone should be able to create a “labeler” to attach moderation information to each post.
• The AT Protocol should do all of this in a way that feels friendly to the end-user: this complexity should be “hidden” by default.

To achieve this, AT Protocol is based on the following architecture:

• The Personal Data Store (PDS) contains the keys and all the other user personal data such as posts, likes, follows, etc. Only the user can log in onto it. Users are represented by their did:plc identifier, whose underlying private key is controlled by the PDS. Migrating off a user’s current PDS server to another one is possible without losing one’s social graph or posts. Delegating key management to the PDS is a conscious decision by the AT Protocol designers, to maximise user experience by removing key management from the client side. By default, PDSs are stored and managed by Bluesky, the company; however, anyone can freely self-host it if they want more control, and migrating away from Bluesky-managed PDS is possible without incurring any loss in terms of social graph or user data.
• The Relay is a series of servers that’s responsible for continuously pulling data from all the existing user’s PDS, and keeping track of it in a large database.
• The Labelers are a series of servers responsible for adding a series of labels to the data available in the Relay. Anyone can create their own Labeler.
• Feed Generators use the data labelled by one or multiple Labelers to create feeds and filter out moderated content.
• AppViews are the frontend of the AT Protocol. They are apps such as Bluesky, Graysky, or WhiteWind. They connect to Feed Generators to display the timeline. Via their interface, they allow end-users to connect to their own PDS and populate data to it.
• Last but not least, the Lexicon functionality adds semantics to the AT Protocol’s underlying data and APIs. This allows creating arbitrary relations between accounts and accounts, data and data, accounts and data.

(Source: Bluesky Blog)

Advantages

• Mostly rooted in web standards, with Decentralised Identifiers, etc.
• Sensible objectives aligned with the principle of self-sovereign identity:
• Portable identity, portable data: no platform/server lock-in.
• Every interaction is cryptographically verifiable, avoiding unnecessary trust and opening doors to zkKYC.
• A clear distinction between raw permissionless data lake (to achieve censorship-resistance) and filtered data (to achieve decentralised moderation), acknowledging that moderation is necessary, yet balancing with the need for freedom of speech is complex and highly controversial.
• Algorithms choice at the user level, both for its creation and for its selection.
• Verifiable accounts via the Web of Trust (@example.com handle verified by DNS coming from example.com domain), effectively fighting against impersonations - this is the only social network protocol which has a solution to this problem (aside from traditional KYC accounts such as on LinkedIn).
• Fully open-source, including Bluesky app.
• Scalable and free from unnecessary blockchain fees.
• User-friendly identity system, without cumbersome key management by default, without affecting user experience.
• Account recovery is well thought of, secure key rotation can occur without users having to change their handle or even know about it.
• Power users can have a very high level of control over their data and identity by self-hosting their PDS and verifying their handle with their own domain name.
• There are mature open-source tooling for labelers, moderators, and feed generators.
• The “Lexicon” functionality allows developers to treat the AT Protocol as an open network of data lakes, with good tooling for syncing, streaming, filtering, and pulling this data. Developers can then build custom functionalities and apps on top, that may address very different use-cases than classic “post/follow/like/retweet” mechanisms, and even address services outside the scope of social media. A recent example of this is WhiteWind.

Limitations

• The identity system being based on DNS and the Web of Trust, it is theoretically less trustless than basing it on Ethereum. However, we believe that trying to replace the Web of Trust infrastructure with Ethereum is not a realistic attempt, especially if it means making every user pay to create their account (Farcaster’s situation). Maybe one day part of DNS will be built on top of Ethereum, but DNS and the Web of Trust are fundamental building blocks of the digital space that have proven to be trustworthy and that are not going away. For that reason, we believe that the AT Protocol choosing to implement its global user registry on top of this existing & mature yet fairly decentralised public key infrastructure is the most reasonable approach.
• While AT Protocol is designed as an open network, the architecture is still in beta, and as a consequence, the following components are still exclusively run by Bluesky, waiting for its decentralisation:
• User Registration. Since May 2024, it is possible to register on one’s own server, and Bluesky app supports it, but it is not trivial to set up, and third-party apps all redirect to Bluesky portal for registration, which creates user friction. Technically, it is already possible for a third-party app to host their users’ PDS, but it requires extra work.
• Relays (Crawling Indexers). It is technically possible to run one outside of Bluesky, but it is not trivial, and it is not officially thoroughly documented.
• Lack of developer documentation and tooling.
• Third-party apps are encouraged to use so-called “App Passwords” to allow users to log in to their PDS, passwords which can only be created via the Bluesky app. This is supposed to be solved when “Log in with Bluesky” will be available later in 2024.
• As the remarks above prove, as well as the “did:plc” method used for user’s handle, which stands for “placeholder DID method”, the AT Protocol architecture remains immature.
• The concept of Personal Data Store is clashing with the “Decentralised Web Node” (DWN) standard. Users should not have to handle two distinct servers to handle their personal data. As PDSs currently seem to lack the flexibility of DWN, and as DWNs are more low-level and are already on the way to be standardised (even though it lacks maturity), DWNs should probably be used as a basis on top of which PDSs would be implemented. However, nothing hints towards this direction, which might result in fragmentation within the ecosystem.
• Even though the AT Protocol provides a solution to sybil resistance and identity theft protection by verifying users via the Web of Trust, this approach only makes sense for public figures (e.g., politicians, artists, sportsmen) or established organisations (e.g., companies, newspapers, non-profits, official governments accounts) owning a well-known web domain, which is not applicable for the vast majority of the population.
• “Lexicon” is not a web standard. The AT Protocol claims that the existing standards for the semantic web (JSON-LD and RDF) were not providing the functionalities they needed - but building outside standards means ecosystem fragmentation and issues with adoption and interoperability.

Could it be useful for our requirements?

• The AT Protocol account portability perfectly suits our Interoperability use-case.
• The fact that every transaction is signed suits our Data Provenance Trustworthiness requirement (protection against identity theft).
• The infrastructure of the AT Protocol simplifies algorithm and moderation choice, so it could be perfect to implement Decentralised Moderation.
• The AT Protocol is designed for pseudonymous / public posting: the AT Protocol associates a permanent public identifier (did:plc) to each user. Since we address anonymous posting, this may be an anti-feature from a privacy perspective, unless an anonymous & unique yet verifiable identifier can be associated with a pseudonymous did:plc.