Comparing Bluesky and Mastodon
This write-up is not intended for all audiences. If you're looking for a simple rundown of differences check here
The week after the election Bluesky quickly surpassed Mastodon's user count. Jumping to 1 million accounts made every day for over a week until settling somewhere around 25 million accounts. Entire communities flocked from the husk that used to be Twitter. Previously, Mastodon was the biggest competitor to Twitter in the 'decentralized and federated' social media space, amassing just shy of 10 million users. A question arises - what made Bluesky more preferable than Mastodon?
The answer is straightforward - it felt better, more seamless, and more interconnected. To understand why, we need to talk about decentralization, federation, and data structure.
Mastodon's biggest flaws, in terms of user experience, are in data presentation, the actual presentation of accounts and posts. Mastodon's network protocol is such that, for example, when searching for an account on an instance that your instance has never seen before, you often wind up looking at a page with an empty account, producing a feeling of 'jank.' You have to click a link that says "Open this account on remote instance" to be brought to the data itself, on the server that data is hosted on. This added layer is an unpleasant feeling that many of us who regularly use Mastodon have just gotten used to. Why is it this way?
To use a metaphor, Mastodon instances are essentially a Post Office, and user accounts are like home mailboxes, with an inbox and an outbox. Instances do the work of collecting information it hears from other servers, other instances, making a copy of that information, and distributing it in the mailboxes of people who ask for it. This is to say that federation on Mastodon's network is Instance to Instance. Scrolling your home timeline on Mastodon is like asking the post office to show you everything they've ever received for you, reverse chronologically. To know to listen to another server, it waits for one of its users to interact with an account on that other server, or for that other server, another Post Office, to send it some mail. This means that, as said, if your instance tries to produce its own copy of data that its never seen before, it won't have anything to show.
Bluesky works a little differently. Firstly - Mastodon champions decentralization. Users are encouraged to "Find a Community" - to seek out an instance that fits them, or to make their own instance. There is a Flagship Instance, mastodon.social, an easy place for anyone to join - but, joining there doesn't offer the fullest experience of the Mastodon network, even if it does drop you into the largest, most populated space. Bluesky intended to turn federation - the interaction between different servers running the software - on from the beginning (and eventually did) but released with centralized infrastructure. That is to say the majority of people who have joined Bluesky's network were never presented with a series of instances to choose from, instead almost everyone has accounts on bsky.social, the centralized and default server. By default there was no possibility for federation hiccups nor jank that users needed to manage on Bluesky. A clear point in Bluesky's favor as an "easy alternative" to somewhere like Twitter.
Where Mastodon instances are like a Post Office making copies of everything other Post Offices send it to distribute to its own users, Bluesky's architecture is a bit more layered and modular.
The equivalent of a Mastodon Instance on Bluesky is a Personal Data Server (PDS). Like Mastodon, Personal Data Servers have users, and users post data on their PDS. But the PDS isn't doing the work of a Post Office, delivering messages from its local users, listening for messages from other Post Offices, making a copy so as to pass the message to an individual user's mailbox - instead, all the PDS needs to do is hold its own user's data and talk to a relay. A relay is a middleman between PDSs, and the relay is what's copying information from other PDSs for yours to interact with - one big Central Post Office for the whole world. This means that Bluesky's default federation style is Instance (PDS) to Relay, unlike Mastodon's Instance to Instance style.
This Instance to Relay federation style makes self-hosting a PDS incredibly lightweight, but at the expense of centralizing one's access to the network. Running this relay is computationally expensive. It is constantly looking for new PDSs as it receives updates from each and every current PDS, too. Currently Bluesky is reporting that its central relay needs to manage 2000 events per second. This means that the entry-fee to running your own relay, one that provides access to the same network of users, is incredibly high. This method practically requires that a central company continues maintaining everyone's connection to the network, and can function as a fulcrum by which to exclude other PDSs from becoming part of the network. How it would do this requires us that we talk about one more part of Bluesky infrastructure - The App View
Without the Relay users wouldn't have access to anyone else's data - and without the AppView, Bluesky users wouldn't even have a website to log into or post from, and they wouldn't be able to see any of their feeds. This is because the feeds you see on Bluesky are managed through The App View, running on its own server, separate from PDSs and separate from the Relay. Bluesky's team visualize the App View as a Prism - it's a collection of algorithms taking the messy, noisy world of the Central Relay and distributing it and displaying it to each user as feeds. Here the App View forms yet another point of centralization in control of the network.
Bluesky has boasted the power of their "Composable Moderation" system, which functions through the App View. As they put it -
Here’s the way we’re designing an open, composable labeling system for moderation:
- Anyone can define and apply “labels” to content or accounts (i.e. “spam”, “nsfw”). This is a separate service, so they do not have to run a PDS (personal data server) or a client app in order to do so.
- Labels can be automatically generated (by third-party services, or by custom algorithms) or manually generated (by admins, or by users themselves)
- Any service or person in the network can choose how these labels get used to determine the final user experience.
- On top of that, we will let users subscribe to additional sets of moderation labels that can filter out more content or accounts.
The Bluesky Team feels that this overcomes the moderation problems of both Centralized moderation decisions; for example, when Twitter bans a user, and Decentralized moderation decisions, as in Mastodon's Instance-level defederation decisions. Instead what it really does is function as a way to ensure central control over maximum content while justifying a lack of moderation altogether.
This is because the Bluesky network is entirely public. All that would be required to sidestep every moderation tool in place is a new, third party App View of the data. Blocks could be entirely circumvented, without a user even needing to make a new account.
The more Bluesky develops as a federated network, with multiple App Views, multiple Relays crawling the network, and a greater set of self-hosted PDSs, the less control individuals and communities will have in actually controlling their data and their connections to others. Blocks and Mutes in a given App View may prevent someone from seeing harassment being directed their way, but it doesn't prevent others from doing the harassing, from continuing to be able to receive a constant stream of your updates.
If you want a short dive into the Composable Moderation system, i recommend this article by Coyote (Osteophage):
Coyote
So to recap, Bluesky's rollout was designed to maximize the number of users who joined the Central Server (bsky.social), while at the same time connecting users through a Central Relay (previously bsky.network, now firesky.tv), while at the same time displaying content through a Central App View (bsky.app). Each centralization produces a more 'seamless' experience of using Bluesky, offloading computational costs from self-hosted PDSs to Bluesky's servers, thus allowing Bluesky's team maximum control over the access to content.
To compare with Mastodon, users join through a set of instances, either from publicly searchable lists, or from someone they know inviting them to an instance directly. The accounts and posts people have immediate access to - the Network - of the instance that they join are a direct consequence of the interaction behaviors of the others on the instance. The possibility of access to other instances is limited only by the moderation decisions of the Instance Owners and users' own, self-applied user-blocks and instance-blocks. Unlike Bluesky's architecture, which offloads the work of building the network to Relays and Appviews, on Mastodon everything - local users posts/profile picture/media/etc, and the Network of other's posts/profile pictures/media/etc, and the presentation of the combination of the two - is self-constructed and self-contained within each and every install of Mastodon across the network. A much more thorough-going decentralization than Bluesky, with far reaching effects.
On Mastodon 90% of "discovery" happens through users actively seeking out new worlds - I can say form experience that I have spent a fair amount of time looking through people's follower/following lists in the hope of finding new worlds to connect to. The other 10% is through Boosts (retweets) - when someone you follow Boosts a post from an instance that they are connected to that you aren't, it still shows you that post, increasing the possibility of further federation. Giving you access to a part of the network you and your instance didn't even know existed.
But... I've not been entirely honest. I've repeatedly made a simplification in the explanation above that wasn't quite true. I said that Mastodon was "Instance to Instance" style federation and that Bluesky was "Instance to Relay" style federation. The truth is that both of them do either. Mastodon was originally built with only an Instance to Instance protocol in mind, but added the ability to receive data from a relay - and Bluesky by default connects to a Central Relay instead of to Instances (PDSs) directly, but, can be configured to connect to individual instances. I simplified because, for the average user, these default implementation decisions directly affect the experience. The lack of relay-usage on most Mastodon Instances directly corresponds to the world "feeling" smaller, something a lot of Mastodon enthusiasts enjoy, but is something the average user, in looking for a Twitter-clone to migrate to is going to struggle with, as it introduces layers to viewing parts of the network your instance has never seen before.
Mastodon's instance-to-instance networking was prioritized to minimize computational necessity in building the network. If the server only needs to interact with posts it knows of locally, and if it only needs to grab and copy the stream of outside posts one of its local users asked for, it's doing a lot less work than constantly trying to build out the entire network all the time, the way a relay does. Following in this principle, Mastodon's relays do not crawl the network looking to automatically incorporate new instances it finds. Instead, Mastodon relays are more like agreements between instances. In the Post Office metaphor, it'd be like if multiple Post Offices agreed to send each other copies of every piece of mail that came through each of their offices, unless the mail was marked private.
Privacy is another key benefit of Mastodon. Obviously we're all still posting On The Web, and so nothing should be treated as ultimately private, but, in comparison with Bluesky, Mastodon offers a far greater array of privacy tools. As we said above, Bluesky's network is entirely public and sent through Bluesky's servers. Every activity is logged by either The Relay or the AppView. On Mastodon, there are multiple scales and types of privacy tools available.
On the level of individual posts, posts can be marked Public, Unlisted, Followers-Only, and Direct. Public posts can be seen by anyone. Unlisted posts can be seen by anyone but are exempt from searches. Followers-Only posts can, as suggested, only be seen by your followers. And Direct posts are messages only readable by the individuals mentioned in them. This is to say that Direct Messages on Mastodon are the equivalent of a Post sent directly to an individual. Some instance contain the ability to post local-only, which is to say that what you post can be seen by anyone logged on to your instance, but it didn't federate out into the network.
On the level of accounts, users can have a Public or a Private (locked) account. This is to say that accounts can choose whether they automatically accept new followers or not. Unlike Twitter - a Private account can still post publicly, but can choose to default their posts to followers-only. And a Public account can still post privately requiring others follow them before they can see their posts. Along with that users can opt-themselves out of "Discovery" features and being indexed by search engines like Google.
Users also have the ability to block any account or any instance from seeing or interacting with their posts. So, even if the administrator at a given instance isn't willing to block other instances from federating with them, individuals still have the ability to.
Which brings us to Instance level moderation. On Mastodon, Instances can operate on either an Allow-List federation model or a Block-List federation model. This means that Instances have the power to either only connect and federate with pre-specified instances or they can leave their Instance open while maintaining a block-list of any and every instance they want to keep away.
Mastodon offers a lot of possibilities, a lot of control at multiple-levels - and that is exactly its problem. The amount of power awarded both to users and instance owners and the decentralized nature of the network creates an experience for the average user that isn't as straightforward as most people are hoping a social-media to be. Some of these issues can be overcome, with some ingenuity and some agreements between the current instances admin.