Laurens Hof

2024-11-04 19:51:27

A conceptual model of ATProto and ActivityPub

If you were to design an open social networking protocol, what would that look like? Which metaphors and comparisons would you use to get a general idea of how the network functions? What would you answer if people ask if your network is decentralised and federated?

This article is not a deep technical explanation about how either ActivityPub or ATProto work. Instead I want to explain to you have these two protocols have different conceptual models of what an open social network looks like. These conceptual models differ much more from each other than people expect, leading people to apply concepts that come from the ActivityPub world to the ATProto world, in a way that does not fit with the conceptual model that ATProto has.

One of the main subjects of discussion recently has been whether Bluesky is decentralised and if it is federated. I think answering these questions requires a clarity on how ATProto differs conceptually from ActivityPub. Decentralisation and federation are valued for how they impact power structures, but there are multiple ways to build other power structures in open social networks.

A bit of the summary at the top, since that might help during reading:

• The conceptual model of ActivityPub resembles that of email: independent servers sending messages to each other.
• The conceptual model of ATProto resembles that of the web: independent sites publish data, and indexers aggregate this data into different views and apps.

A conceptual model of ActivityPub and the fediverse

The fediverse¹ is a network of independent social networking sites that use the ActivityPub protocol with each other. The conceptual model of the fediverse is that each social networking site, often called a server or instance, is it’s own network that can exist independently. You can set up your own Mastodon server, not connect to any other server, invite some of your friends, and have a fully functional social networking site.

Because each server is its own independent and complete social networking site, it means that each fediverse server is a monolith, that puts all components together in a single place. A fediverse server:

• Owns your identity.
• Stores your data.
• Transforms protocol data into a site with a timeline that you can look at.

Most people run a fediverse server because they want their independent social networking site to join a super-network of interconnected social networking sites; the fediverse. This ‘anyone can run a fediverse server’ is the ‘decentralised’ part of the fediverse. In order for the server to communicate with the rest of the fediverse it does a fourth thing:

• Communicates with the rest of the network. In ActivityPub terms: the server gives you an inbox and outbox, and messages flow between these inboxes and outboxes on other servers.

This communication between servers is the ‘federation’ part of the fediverse.

Decentralisation and Federation in the fediverse

The reason to create a super-network of independent social networking sites is one of governance. The fediverse is in many ways a response to the centralised governance under a single billionaire of the current Big Tech platforms, and creates a governance structure where each social networking site is it’s own authority; it has authoritative control over the users on their site, but no authority over any of the other ~30k independent servers.

Decentralisation and federation are crucial for the functioning of the architecture of the fediverse. Decentralisation means that anyone can set up their own social networking site, and federation means that all these independent sites can connect with each other without a single central authority. While these terms often get used as being valuable in itself, I think they should be seen as technical solutions to solve a governance problem: how can we build a social network without a single central authority? Human nature is a funny thing however, and technical solutions to limit authoritative control usually means that chokepoints simply pop up in other places; whether that’s the software that’s used 75% of users being governed by a self-styled ‘benevolent dictator for life’, or server admins having full centralised control over the users on their server.

A conceptual model of ATProto and the ATmosphere

Bluesky PBC² is also building an open social network with the explicit goal that the network should not be owned by a single company. The protocol they use is called AT Protocol, often called ATProto. The network that is build on top of ATProto is called the ATmosphere. The approach they take to get there is quite different than the one the fediverse takes, however. The conceptual model of ATProto is that every account is it’s own independent place in the ATmosphere³, and every app is an aggregator that takes data from all the places in the ATmosphere and uses them to create their own service.

Every account has its own place to store their data, a Personal Data Server⁴. This PDS is a simply a database that contains all your own data on ATProto: the posts you made on Bluesky, as well as your RSVP to an event on Smoke Signal.

In turn, every application is an aggregator, similar to how Google is an aggregator of the web. An ATProto app (like Bluesky) takes the data from all the PDSes in the network⁵. The ‘app’ processes that data, and provides the end-user with a ‘view’ on that data. As such, these applications on ATProto are called AppViews.

In the case of Bluesky, they take all the microblogging posts stored on all the PDSes in the ATmosphere, aggregate them together. This aggregation allows Bluesky to give users the Discover feed, count the number of likes on a post, among other things. It is then presented (the ‘view’) to the user in a format that resembles Twitter⁶. But other AppViews are also possible: WhiteWind is a blogging platform build on ATProto: it allows you to write blogs, and if you use WhiteWind to write a blog posts, these posts are also stored in the same PDS that stores your Bluesky data. The WhiteWind application (AppView) aggregates data from the entire ATmosphere, and takes both WhiteWind-style blog posts, as well as Bluesky’s microblogs. The View WhiteWind presents on their site is blog posts, and with Bluesky’s microblogs functioning as a sort of comment section⁷.

In short, the conceptual model of ATProto is has some resembles to how the web works. The web has many independent websites, and indexers such as Google aggregate the websites and present it back to users in their own ‘view’. Similarly, the ATmosphere has contains of many PDSes, and AppViews aggregate this data into a product for users.

Independence, openness and power on ATProto

As the question ‘Is Bluesky decentralised and federated’ is the greatest thread in the history of forums, and the discussion is still not locked by moderators after 12,239 pages of debate, it’s worth taking a step back at what these concepts are meant to accomplish. Decentralisation and federation in the fediverse mean an open network that anyone can join without any without centralised control.

Anyone can run their own PDS and be a full part of the network, without needing any centralised permission. Anyone can run their own AppView⁸, and build their own product in the ATmosphere, without needing permission by any centralised authority. They can even reuse Bluesky’s data for their own purposes, like WhiteWind does. On first glance, this seems pretty decentralised.

The question of federation becomes more complicated: who can communicate with what exactly? Any AppView can communicate with the PDSes, is that federation? The PDSes cannot communicate with each other directly (so no federation?) but do so via AppViews (so maybe federation?) What about AppViews communicating with each other? Picosky and IRCsky are two different AppViews that both allow you to chat over ATProto, and see the same chat messages. Are these two AppViews federated? And how many individual parts of the system need to federate before you can describe the entire ATmosphere as federated? I don’t know the answer to all of this, but I’m personally trending towards: are we even asking the right questions here?

To make matters even more complicated; many people are not asking the question ‘is the ATmosphere decentralised’, but are wondering ‘is Bluesky decentralised’? Here the ATmosphere take a different direction than the fediverse. The answer for the ATmosphere is not: ‘there should be many versions of the Bluesky app so users can switch to another app’. Having many instances of the Bluesky app provides no real additional benefit to making the network more open and less controlled by a single point of authority.⁹ Instead, the conceptual model of how the ATmosphere is defending itself against an AppView turning ‘bad’, is to have competing different AppViews where people can switch to instead. Bluesky PBC hopes that there will be a hypothetical GreenCloud AppView, which does microblogging slightly differently than Bluesky. This way, people have a different app they can use, in case the Bluesky app does not suffice.

The hypothetical GreenCloud microblogging app build on ATProto does not actually exist. But the code for the Bluesky app is available as open source¹⁰, anyone can run their own Bluesky if they want to. The interesting problem here is that nobody has done so: running a competing service to Bluesky is totally possible, but why would you? It costs money, time and expertise to do so, and there is little gain to doing so.

How applicable the concepts of decentralisation and federation are to the ATmosphere is debatable, but they are used as an approximation for the core question: how is power distributed in the network? And Bluesky and the ATmosphere make it clear that technological architecture can only help so much here: Sure, you can be completely independent of Bluesky PBC on the ATmosphere, as everything is open. But in the end, 99% of users are exclusively on infrastructure owned by Bluesky PBC. No technological architecture can compensate for that kind of the power distribution.

This is not lost on Bluesky PBC and their investors either. Blockchain Capitol, lead investor in the series A, has the investment thesis that the value is in growing the ATmosphere, writing that they are “investing in more than a product but rather a vision of what social infrastructure could be”.

On Identity

Technological solutions to prevent control of chokepoints usually mean that these chokepoints simply pop up in different places, and the ATmosphere is no different than the fediverse in this regard. This explanation of how the ATmosphere works, is missing a crucial part: how Decentralised Identity works on ATProto. Explaining how the system in detail is the subject of my next article. And that system might just be both more centralised than people expect, more decentralised than people think, and it’s most centralising aspect might just be… a clock.

Notes

1. The fediverse is defined here by the Mastodon-dominant supernetwork that mostly uses ActivityPub and is mostly is used for microblogging, with some link-aggregators on Lemmy, some video on PeerTube on the side. I’m aware that this definition does not cover the entirety of the network, as well as that you can contest every word in that definition. But its a close enough approximation for how the word is used in casual day-to-day life. ↩︎
2. For clarity, ‘Bluesky PBC’ refers to the Bluesky Public Benefit Company, while ‘Bluesky’ refers to the microblogging app made by Bluesky PBC. ↩︎
3. See also Paul Frazee’s thread on how every user is basically a website. I hesitate to use the term website here, as that comes with certain preconceived notions of what a website is, and a PDS repository is different in some manners. Maybe over time it will turn out that the equivalence of ‘PDS repo’ with ‘website’ will makes sense to people however, I’m unsure. ↩︎
4. Technically, a repository on a PDS, a PDS can contain the repositories for many different accounts. ↩︎
5. This is mostly done via a Relay. Relays are an optional part of the network, and can best be seen as an extension of an AppView. This extension is in itself also flexible, multiple AppViews can use the same Relay. ↩︎
6. The extra step here is that the AppView sends data to your client, such as the bsky.app website, the official mobile clients or a third-party client like deck.blue ↩︎
7. Example of a WhiteWind blog that combines Bluesky’s microblogs here. ↩︎
8. And/or run their own Relays, which multiple people are in fact doing. ↩︎
9. This is the problem that the fediverse has; there are 10k Mastodon servers, accounting for 80% of active users, but the software is controlled by a single person. Many concurrent deployments of the same software does not reduce the amount of control that this software has, it arguably increases the control instead. ↩︎
10. The core functionalities all are, some parts are not. ↩︎

fediversereport.com/a-conceptu…