In this article, I'll explain how Bluesky is a decentralized social media, and how this "decentralization" makes it different from traditional social media websites, like Twitter, Tumblr, Facebook, Instagram, Reddit, Youtube, TikTok, Plurk, etc.
Summary: Bluesky's so-called "decentralized" architecture should theoretically allow you to take all your data (your posts, followers, likes, etc.) and move it to a different service if you want in the future. Everyone that followed you on Bluesky will keep following you on this different service, and you will still be able to interact with users that use Bluesky from this other service. You can even host "you own Bluesky" if you have the resources to do so. However, it's worth noting that while the whole thing is designed to work like this in the future, currently much of it is under development.
Understanding Decentralization
The traditional social media website is centralized, in a sense. Centralization in general terms means that there is a single, "central" thing where all things in a system have to go to through to get anywhere. This has 2 consequences, regardless of sense:
- If the centralized component fails, all fails, because nothing can go anywhere without passing through it.
- If you want to block things from going through the system, you can block them in the centralized component.
There are many ways things can be decentralized, and only one of them is actually relevant to Bluesky.
Decentralization for Redundancy
For example, every large social media is decentralized in a sense. That's because they are huge.
Your basic web forum running PhpBB with a few hundred or thousand users can operate as a single server. This means all use of the forum would be centralized: it has to pass through this single server no matter what because it's the only server. If that server explodes, the whole forum is gone.
Large websites would lose a lot of money during downtime if their servers stopped working, so they pay a lot of money to design redundancy systems. In such systems, sometimes you will have multiple servers, sometimes around the globe, each with a full copy of the whole website, such that if one server explodes the website stays online because you can just route all traffic to the working servers.
Drawbacks of Decentralization
Decentralized systems are inherently more complex than centralized systems. When you have one server, that single server is the single "source of truth." Everything that is posted is posted to that server. Everything goes through it. But if we had two servers and some users posted to one server while other users posted to the other server, neither server would necessarily have the full picture any longer. We would need to synchronize both servers somehow so that they know what was posted on the other server.
Let's see a simple example of this added complexity.
Let's say every post has an unique text code that identifies it, so every time a post is posted, some program has to generate a unique identifier for it. The simplest implementation of such identifier is an incrementing integer. The first post has the ID 1, the second post the ID 2, the third the ID 3, and so on. All you need to do is keep track of what was the last ID you assigned, increment it by 1, and assign it to the new post.
In a decentralized system, we would have 2 servers handling the posts, and this simple solution would no longer work. Let's say the last ID generated was 100, and two users post at the same time, one to each server. One post should get the ID 101, and the other the ID 102. But both servers think the last ID generated was 100. So they both take this 100, add 1 to it, and both decide the new post they received should have the ID 101. Now we have 2 different posts with the same ID. One server says post 101 is one thing, the other server says post 101 is a different thing. We have a conflict that will cause trouble when we try to synchronize both servers.
This happens because both servers are "sources of truth" in a decentralized system. We don't have a central entity to decide which server is right about which post is the post 101. We trust both servers the same, hence the problem. The solution to this is to design systems that don't generate conflicts like these. For example, if we make all IDs generated by server 1 start with the letter A, and all IDs generated by server 2 start with the letter B. Then we would have A101 and B101. Different IDs even if it's the same number. This is such a common problem the solution for it has a name: Universally Unique Identifier, or UUID. And there are half a dozen different standards for it, like UUIDv1, UUIDv2, UUIDv3, UUIDv4, and so on, because even the simplest thing you can do in a decentralized system is extremely complicated.
Decentralization as we see above helps prevent that online services go down. More specifically, redundancy (having multiple components that do the same thing) prevents it, and decentralization is a side-effect of redundancy in web servers.
But that has nothing to do with Bluesky.
All social media have this sort of redundancy, because they are huge and would lose a lot of money if the servers went down for even a single minute. They have entire buildings full of servers in multiple parts of the world.
Decentralization against Censorship and for Crime
Another type of "decentralization" you may have heard about is decentralization to become censorship-resistant. Without a central authority, there is no way to completely block the traffic in a system, so a government, for example, wouldn't be able to just call the system's manager and threaten them with jail time if they don't stop the system.
This type of decentralization is typically associated with cryptocurrencies like Bitcoin, IPFS (where the JPEGs of NFTs are hosted until the server goes down and then the NFT stops working), and anonymous networks like Tor. The main use case for these things is crime. It can't not be crime.
In an oppressive government, the oppressor is the law, and going against it is the crime. It sounds noble because we don't like oppressive governments, but even in its noblest use case, this type of decentralization is still technically used for crime. Outside of oppressive governments, it's just used for normal crime, like trying to avoid paying income taxes, or taxes on international payments. If you create a system that the state can't take down with a court order, that's a criminal system created to obstruct justice. Just like if you steal from the rich to give to the poor, that's still stealing, so it's a crime.
It's not easy to have a good relationship with countries when your product promises to help people circumvent those countries' laws. Consequently, there are cases of entire governments deciding to ban such decentralized systems altogether, so they don't need to prove that you did anything with the systems, simply using the system is already the crime.
These systems work by having countless servers ("peers") that route messages from one peer to the other, hiding the IP address from the peer that sent the message, making it relatively anonymous. If a peer is taken down, a different peer can replace it. This redundancy is what makes it resilient.
But that also has nothing to do with Bluesky.
Bluesky wasn't created to be anonymous and censorship-resistant. At least not more than Tumblr or Reddit. You can still be anonymous on Bluesky if you choose not to disclose personal information about yourself on the social media. And you can resist censorship by Bluesky's owners by hosting "your own Bluesky" (in the future, probably). However, neither of these things can hide your acts on Bluesky from authorities with a search warrant. If they have a warrant, Bluesky will probably just give them all the information they have on you, including, for example, which IP addresses have logged into your account. Although the IP address alone can't identify a person, it's still a pretty big hint.
This means Bluesky isn't decentralized in the criminal sense, which is good because it means there is no risk of it getting banned from an entire country for aiding it users to circumvent those countries' laws.
What sense is left then? How is Bluesky decentralized, if at all?
The AT Protocol Architecture
Let's start by understand what exactly is Bluesky, because that is actually the most confusing part.
Bluesky isn't a single thing, but several. More specifically, Bluesky is based on top of the AT Protocol that is being developed alongside Bluesky.
Bluesky is a brand owned by someone. This someone is a corporation also called Bluesky. This is just like Reddit is owned by Reddit Inc. This is important to understand because when I say "you can host your own Bluesky," I don't mean you can actually copy the entire brand, I mean you can host the parts of it that matter. Similarly, if you joined an "alternative Bluesky social media," that would still be only some parts of what is bundled together in the term "Bluesky."
Nevertheless, these alternative Blueskies will STILL be able to communicate with the "main" Bluesky. In fact, they don't even need the main Bluesky at all.
This is just like the Internet.
Building Your Own Internet (Literally)
The Internet is an "interconnected network." What this means is that the Internet isn't "simply" one network, but a bunch of networks that connect to each other, forming a larger network.
To have an Internet, all we need are machines connected to each other that can communicate with the Internet Protocol (IP).
When you connect to the Internet, you don't "connect to the Internet." Your PC or smartphone connects to your router. What your router does is "route" messages from your computers to some computer identified by an IP address. But your router isn't directly connected to the target computer if it's on the other side of the planet. How does it send your message to it then? Your router needs to connect to other routers, which connect to other routers, and so on and so on, until it finds a router that is directly connected to the computer you want to communicate with.
If a single router explodes, this doesn't affect the Internet at all, since traffic can just pass through other routers instead. The Internet is a decentralized system.
Similarly, we could have a country that has "its own Internet" by using the Internet Protocol in its routers, but cutting all physical connections to routers outside the country. Everything would work just like the normal Internet, except nothing would go in the country or out the country.
The AT Protocol is the Internet Protocol of Bluesky.
If we have a bunch of servers that implement the AT Protocol, we can create our own Bluesky, even isolated from the main Bluesky.
So even in the worst case scenario that the Bluesky corporation becomes an evil Redsky corporation and starts cutting away everyone that doesn't agree with it, we can still recreate the whole thing without them because the AT Protocol is an open protocol. It isn't going to be easy, but it's not impossible either.
But that's not what we want, is it? We want to be able to take all of our data and move somewhere else, and still communicate with the main Bluesky. How do we do it then?
Coupling Identity to App
In traditional social media, the interface that users use to interact with other users is coupled with the service that hosts the user data. This means if you tweet something on Twitter by going to Twitter's website or Twitter's smartphone app, that tweet will be sent to Twitter's servers and will be hosted there. To display that tweet to other users, the Twitter's website or app has to pull the data from Twitter's servers where it's stored.
The perceived problem here is that it's all Twitter. This is the single point of failure, the centralization that Bluesky seeks to avoid.
Bluesky vs. Mastodon
Bluesky isn't the first one to try to create a decentralized social media. Previous efforts like the Fediverse exist, but it tries to solve the problem in a different way. A way that is actually very confusing, to be honest.
In the Fediverse, different social media can communicate through a common protocol called ActivityPub. Observe that this isn't the same protocol that Bluesky uses. Bluesky uses the AT Protocol, while the Fediverse uses the ActivityPub protocol. This means that Bluesky users can't interact with Fediverse users, despite both things being "decentralized social media." They are decentralized, but separate. Each their own system.
In the fediverse, there are several completely different projects, technologies, that implement ActivityPub. One of them is Mastodon, which is Twitter but in the Fediverse. Another one is Misskey, which is Japanese Twitter but in the Fediverse. We also have Lemmy, which is Reddit but in the Fediverse. And PeerTube, which is Youtube but in the Fediverse. Every social media has a Fediverse copy now.
These completely different social media can communicate with each other through the same common protocol. This means that in the Fediverse you can follow someone on "Fediverse Youtube" (PeerTube) from your "Fediverse Twitter" (Mastodon) account. You create an account in one service and you can follow anyone from any service.
Mastodon is often said to resemble e-mail because of this. You have one e-mail account and you subscribe to all these newsletters from all these websites. The only difference is that besides sending messages, you can also like posts and retweet ("boost") them.
These technologies are just technologies, which is where the confusing part begins.
Mastodon isn't a server or even the actual service. It's the technology that powers those. This means that in order to have "a Mastodon" you need to have a server and install "the Mastodon" on it. Then it works just like any website.
All these separate, interconnected Mastodons, Misskeys, Lemmies, and PeerTubes are called "instances." Mastodon hosting businesses started appearing to let non-technical people pay to have their own instances. For 5 dollars per month, you get your own social media just to host your own posts, that you can use to federate with everyone else.
I'm not very sure what is the point of this since that instead of trusting that an instance administrator isn't going to spy on you or kick you our of their social media platform, now you have to trust the guy you pay 5 dollars per month isn't going to spy on you or kick you out of their web hosting platform.
We can't escape having to trust people so long as we depend on others in this world, and we're always going to depend on someone for something.
Every Mastodon instance looks exactly the same by default, which is very confusing. You can barely tell if you are accessing mastodon.social, masto.social, or mastodon.world at first glance. These are completely different websites, owned by completely different people, that have exactly the same content (in fact I just checked and I saw literally the same post on both masto.social and mastodon.world, the whole thing is identical) because it's all connected to the federation.
In fact, it creates some intriguing philosophical questions.
Where the social media starts and ends?
Is mastodon.social and masto.social different social medias? Or is it one huge social media called "mastodon"? Or is the whole fediverse considered a huge but singular social media?
All of these are connected through the ActivityPub protocol, which literally any website can implement. Threads (the social media related to Instagram) has actually implemented the ActivityPub for some popular accounts. You can follow a Threads account from your Mastodon account today. So is Threads part of the fediverse now? Is it no longer a separate social media but part of the huge social media amalgation?
It's very confusing, isn't it?
You know those buttons you can click to share an article on social media? Creating one of those is very easy for most social media. Except for Reddit because it doesn't work for Reddit anymore since they redesigned the website, but don't tell them that, I want to see how long it takes for them to find out their legacy API isn't working anymore. If you wanted to create one of those buttons for Mastodon, you can't, because there is no singular Mastodon. There is no central Mastodon. The only thing you can do is make a button to share on some Mastodon instance. But which instance, when there are so many?
You have two choices.
First, you can make a button that shows a popup that asks the user the URL of their Mastodon instance just so you can redirect them to their instance's "new post" page. This is massively complicated compared to just have a simple button, and I bet most users would rather just copy the URL and access their preferred Mastodon instance from their address bar where autocomplete will work.
Second, you can make the reasonable assumption that everyone is in the "main" instance, so you only support that one.
In fact, pretty much everything to do with Fediverse is like this.
Everyone just joins the "main" instance, the "official" instance of Mastodon, Lemmy, etc., because centralization fixes a lot of problems that decentralization creates.
That doesn't mean decentralization is pointless. The Fediverse has succeeded in creating a decentralized social media. It's a very complicated one, but anyone can setup their own server and connect to all others very easily. This has democratized social media in a way. Anyone can join and they don't depend on anyone to do that. The only problem is that it's extremely confusing, and forced everyone who has to use the social media to deal with the complexities of decentralization.
If you try to use Mastodon, you'll often find yourself looking at something that looks like your social media, but you aren't logged in, even though you're sure you were logged in. That's because you clicked on a link that went to a different Mastodon instance, so everything looks the same, even if it's not.
If you have an account on Mastodon, you have an account in one instance, in one website. Other Mastodon instances have no idea who you are. You don't have an account with them.
If you want to move all your data to a different Mastodon instance, there is a chance you won't be able to even though there is technically a way to do it.
That's because all your data is in your instance's servers. If you signed up with a small instance created by someone just for a quick experiment, it's likely they won't maintain it for long. They have to pay for hosting. They aren't serious about it. The instance can suddenly shut down. Then you lose access to all your data before you have the chance to migrate to anywhere else.
Let's say that you do succeed in migrating, then your handle will be different. If you have an account on mastodon.social, your handle is going to be @[email protected], but if you move to mas.to, it's going to be @[email protected]. There is method in ActivityPub for telling a user has moved to a different instance, but it's won't be sufficient in all cases. For example, if you have hundreds of pages linking to your old handle on an old instance that shut down, nobody clicking those links will get the notice that you moved because the instance is no longer running.
All of these problems that the Mastodon has, Bluesky, or rather, the AT Protocol was designed to solve.
The key difference between Mastodon and Bluesky is that on Bluesky the user's data isn't coupled to the interface.
Decoupling of User Data
On Bluesky, all user data is stored on what is called a Personal Data Server (PDS). All your likes, followers, posts, etc., are stored in this PDS.
Every user has an unique identifier associated with them called a Decentralized Identifier (DID). If you ever see /profile/did:plc in your address bar, that's the DID of a user.
DIDs are like IP addresses. They uniquely identify every user, but they are just random letters and numbers, so humans aren't supposed to deal with them. You aren't supposed to memorize your DID, and in most cases you won't even know about it.
Instead, you just use handles like in any social media. On Bluesky, handles are like domain names. When you access the domain name www.virtualcuriosities.com, your web browser connects to a Domain Name Server (DNS) and asks it what's the IP address for that domain name. That's because computers can only connect to IP addresses, not to domain names, so in order to connect to a domain name, first you need to resolve that domain name into an IP address, and this is done by asking a DNS about it. Handles are resolved to DIDs.
Have ever seen a user with a handle that looks like a domain name? The way this is done in Bluesky is very simple! The owner of a domain name can set arbitrary metadata fields on the domain name they own. This metadata is reported by a DNS when requested. If you own a domain, all you need to do is set a metadata field called atproto with a value did=did:plc:... (i.e. your DID) and that's it. Bluesky can check with the DNS that powers the entire web to know what's the DID of the account of a website. Even if Bluesky becomes evil, anyone else would be able to just check with the DNS record figure out the DID of a website.
This means it's not possible for anyone to impersonate virtualcuriosities.com on Bluesky. The only account that can have this handle is the account of someone who owns virtualcuriosties.com and can edit the DNS metadata. Similarly, it's not possible for Bluesky to take the handle from me and give it to someone else. This is very important, considering:
- Elon Musk's X takes @X handle from longtime Twitter user, "July 26, 2023" [https://www.nbcnews.com/tech/tech-news/elon-musks-takes-x-handle-longtime-twitter-user-rcna96074]
- Longtime user ‘super pissed’ after Elon’s ‘X’ takes over his @music handle, "08/05/23" [https://thehill.com/policy/technology/4139274-longtime-user-upset-after-musk-takes-over-his-x-handle/]
- Elon Musk Seizes @America Handle on X to Promote Trump, "October 7, 2024" [https://www.pcmag.com/news/elon-musk-seizes-at-america-handle-on-x-to-promote-trump]
A domain name costs a lot less than 5 dollars per month, by the way. All you need to pay is a yearly fee to a registrar. As a plus, if you can find free web hosting somewhere that lets you set a custom domain for free, like Netlify, you can have your own website, so you might not even need a linktr.ee page anymore to organize your ever-growing list of alternative social media accounts.
A handle is just a nickname for a DID. The DID refers to data in a PDS, so whoever controls that PDS controls all the data.
The decentralization of Bluesky is that you can host your own PDS. If you do this, just like with Mastodon, the data is all yours and nobody can take it from you, or assert ownership over it. This is important, considering:
- Elon Musk's X Asserts Ownership Over User Accounts Amid InfoWars Sale to The Onion, "11/27/2024" [https://www.msn.com/en-us/money/news/elon-musks-x-asserts-ownership-over-user-accounts-amid-infowars-sale-to-the-onion/vi-AA1uSgAb]
More technically, in order to publish posts securely, it's necessary to sign them cryptographically with cryptographic keys. This method ensures that someone without the keys can't impersonate someone else. However, it doesn't prevent someone that DOES have the keys from impersonating other people. When you create an account on Bluesky, Bluesky has your keys. Instead of using keys to post, you simply log into Bluesky with your handle and password. You authenticate with Bluesky, and Bluesky signs your posts for you.
The idea that Bluesky can impersonate you if they turn evil may sound scary, but this has nothing to do with the fact that they have your keys. Any instance administrator on Mastodon for example can impersonate any user on their instance. And let's never forget that Reddit's administrator Spez forged a user's comment that one time. This is possible for any website owner with database access.
All your data is attached to a DID, and a handle is just a nickname for your DID. This means you can change your handle as many times as you want, and you'll never lose followers because your followers are actually following your DID, not your handle. Similarly, you could move all your data to a different PDS, migrate away from Bluesky and start self-hosting, and you wouldn't lose followers like on Mastodon becaus they're following your DID, they aren't following your PDS.
If you can host your own PDS, and the DID refers to a user's data in a PDS, how does Bluesky figure out the IP address of the Personal Data Server containing the user data for a given DID? It resolves the handle to a DID, but how does it resolve a DID to a PDS?
Well, have you ever heard the phrase "there is nothing more permanent than a temporary solution"?
So it seems Bluesky actually supports two types of DIDs, one is did:web, but because it had some problems, Bluesky created another type, called did:plc. The plc stands for "placeholder." But it's now a backronym for "Public Ledger of Credentials."
[...] Today, did:plc stands for "Public Ledger of Credentials", however it originally stood for "Placeholder DIDs", with the hope of replacing them with something else later. The way that did:plc works is that Bluesky hosts a web service from which one can register, retrieve, and rotate keys (and other associated DID document information). However, this ledger is centrally controlled by Bluesky.
https://dustycloud.org/blog/how-decentralized-is-bluesky/ (accessed 2024-11-29)
When you create an account on Bluesky, you get a plc DID. While you can change your handle without losing followers, it's not possible to change your DID without losing followers, since this is the permanent identifier to which all your data is associated. This means you can't switch from did:plc to did:web, whatever benefits there might be.
[Question]
While migrating to a new PDS is a challenging but supported task, is it also possible to migrate my current did:plc identity to a did:web identity either separately or at the same time (while keeping my handle the same in all cases)?
My current understanding is this is likely impossible, given it's the identifier for my account, and other relationships (such as followers) will suddenly lose track of me.
[Answer]
Yup, that's pretty much it. You can keep your handle and point it at your new DID, but all in-protocol references are based on the DID. You will lose your followers, for example (because they're "following" your DID, not your handle).
You could in theory re-import your old posts, but they'd lose any existing replies/likes/etc., and any threads would be broken
https://github.com/bluesky-social/atproto/discussions/2705 (accessed 2024-11-29)
To resolve a PLC, you need to connect to plc.directory. This is literally a website. It gives a JSON response with data about a DID, including what is the URL of the PDS that hosts that DID, e.g. https://morel.us-east.host.bsky.network.
Essentially, this plc.directory website is acting just like a DNS. When you access plc.directory, your web browser asks a real DNS what is the IP address for the domain name. When Bluesky finds a DID, it asks plc.directory what is its PDS.
I think I read that while Bluesky owns plc.directory there are plans to make it more public somehow. In any case, if its only purpose is to be a centralized way to resolve a DID into a PDS, then you should be able to easily replace it if Bluesky ever turns into an evil Redsky.
So let's recap a bit just to be clear.
Let's say your handle is example.bsky.social.
Bluesky uses the DNS that powers the entire web to resolve example.bsky.social. This is just like how Tumblr does it for its subdomains. Doing that, it can figure out what is the DID for the domain name.
It takes this DID and asks plc.directory what is the URL of the PDS. This is a centralized service, but an alternative Bluesky could replace it with an alternative more open directory if it wishes.
It then goes to the PDS (which you can self-host) and there it can find the user's data.
Alright, so you have your own domain that points to your own DID stored in your own PDS. But how do you connect to other people without depending on a third party?
That's the neat part: you don't.
Bluesky lets you own the PDS where your data is stored, but as we know from the Fediverse, making users responsible for multiple aspects of the social media at once creates a lot problems. Instead of decentralizing the social media into multiple interconnected instances, Bluesky split the social media into 3 layers, then decentralized EACH layer.
In order to actually "use" Bluesky you need an app. Such app is https://bsky.app/. However, there are others that you can already use today. If you have experience with TweetDeck for Twitter, there is a similar project called https://skyfeed.app/. You'll see it asks for an "app password" to be used. You need to go to your security settings in bsky.app to create an app password so you can use skyfeed.app without it having complete control over your account.
Presumably you only need to go through bsky.app because you created an account via bsky.app, so you made Bluesky (the app/brand/corporation) the custodian of your data as your data is in their PDS and they have your keys. I assume you would be able create these app passwords without bsky.app if you self-hosted or had someone else manage your data.
You can find many similar projects at [https://docs.bsky.app/showcase].
So we have a decentralized user data storage layer, and a decentralized interface layer. What is the third layer?
Relays.
Relays are what make Bluesky fundamentally different from Mastodon.
When a user posts in one Mastodon instance, their instance sends their post to every instance that has someone who follows them. This means that in order to "follow" someone on Mastodon, your instance has to ask the other instance to send a notification when a new post is made. This is very efficient because it only sends messages to servers that need to receive those messages when a new post is made.
On Bluesky, every PDS is constantly streaming all data that is getting posted. Officially, this stream of data is called a "firehose." The job of a relay is to aggregate all these "firehoses" into a bigger firehose so that apps only need to fetch data from the big one instead of countless smaller ones.
The relay is a server that slowly fetches data from the PDS's to create a "world" containing all the data from everyone. This is just like how Google and other search engines use programs called spiders to "crawl" the web, indexing every web page out there. The relay's job is to crawl every PDS and then relay their data to the apps.
These things aren't cheap to maintain, and Bluesky is still operating without ads. It's very likely it will have ads in the future, and access to its firehose may become limited to apps that can pay API fees.
However, anyone can build their own relay. It just costs a lot of money, so anyone who builds a relay will need to figure out how to make enough money to pay for their relay. If Bluesky's "main" relay starts charging exorbitant fees, apps would have the choice to create an alternative. Will they actually be able to make their alternative relay cheaper than the fees they would be charged? Maybe, maybe not. But they have the freedom to try, and that's what really matters.
On Mastodon, and much of the Fediverse, there doesn't seem to be any ads at all. Many instances survive from donations from its users. Those that can't survive just shut down.
Let's say that, hypothetically, a successful alternative relay is created, but Bluesky decides it will start charging the relay for access to the data in its PDS's. This would fragment the AT Protocol network and make some users very sad when they can't communicate with their friends that use alternative relays, but evil Redsky is evil, so it doesn't care.
Even in the worst possible case the situation is still better than in "centralized" social media. For example, let's say you decide to boycott Bluesky and leave at all costs. They have your data hostage, so you give up on it. You still have an ecosystem of many apps and relays that work with each other. If you find a PDS that isn't evil (or self-host), you can rejoin the social media with familiar tools instead of starting from scratch.
However, it's very likely that won't be necessary. The PDS's give a lot of data to the relays, so even if Bluesky turned really evil, it's likely you would find some migration tool that let you at least recover all your likes, posts, and people whom you follow. You still wouldn't be able to transfer your followers in this nightmarish scenario, however.
The Solution to Evil Redsky
As you may have noticed, Bluesky isn't really decentralized. The AT Protocol is. Decentralization is about redundancy. If you invest a lot of time posting on Bluesky, and then one day Bluesky fails, there isn't much you can do about it.
They own the service that resolves the DIDs. They own your keys. They have a relay that costs a lot more money to run than a simple 5 dollar Mastodon instance. One feature that Bluesky has, direct messages (chatting), isn't even built into the AT Protocol at all. It's completely centralized, just like a typical centralized social media. Because users needed it NOW and it would take too long to implement it in the protocol.
If the blue skies suddenly turned red, and someone decided to pull the plug and delete all of it tomorrow, you would lose all your data with no recourse. How can this be considered more decentralized than a single PhpBB forum that disappears if a single server explodes?
Is there no technology that we can use to prevent such tragedy? Perhaps blockchain? Perhaps AI? How can we stop this evil, sporadic behavior that seeks destruction without purpose?
Fortunately, there is a technology that solves this.
It was invented by people much brighter than I. It doesn't even require a computer!
It's called a contract.
The thing that we're afraid of is that Bluesky will stop supporting decentralization and become a closed platform, making any efforts to support decentralization a huge waste of time. That is always technically possible to happen. And if it can happen to Bluesky, it can happen to anyone. Even if you migrate your PDS from Bluesky to some alternative Greensky, there is no guarantee Greensky won't also become evil. There is no algorithm to prevent this.
That's because this isn't a software problem. This is a dependency problem.
We depend on Bluesky to do X. If it stops doing X, we'll have a big problem. But we have trust issues, so we can't trust Bluesky to keep doing X forever. How can we ensure that Bluesky keeps doing X forever?
I'm not a lawyer, but I'm pretty sure this is what contracts are for.
If Bluesky was bound by a contract to provide some service to you, it wouldn't be able to stop providing it without opening itself to a lawsuit.
Every social media has a terms of service, but they're generally focused on what YOU give the platform, e.g. content licensing terms, not on what the platform guarantees you. If in such terms it said that Bluesky HAS to let any relay access the PDS's with your data, we wouldn't have to be afraid of Bluesky randomly cutting access to alternative relays. The same applies to all parts of the system that can be decentralized.
Even if Bluesky doesn't do this, Greensky could. And everyone that cares could just use Greensky.
There is now the technological support for creating this decentralized social media. All we need are some legal guarantees to fix the holes that the software can't patch, and that should be enough to make it as good as it gets. Not "perfectly decentralized" but still much better than the "centralized" social media we currently have nonetheless.
Let's just hope that they figure out a way to make money from it.
Observations
Central Disappointment: I've noticed that a lot of Bluesky's "decentralized" features that users love have absolutely nothing to do with decentralization. It makes sense, since currently it seems there really is only one relay, almost everyone just uses the same app, and most users are on Bluesky's PDS's, there is almost nothing in Bluesky currently that is actually decentralized.
For example, Bluesky lets you create custom feeds, and subscribe to moderation lists (block lists). This is perfectly doable by centralized social media. It would probably be EASIER to do it centralized since there is no overhead from decentralization. And yet centralized social media lack these features.
This has nothing to do with whether it's centralized or decentralized. The only reason Tumblr doesn't have block lists is because it doesn't. Nothing in its "centralized" design prevents it from having such feature.
Similarly, Bluesky has algorithmic feeds. Some think that "the algorithm" is something that only exists in centralized social media, but that's clearly not the case in Bluesky since the first thing you see when you create a new account is a "Discover" feed that is clearly algorithmic. Bluesky simply designed a way to have a recommendation algorithm in a (potentially) decentralized social media.
Decentralized Purism: I've read some people argue over what exactly constitutes as truly "decentralized." As we have seen, there are many, completely different reasons for wanting something to be decentralized. In my opinion, "decentralization" is a terrible term. It gets worse when people get pedantic about it and start throwing even more complicated terms like "distributed" or "federated."
For instance, one could argue that SSL isn't decentralized because it depends on centralized root certificates. Since almost every website uses HTTPS nowadays, that means the web itself isn't decentralized.
That's cool, but nobody is trying to replace the Internet. All we want is a place to post cat pictures. I think Bluesky is enough.
Other Perspectives
- How Does BlueSky Work? [https://steveklabnik.com/writing/how-does-bluesky-work]
- How decentralized is Bluesky really? [https://dustycloud.org/blog/how-decentralized-is-bluesky/]
Leave a Reply