Bluesky was initially created in 2019 as a research project tasked by Jack Dorsey and the then-Twitter, Inc. to develop an open, decentralized social protocol and social app atop that protocol. Twitter wholly funded this group of engineers, and the original intention by Jack Dorsey was to eventually move Twitter onto this new protocol to strip the platform of its centralization.
What is centralization? On a centralized social platform, one party controls the platform entirely, and one central server owns and controls the data. On a centralized social platform, you do not own anything you post or upload—they do. All of today's major social giants are centralized. However, decentralized networks are gaining steam and have no central authority or central server. Instead, user data is distributed across the network, giving users more power over their data.
So, how does Bluesky work?
Bluesky is built on the AT Protocol. The AT Protocol works off what they call Personal Data Servers, or PDSs. A Personal Data Server is a decentralized server that hosts all your data. When you sign up to Bluesky, by default, you're randomly placed on one of Bluesky's own Personal Data Servers, and whichever you're selected for, that's where all your Bluesky data lives—posts, reposts, replies, likes, follows, and blocks, among other things. All of this data is entirely public and can be read by anyone. To help visualize this, there's a fantastic website known as the AT Browser that lets you see what is on anyone's Personal Data Server. For example, here's a screenshot from the AT Browser of what's on my Personal Data Server:
The only AT Protocol app I use is Bluesky (and I only use the core features), so only Bluesky content is stored on my PDS. But there are several other AT apps, and they each write their own data to your PDS when you use them. For example, here's what my friend Jack’s PDS looks like in the AT Browser. He uses quite a few other AT Protocol apps, so his has a bunch of additional data on it compared to mine:
You could also write your own data to your PDS if you know how to. Hosting your own PDS and transferring it between different hosting locations is also possible, but this isn't recommended for most users because it can require a lot of technical know-how to ensure you don't lose all your data and get wiped from the AT Protocol. Apps also don't necessarily have to store content on your PDS; Bluesky, for example, doesn't store what accounts you've muted or the Chats, Bluesky's equivalent of DMs, you have with other users on the platform, but the majority of all content is.
Other apps can also read and use each other's data on your PDS. Here's an example from Jack of this in action:
let's say Instagram was built on ATProto [AT Protocol], you could keep your insta posts in your PDS, it might look for https://com.instagram.post.photo or something, then other apps can integrate and look for that data, so for example Bluesky could have a section called "Photos" which reads for that instagram data
What he's explaining here is that a photo-based app on the AT Protocol (in his example, Instagram) could store your uploads in a dedicated spot on your PDS that another AT app could recognize, read, and pull into a section of their app. And this ability is fantastic on multiple fronts. Most notably, what if you no longer like Bluesky? Say they made a decision you didn't like. Because other AT apps can read your Bluesky data, someone else could create a competitor on AT that ensures you aren't starting over again while distancing yourself from Bluesky. And they’d be able to associate it with your same identity on Bluesky because…
On AT, you have one all-encompassing identity.
When you sign up to Bluesky with one of their Personal Data Servers, they give you a bsky.social subdomain as a handle. This is because, on the AT Protocol, handles are domain names. Y'know, the things you type into a web browser to go to a website? For example, imagine my handle is brewer.bsky.social. This handle is my AT identity, and I can use it to log in to Bluesky and any other app on the AT Protocol. Theoretically, other AT apps could issue their own handles, but that would require them to host their own Personal Data Servers. These handles are considered “server-side.”
But there is another option. Because handles are just domains, nothing stops you from bringing your own. My handle isn't actually brewer.bsky.social, but rather, just thebrewergame.com because I own that domain. I could also use a subdomain if I wanted to, like matthew.thebrewergame.com. I don't even need a website set up on my domain (or subdomain) of choice to use it as my AT identity.
A custom handle like mine can actually serve as a decentralized form of a blue checkmark, too. One famous example the Bluesky team usually uses in this conversation is the British news organization NPR, which is on Bluesky with the handle npr.org. Because that is NPR’s official domain, and they’ve gone through the verification process, we know it's officially them. They can also verify additional accounts as being associated with them for no cost with subdomains. For example, if they wanted to confirm a journalist named Jane Doe, they could give Jane the handle jdoe.npr.org.
And finally… a quick tip before I go. If you have a .bsky.social handle, you can actually type it anywhere, and it becomes a link straight back to your profile!
Thanks to Jack for helping review this write-up! Be sure to follow him and me on Bluesky and across the ATmosphere at jglypt.net and thebrewergame.com, respectively, and until next time, I’ll see you around.