Bluesky’s AT Protocol: Pros and Cons for Developers

Decentralized social media is a vibrant developer ecosystem currently, and it’s not just the fediverse leading the charge. Get ready for more dev activity in “the ATmosphere,” the rapidly growing network based on Bluesky’s AT Protocol. In this post, we take a look at the mechanics of the AT Protocol, what developers are doing with it, and some comparisons with the fediverse model of ActivityPub.

In case you’re unaware, Bluesky is a company that started out as a special project in Jack Dorsey’s Twitter. It’s now an independent company, led by CEO Jay Graber, which just had a $15 million series A funding round (the lead investor is a blockchain VC, which raised concerns among some in the decentralized web community). Make no mistake: Bluesky has major traction. It now has 13 million users and has tempted some big names from the tech community to migrate from X — notably for TNS readers, Kubernetes A-lister Kelsey Hightower.

How AT Protocol is Like the Web

In a recent conference presentation, Bluesky engineer Dan Abramov — previously known as one of the faces of React at Meta — explained how the AT Protocol works.

He began by noting that in the early web, you might create a personal website by buying a domain name and putting your HTML files “into a box” — by which he meant a web host. But because you had a domain name, it meant you controlled that box; you could switch web hosts anytime and point your domain name to the new host. But when centralized social media services arose in Web 2.0, such as Facebook and Twitter, you no longer controlled “the box.” Now you were “inside the boxes,” which meant if the service died or changed significantly (as happened with Twitter), you had no say in the matter.

The idea with Bluesky is to prevent a company like Facebook or Twitter from keeping you in a box. As Abramov explained it, “What if there was a layer, kind of above the products, that was user-controlled, that was product-agnostic, and that was shaped like the web?” Enter the AT Protocol. In practical terms, it is similar to the http:// part of a web address. But in Bluesky, it’s at:// — “the ATmosphere.”

Bluesky, a Twitter-like application, is hosted on the AT Protocol and collects data from a user’s “personal data server” (PDS). Most of Bluesky’s 13 million users are currently hosted on servers owned by Bluesky (the company), but the idea is that over time many people will opt to host their content on either their own personal PDS, or a PDS owned by another organization (similar to how web hosting works).

But here’s the really beautiful thing about this system — you can use domain names on Bluesky, both to verify yourself and to control your content. To use Abramov’s framing, the PDS is a box where you put your content, but you can remain outside the box by using a domain you own.

AT Protocol in Practice

To illustrate how the AT Protocol works, my own Bluesky handle is @cybercultural.com. To set this up, I just needed to create a TXT record on my web host to point it to Bluesky. This maps a Decentralized Identifier (DID) to my domain, like so: at://cybercultural.com. DIDs are a web standard ratified by the World Wide Web Consortium (W3C), so this is all web-native.

Now when I post onto my Bluesky account (currently hosted on Bluesky’s PDS), it goes into the app.bsky.feed.post collection connected to my domain. A developer on Bluesky set up a nifty browser view into what’s happening behind the scenes, so here’s what my account looks like:

This is all very tidy for developers. So let’s now look at the code for a post on the AT Protocol. Here’s a recent post I did on Bluesky, which included a link to my website:

Here’s what that looks like in code:

You can read more about the back-end architecture in Bluesky’s excellent documentation, but let’s focus for now on the implications for app developers.

Bluesky has one really compelling feature for application developers thinking about building on AT Protocol. Because users can own their identities — via DIDs and the domains they control — they can easily use their Bluesky ID to sign up to other applications that get built on the AT Protocol. Even better, new applications can use content from Bluesky, because it’s connected to a user ID. So right out of the box (so to speak) app developers can tap into existing user IDs and content. This is much more enticing to devs than the ActivityPub / fediverse model, which requires users to set up a new ID for each application (I’ve previously written about the fediverse’s issue with identity).

Right now, there aren’t a lot of other apps in the ATmopshere, but there are experiments happening. There’s a blogging tool called WhiteWind, a Reddit clone called frontpage.fyi, and an events app called Smoke Signal. More will follow, I’m sure.

For users, the clear benefit to the AT Protocol is that, as Abramov pointed out, you can be “outside the box” and in control of your ID and content. If you take exception to the main corporate Bluesky PDS, then you can move to another PDS and re-direct your domain to it. And because your content is tied to your identity, all your content moves to that new PDS, too. This is different from how ActivityPub works because although you can move to another instance (equivalent to a server) and bring your follower and following connections along with you, your content stays on the old instance.

But Is AT Protocol Truly Decentralized?

Now, the sticking point so far with the AT Protocol is that the company that created it, Bluesky, controls the development process and almost all the infrastructure at the present time — and so the resulting network (the ATmosphere) is vulnerable to corporate control.

Cory Doctorow referenced this in a recent post, saying that he wouldn’t join Bluesky until it “added the federation systems that would enable freedom of exit to its service.”

Laurens Hof, who is active on both Mastodon and Bluesky, wrote a post in response to Doctorow. He firstly offered a handy conceptual model to show how AT Protocol differs from ActivityPub:

• 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.

In this model, Bluesky (the app) is an “indexer” of content that you control — in my case, via at://cybercultural.com. The problem, as Hof points out, is that “99% of users are exclusively on infrastructure owned by Bluesky PBC” (by PBC he simply means the company, which uses a “Public Benefit Corporation” structure). How different is that really from a platform like X, where one company is ultimately in control?

Developers Have a Choice

So, as a developer, should you build on the AT Protocol? There are, as shown above, some compelling aspects to this protocol. Notably, if you build an application that appeals to many of Bluesky’s 13 million users, then you’d be able to piggyback off Bluesky’s success and get people to log in to your app using their existing identity. That’s much easier than the fediverse model, where you have to convince people to create an entirely new account for your app.

However, the corporate control issue presents a big risk to developers, especially given the track record of web startups over the past couple of decades. What if Elon Musk buys Bluesky?! That may seem like an extreme scenario now, but you never know what Bluesky’s investors will decide in the future — certainly, we learned that the hard way with Twitter’s former board.

The reality is, until the technical foundation of the AT Protocol is distributed much more widely than it is presently — which is the company’s stated goal — you’re going to be under the thumb of Bluesky and its investors. Whether you think that’s an acceptable risk for you to take as a developer, well that’s for you to decide.