Bluesky - AT Protocol vs. ActivityPub

🧵 [1 / 15]

So, we jumped from #Twitter to #Mastodon, after a man with a sink showed us how fragile centralized platforms really are. And now there’s #Bluesky wanting to convince us that their AT Protocol is even more robust than #ActivityPub. But is it really superior and would it have been better to build the #fediverse on top of this protocol, instead?

Thread time!

🧵 [2 / 15]

Let’s recap, in all briefness, how ActivityPub works [1] .

The core idea is that neither your home nor mobile devices have a permanent internet connection, so you need an agent that does (in Mastodon lingo: your instance). This agent performs two services:

1. Take your posts and host them under linkable URLs.
2. Notify interested parties (aka your followers) when you post something (and where it can be found).

🧵 [3 / 15]

Curiously, there is no concept of a comment. A reply and a post are basically the same thing. If you were to comment on this one, you’d actually instruct your agent to publish a post of your own, with it’s parent URL pointing to mine, then send my agent a notification to add your reply post’s URL to the children list of my original post. In other words, the parts of a lively conversation can easily scatter across multiple servers,

🧵 [4 / 15]

be costly to stitch together and a lot can go wrong in the process (e.g. if an agent goes offline, conversations are cut off). There are good reasons to design the protocol this way, but it is not a good design for what we are using it for.

So, what does Bluesky’s AT Protocol bring to the table that ActivityPub doesn’t? Is it more efficient? More reliable? Well, sortoff yes, but no…

🧵 [5 / 15]

AT stands for “Authenticated Transfer” and addresses a main concern of Mastodon (though not necessarily of ActivityPub): unless you self host, there’s always the risk of a moderator taking your agent away or its instance shutting down, either resulting in you loosing everything with no recovery option.

🧵 [6 / 15]

ATP also has the concept of an agent [2] , called a PDS (Personal Data Server), hosting a PDR (Personal Data Repository). The big feature of the system is that the PDR not only contains your entire content (including comments), but is also bound to your identity [3] . A PDR can move to a new PDS in the same sense that you can move your phone number when switching carriers (cooperation of the old PDS is not required). You are also welcome to transfer to a self hosted PDS any time.

🧵 [7 / 15]

The “phone number” in this case is called a DID (Decentralized ID [3] ) which is derived from the cryptographic key, the content in your repository is signed with. This DID is published in a “telephone book” along with your handle and a manifest that lets users look up where your PDS is currently located and verify that it indeed hosts your content.

🧵 [8 / 15]

Where is that “telephone book” stored and what would keep a moderator from simply deleting your entry? Well, the W3 recommendation tries very hard to avoid using the word “blockchain” here. 🤷

[The whole federation aspects stands and falls with the question of who controls DID resolution]

🧵 [9 / 15]

While this all sounds like silicon valley finally getting the message to stop locking users into silos, that’s actually just of a side effect of the design goal, marketed as the design goal. What the PDS/PDR system really is, is a load balancer of a distributed content delivery network:

🧵 [10 / 15]

• Datacenter is at max storage capacity? Just rent another one and move some PDS/PDR over there.
• User starts hosting video content? Offer to move his PDS to premium hosting with more storage and bandwidth.
• User wants to self host? Great! Let him pay his own hosting costs.
• User is producing questionable content? Force him into self hosting and shirk legal responsibilities while avoiding all the drama that comes from banning an account.

🧵 [11 / 15]

So, where’s the catch? Is there even one? Or do we finally get lock-in free platform (even if only by accident)? Well, this is the part where the smoke and mirrors come in. Buckle up!

🧵 [12 / 15]

Bluesky distinguishes two layers: speech and reach [2]#speech-reach-and-moderation . That is, you can say everything you want in your PDR, but you won’t necessarily find an audience for it, because Bluesky wants to control the indexers, required for content discovery. Technically, it is an open ecosystem. Everyone could setup such an indexer and users could choose freely. But in reality the cards are stacked against that. The whole “invite link” thing, for example,

🧵 [13 / 15]

ensures that Bluesky gets a head start at indexing content and the mobile app will make the Bluesky indexer the default choice for new users (this is the same discussion, we are currently having about making mastodon.social the default instance). No competitor will be able to enter the market before Bluesky is firmly established and at that point it will be a constant game of catching up with new features,

🧵 [14 / 15]

while users have to play according to the rules or risk loosing reach (Twitter Blue anyone?).

Does this sound familiar? It should! From a birdseye’s view, leaving all the implementation details out, this is the same relationship, bloggers have with search engines and that is exactly what Bluesky is hoping to become: not Twitter 2.0, but the next Google.

🧵 [15 / 15]

Sources:

1. https://www.w3.org/TR/activitypub/
2. https://atproto.com/guides/overview
3. https://www.w3.org/TR/did-core/
4. https://atproto.com/guides/overview#speech-reach-and-moderation