To start, let’s verify that Bluesky the app is indeed open-source. Yep, it is. But that’s not the same as having all the machinery be open-source, where anyone could spin up their own, compatible service; maybe named ExampleSky. To be compatible, ExampleSky would need to use the same backend interface – aka protocol – as Bluesky, which is known as ATProto. The equivalent (and older) protocol behind Mastodon and Lemmy is ActivityPub.

ATProto is ostensibly open-source, but some argue that it’s more akin to “source available” because only the Bluesky parent company makes changes or extensions to the protocol. Any alternative implementation would be playing a game of chase, for future versions of the protocol. History shows that this is a real risk.

On the flip side, Mike Masnick – founder of Techdirt, author of the 2019 paper advocating for “protocols, not platforms” that inspired Bluesky, and recently added member of the board of Bluesky – argues that the core ability to create a separate “Bluesky2” is where the strength of the protocol lays. My understanding is that this would act as a hedge to prevent Bluesky1 from becoming so undesirable that forking to Bluesky2 is more agreeable. To me, this is no different than a FOSS project (eg OpenOffice) being so disagreeable that all the devs and users fork the project and leave (eg LibreOffice).

But why a common protocol? As Masnick’s paper argues, and IMO full agreement with what ActivityPub has been aiming towards for years, is that protocols allow for being platform-agnostic. Mastodon uses are keenly aware that if they don’t like their home instance, they can switch. Sure, you’ll have to link to your new location, but it’s identical to changing email providers. In fact, email is one of the few protocol-centric systems in the Internet in continued use. Imagine if somehow Gmail users couldn’t send mail to Outlook users. It’d be awful.

Necessarily, both ActivityPub and ATProto incorporate decentralization in their designs, but in different fashions. ActivityPub can be described as coarse decentralization, as every instance is a standalone island that can choose to – and usually does – federate with other instances. But at the moment, core features like registration, login, or rate limiting, or spam monitoring, are all per-instance. And as it stands, much of those involve a human, meaning that scaling is harder. But the design suggests that instances shouldn’t get too large, so perhaps that’s not too big an issue.

ATProto takes the fine-grained design approach where each feature is modular, and thus can be centralized, farmed out, or outright decentralized. Now, at this moment, that’s a design goal rather than reality, as ATProto has only existed for so many years. I think it’s correct to say for now that Bluesky is potentially decentralizable, in the coarse sense like how Mastodon and Lemmy are.

There are parts of the Bluesky platform – as in, the one the Bluesky organization runs – which definitely have humans involved, like the Trust and Safety team. Though compared to the total dismantlement of the Twitter T&S team and the resulting chaos, it may be refreshing to know that Bluesky has a functional team.

A long term goal for Bluesky is the “farming our” of things like blocklists or algorithms. That is to say, imagine if you wanted to automatically duplicate the block lists that your friend uses, because what she finds objectionable (eg Nazis) probably matches your own sensibilities, then you can. In fact, at this very moment, I’m informed that Bluesky users can subscribe to a List and implement a block against all members of the List. A List need not be just users, but can also include keywords, hashtags, or any other conceivable characteristic. Lists can also be user-curated, curated by crowd sourcing, or algorithmically generated. The latter is the long goal, not entirely implemented yet. Another example of curation is “Started Packs”, a List of specific users grouped by some common interest, eg Lawsky (for lawyers).

So what’s wrong with Bluesky then? It sounds quite nice so far. And I’m poised to agree, but there’s some history to unpack. In very recent news, Bluesky the organization received more venture capital money, which means it’s worth mentioning what their long term business plan is. In a lot of ways, the stated business plan matches what Discord has even doing: higher quality media uploads and customizations to one’s profile. The same statement immediately ruled out any sort of algorithmic upranking or “blue checks”; basically all the ails of modern Twitter. You might choose to take them at their word, or not. Personally, I see it as a race between: 1) ATProto and the Bluesky infra being fully decentralized to allow anyone to spin up ExampleSky, and 2) a potential future enshittification of Bluesky in service of the venture capitalists wanting some ROI.

If scenario 1 happens first, then everyone wins, as bridging between ActivityPub and ATProto would make leaps and bounds, and anyone who wants their own ATProto instance can do so, choosing whether they want to rely on Bluesky for any/all features or none at all. Composability of features is something that ATProto can meaningfully contribute to the protocol space, as it’s a tough nut to crack.

But if scenario 2 happen, then we basically have a Twitter2 cesspool. And users will once again have to jump ship. I don’t personally use Bluesky, being perfectly comfortable in the Fediverse. But I can’t deny that for a non-tech oriented audience, Bluesky is probably what I’d recommend, and to opt-in to bridging with the Fediverse. Supposed episodes of “hyping” don’t really ring true to me, but like I said, I’m not currently an invested user of Bluesky.

What I do want to see is the end result of Masnick’s paper, where the Internet hews closer to its roots where interoperability was the paramount goal, and the walled gardens of yore waste away. If Bluesky and ActivePub both find their place in the future, then IMO, it’ll be no different than IMAP vs POP3.