Bluesky Begins To Make Its Decentralized Vision Real

For semi-obvious reasons, I've been following developments at Bluesky closely, given that my Protocols, not Platforms paper was originally part of the reason Jack Dorsey decided to create Bluesky. I have no official association with the organization, though I did help Twitter review some of the early Bluesky proposals and spoke with a few of the candidates they looked at to lead the company (including Jay Graber, whom Jack eventually tabbed to run it).

While Dorsey has since soured on the approach that Bluesky is taking, preferring the nostr protocol's approach (and deleting his Bluesky account entirely), I continue to believe that Bluesky is the most interesting and most promising of the various attempts at building a better social media system out there. I explained many of the reasons why a few weeks ago when Bluesky finally dropped its private beta/invite-only" setup and opened to the public.

And yet, as many people pointed out to me, Bluesky still wasn't really decentralized in any real way. It remained entirely centralized, as the company worked to build up both the new protocol for it, ATProtocol, and the Bluesky reference app on top of the protocol.

However, last week, Bluesky took that next step and opened up the ability to federate.

Today, we're excited to announce that the Bluesky network is federating and opening up in a way that allows you to host your own data. What does this mean?

Your data, such as your posts, likes, and follows, needs to be stored somewhere. With traditional social media, your data is stored by the social media company whose services you've signed up for. If you ever want to stop using that company's services, you can do that-but you would have to leave that social network and lose your existing connections.

It doesn't have to be this way! An alternative model is how the internet itself works. Anyone can put up a website on the internet. You can choose from one of many companies to host your site (or even host it yourself), and you can always change your mind about this later. If you move to another hosting provider, your visitors won't even notice. No matter where your site's data is managed and stored, your visitors can find your site simply by typing the name of the website or by clicking a link.

We think social media should work the same way. When you register on Bluesky, by default we'll suggest that Bluesky will store your data. But if you'd like to let another company store it, or even store it yourself, you can do that. You'll also be able to change your mind at any point, moving your data to another provider without losing any of your existing posts, likes, or follows. From your followers' perspective, your profile is always available at your handle-no matter where your information is actually stored, or how many times it has been moved.

It's currently limited to smaller situations, of people who basically want to self-host their own Personal Data Servers. While things get settled, there are rate limits and guardrails for these PDS's (so, things like only 10 user accounts for the time being). If you want to understand this even more (even if you're not technical), Bluesky's more technical" explanation is still highly readable.

I know that some people hear federation" and immediately think of Mastodon. However, Bluesky's entire setup is very different and designed to be much more user friendly in multiple ways (once again, this is one of the reasons that Bluesky chose to create the ATProtocol, rather than going with ActivityPub).

ActivityPub federation has both pros and cons. When you sign up for an instance, you're basically wholly reliant on whoever runs that instance. Rather than being part of a big centralized network, like Facebook, you're part of a small centralized server that interconnects with lots of others. But whoever runs your server has pretty much ultimate control. That can work out great if they're committed to it. But it can also unleash some problems.

Mastodon and related ActivityPub systems have put a lot of effort into minimizing some of the downsides of this. For example, threats of defederation" are a fascinating incentivizing structure to keep ActivityPub instance admins from going totally rogue, while still allowing for there to be experimentation and differences among servers.

But in the end, you've still gone from a big centralized system to a little one, where someone else is in control.

With the Bluesky approach, there are many more layers involved, and federation is less about putting your entire social experience in the hands of one instance admin. Rather, it's just about where your data/account information gets stored. As Bluesky explains:

A summary of some ways Bluesky differs from Mastodon:

• A focus on the global conversation: On Mastodon, your instance", or server, determines your community, so your experience depends on which server you join. An instance can send and receive posts from other instances, but it doesn't try to offer a global view of the network. Your Mastodon server is part of your username, and becomes part of your identity. On Bluesky, your experience is based on what feeds and accounts you follow, and you can always participate in the global conversation (e.g. breaking news, viral posts, and algorithmic feeds). You can use your own domain name as your username, and continue participating from anywhere your account is hosted.
• Composable moderation: Moderation on Bluesky is not tied to your server, like it is on Mastodon. Defederation, a way of addressing moderation issues in Mastodon by disconnecting servers, is not as relevant on Bluesky because there are other layers to the system. Server operators can set rules for what content they will host, but tools like blocklists and moderation services are what help communities self-organize around moderation preferences. We've already integrated block and mute lists, and the tooling for independent moderation services is coming soon.
• Composable feeds: We designed your timeline on Bluesky so that it's not tied to your server. Anyone can build a feed, and there are currently over 40,000 algorithmic feeds to choose from. Your Mastodon timeline is only made up of posts from accounts you follow, and does not pull together posts from the whole network like Bluesky's custom feeds.
• Account portability: We designed federated hosting on Bluesky so that you can move servers easily. Moving hosting services should be like changing your cell phone provider -you should be able to keep your identity and data. Changing servers on Bluesky doesn't disrupt your username, friends, or posts.

This is important, though there are still some details to be worked out, especially around the third-party moderation efforts. But, on the whole, having the ability to still interact with the wider Bluesky community while keeping your personal data server somewhere else that you control is a big step forward in realizing how a more decentralized social media could (and I'd argue, should) work. It brings us back towards the world of an open web, and away from locked-in silos.

Now, again, there are still some parts of the system that people are worried about, in particular how they could be open to centralized capture. The thing is, there is always going to be some risk of this on basically any system. To make things work properly, you tend to need certain parts of the stack to either work together seamlessly, or it just ends up that a very small number of giant players end up dominating the otherwise open" system anyway.

This is a concern worth watching. However, it's also been one that the Bluesky team has repeatedly and readily acknowledged, along with their ideas and thinking on how to guarantee that future Bluesky (or anyone else) is effectively incentivized against enshittification. That's not to say it will all work out, but so far I've seen no reason not to believe that the team has been building with this in mind. Its last few major announcements have all shown continued movement in this direction.

At the end of this tunnel, there is a very powerful vision, one that is partially (though not entirely) laid out in the Protocols, Not Platforms paper. In this vision, people can either self-host their own data servers or find a trusted third party to do so, with the ability to move if the current host turns out to be a problem. It's one where there are many different tools to allow people to craft their own experience (though composable moderation and algorithmic choice within the system) and the moderation layer is separate and extracted from the data server, the app, and the hosting company.

There will be services that combine them all (like Bluesky today), but also we're increasingly moving towards the world in which people will be able to adjust things to their own liking. And that can be powerful in its own way. No, most users won't want to get down into the weeds and tweak things themselves. But that's where there's an opportunity for organizations to step up and provide a comprehensive solution themselves, whether it's Bluesky itself, or others.

But, just the fact that users can modify basically everything, and that third parties have free ability to build apps and services (and custom feeds) on top of this core, has an added advantage, even for those who don't want to tweak the details and fiddle the knobs themselves. The very fact that it's possible (or that it's possible to jump to other providers) creates a strong anti-enshittification incentive structure.

One of the big reasons that enshittification occurs is because users are locked-in. There's no easy way to leave, without a massive hassle. And part of that hassle is losing access to friends and family. The exciting part of Bluesky with federation is that there is no lock-in, which means there's much less temptation for enshittification and rent extraction from users with nowhere else to go.

This move towards federation is a small move towards that larger vision, but it's an important one.