I still see the occasional plea for Bluesky to implement features pioneered by the old Twitter like private accounts and blue-checkmark user identity verification. It's really interesting to think about how social media platforms up until recently were huge monoliths where that was possible, and people are generally stuck in that thinking.
Bluesky is the reference implementation of an underlying technology called the Authenticated Transfer Protocol (or AT Protocol, or atproto) explicitly designed for a central entity to NOT have control over the whole thing. Yes, everyone (mostly, for the time being) goes to one place to interact with it, but behind that curtain exists enough moving parts to give even experienced systems engineers vertigo. I'm not one of those, but I at least have an interest and a limited understanding of how all this works... emphasis on limited. My perspective is based on my limited understanding. If I'm wrong, correct me.
Note: While Bluesky and the AT Protocol are designed and intended to be completely decentralized, it's not quite there in practice due to the relative infancy of the technology and some components not scaling well. For the time being, a more appropriate term may be distributed, not decentralized. Community efforts like Free Our Feeds are working to set up parallel infrastructure to operate these components outside Bluesky PBC[1] and help solve scalability problems. Despite this, AT Protocol has very clear design features showing its intended use as a fully decentralized platform.
To help us understand why implementing these features is not as easy as it seems[2], we need to look at what constitutes an "account". If you open an account on Bluesky (or any other future atproto-based platform), what actually happens is a "personal data server" or PDS[3] sets up a data store on your behalf called a "repository". You can think of it like buying a new blank journal. This repository is initialized with a set of cryptographic keys that allow you, the owner of the repository, to make changes to it[4] and everyone else to verify the integrity of the data it holds. Each action you take, like a post, follow, like, etc., is added as an event to this repository. This may not be immediately apparent, but these repositories are completely self-contained. If you like someone else's post, that fact is not attached to their post; it's recorded in your repository because that's the only place you have the authority to write. The self-contained nature of these repositories also allows them to be structured in a hash tree or Merkle tree so authenticating the data is much easier[5]. Each repository has its own "decentralized identifier" or DID, and Bluesky PBC operates a directory[6] where these DIDs are recorded.
From there, massive web services called "relays" go about ingesting changes to these user repos from all the known PDS instances out there and funneling every event into what is lovingly called the "firehose"[7]. From there, various applications — including the Bluesky frontend itself — take these event changes and construct the social graph people are accustomed to interacting with. It's only then that data from any one repository touches another. This structure is what makes Bluesky look like a monolith - their systems know about every action taken by every user and can connect all these interactions into a usable interface.
As I just mentioned, the Bluesky application knows about everything done by every user thanks to drinking from the firehose, but the application has no real authority of its own to change or enforce anything. The ultimate arbiter of changes to a given user's repository is the PDS holding it, and if you don't own a repository, you can't change it. This is why you can't remove followers — the record of a user following another is in the initiating user's repository. The frontend application takes these records essentially as instructions and slots posts from followed users' repositores in the timelines of the following users. The followed user is shown a list of followers as a courtesy. Blocking works the same way: if you block a user, that is recorded in your repository and the application you're using to interact with the platform will use that information to keep posts from users you block from appearing in any of your timelines. No one but you can remove it from your repository.
The end result from this design is that you cannot control who follows you. There is no one place that can enforce it. There are plenty of people who are reasonably concerned with this fact, but in my opinion, enclaves where access is strictly controlled is sort of antithetical to an open web social platform[8]. If you don't want everyone to be able to see what you post, maybe you should be looking at a group text or an email thread.
I'm finding that people really liked the blue checkmarks on Twitter. I never had one, so I'm indifferent to that, but if I had a nickel for every reply to Paul Frazee begging Bluesky to implement the exact same thing, I could probably buy myself a nice meal at a fancy restaurant. The problem with identity verification à la Twitter is similar to the private accounts problem: a feature like this requires centralization of some sort.
AT Protocol already has an elegant, open, and decentralization-friendly method of implementing external verification. Every user's repository has a DID which never changes, but social app frontends like Bluesky use domain names as handles. If you are a user who would have typically benefit from the blue checkmarks on Twitter, you invariably have a web site or some other internet presence[9]. You can publish a DNS record under your domain or serve a text file from a special path on your web site with the DID of your repository, and you will then be able to change your handle to the domain name you already control.
For some reason, when this is pointed out to people complaining about a “lack of verification”, the goal posts are almost always immediately moved to some perceived defect in this system, either that it's too hard or not accessible to the layperson. I think that's complete BS, because you're probably already typing nytimes.com or nbcnews.com into a web browser's address bar and implicitly trusting the content shown as a result. Seeing an account on Bluesky matching one of these domain names should be more than enough to know the same entity that controls that DNS zone (and by extension, the web site on it) also controls the repository.
We've all been burned by social media and the Big Tech moguls using first- and second-generation platforms as their playground. The first answer to the problem was packaging the entire experience into a single piece of software, standing up a bunch of copies of it all over the internet, and ensuring they can all talk to each other. This is the model used by Mastodon and other ActivityPub-based federated social media tools. Instead of one gigantic service holding on to all your data, you get to pick a small one to do the exact same thing. Nerds like me understand this intuitively, but for the average person, simply picking which server you'll sign up on is just too much trouble. It was a problem in 2017 and it remains a problem today.
Bluesky did a great job of smashing the platform into a collection of pluggable microservices, and by virtue of making it look monolithic, dramatically reduced the barrier to entry for your average user. It has also fooled a mind-boggling number of people who think ActivityPub is the One True Solution™ into believing it's just another social media platform subject to the same defects as the rest, an assertion that is flawed in multiple ways. Part of me wants to just think it's a defense mechanism because these folks went all-in on Mastodon and ActivityPub, and they're believing everything they read saying AT Protocol and Bluesky are bad.
Bluesky is good. ActivityPub is good. They can coexist.
Bluesky PBC is the "public benefit corporation" serving as the business entity responsible for AT Protocol development. ↩︎
Seriously, the people building this did a great job of making it look like a monolith. ↩︎
The vast majority of personal data servers are operated by Bluesky PBC — I'm sure this will change as time goes on. ↩︎
More specifically, the PDS holding your repository writes to it on your behalf. ↩︎
Other technologies using cryptographic hash trees include distributed version control systems like Git, resilient file systems like ZFS, and just about every blockchain implementation. ↩︎
This is one of the more centralized aspects of the platform; from what I gather, work is ongoing to make it more distributed. ↩︎
Bluesky PBC operates the only full-scale relay instance I know of. Free Our Feeds has explicitly stated their intent to set up another one, removing this dependence on infrastructure ↩︎
To make a statement dripping with opinion, Bluesky PBC understands that the correct response to the rise of the authoritarian right is not the authoritarian left. ↩︎
In my opinion, it's an absolute requirement for anyone who's serious about publishing anything, online or otherwise, to at least have a domain name. ↩︎