Bluesky relays, Mastodon discovery providers
Comparing ActivityPub and AT Proto is a useful exercise. It’s tempting but ultimately too simple to say that one is decentralized and one is centralized. Bluesky’s app and relay are centralized but personal hosting in Bluesky is decentralized. Mastodon’s instances are decentralized but identity within an instance is tied to that instance. This makes for an odd comparison because it’s actually easier to migrate account data in Bluesky than it is in Mastodon.
Folks have criticized Bluesky from the beginning for not adopting ActivityPub. I think it’s clear now that the Bluesky team created AT Proto because they wanted to decouple certain aspects of the protocol, allowing for a high-performance infrastructure that could replace Twitter, while maintaining the benefits of the open web around hosting and domain names. Their strategy has paid off. Bluesky is growing very quickly and is now twice as large as Mastodon.
Centralized identity is an issue, though. Most people in the fediverse are hosted on a single Mastodon instance, mastodon.social, and everyone in Bluesky is tied to a single identity provider. The team at Bluesky obviously knows this limitation, which is why they named their scheme “placeholder” and hope to have management of it adopted by a more independent, ICANN-style organization.
I mention all of this as prelude to fediverse discovery providers. Discovery providers is a proposal for an open network of servers that effectively index Mastodon servers, providing a more universal timeline and search across servers, among other potential features such as spam filtering. These servers would serve a similar purpose to Bluesky’s relay. If this model becomes popular and apps are built to depend on it, it makes aspects of Mastodon slightly less decentralized, but the trade-off is worth it. Many people do want a more realtime, complete index of posts that are flowing through the fediverse.
For years Micro.blog customers have also asked for a firehose view of blog posts. I’ve avoided it, and I’ll continue to avoid it, because it creates new problems for spam and moderation. It’s great that Bluesky and Mastodon offer their own forms of this. Not all platforms need it, though, and as Bluesky and Mastodon become busier, Micro.blog will continue to carve out a quieter, slower niche on the social web.
In Micro.blog you don’t see everything because seeing everything is overwhelming. Our approach to notifications is also pared back. Micro.blog has a simple Mentions section to see replies and @-mentions. That’s it. It does not have a Notifications section like every other network, cluttered with likes, follows, and retweets. If you’re used to the dopamine hit of seeing someone like your post, this more limited view may take some getting used to. It’s not for everyone, and that’s fine too.
If Mastodon can add a relay-like service with discovery providers, I wonder if Bluesky could add its own additional layer at the community level. In other words, something that duplicates the benefits of having many instances with a small number of users — thousands or tens of thousands of users, not millions. This could address some concerns about Bluesky depending too heavily on a single company, especially if client apps could connect directly to a community server.
Mastodon and Bluesky both have their own strengths. Because they don’t completely overlap, neither platform feels finished yet. The social web is still young enough that we can shape it, borrowing good ideas wherever we see them. Both platforms have staying power.
I’m less concerned with having a single “winning” social protocol than some people are. The web is already that protocol. Blogs and social networks can coexist, each building on open APIs and contributing what they’re good at: blogs for content ownership and voice, social networks for community. The lines will blur. Interoperability will get better. The web is finally in a good place again.
