> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky?
Presumably to stop credential reuse attacks on Bluesky itself?
Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!)
I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
But this particular criticism seems unfounded.
It seems backwards to worry about attacks when basic functionality is undocumented/broken.
So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate?
I really like the ActivityPub approach more. There, if a domain changes hands, so potentially do all accounts associated with it. An account can be permanently deleted by sending a Delete{Person} activity to the network, but that doesn't prevent an account with the same username from being created again.
Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).
It's written in anger, but I'm optimistic that this will eventually get fixed, and documenting bad experiences like this will help.
Peer to peer, not federation, is the way forward.
We should only build peer to peer social protocols.
Websites and communities should simply sample from the swarm and make it easy for non-technical users to post and consume. They should be optional and not central points of failure (or control).
{Twitter, YouTube, Reddit, Instagram, TikTok, WhatsApp, Discord} should work like {Email, BitTorrent, PGP}.
Bluesky and Mastodon are the wrong architecture.
The web, fancy javascript UI/UX, and microservices shouldn't be the focus. The protocol should be the focus.
A fully distributed protocol would dictate the solution to this exact problem.
Email is the prime example of federated communication. From protocol inception to painful expansion and aging protocol all until corporate apropriaton. But I still think federation is the way forward, absolute centralisation is bad I'll let you figure why, but absolute decentralization is also bad, limitations due to its nature, unusual working for most users... Meanwhile federation is right in the middle, and users already use it with email without even noticing!
Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra.
Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But atproto architecture is a very fair experiment in this space. I can store my data on my own server, use a client app I wrote, subscribe to a specific aggregation/feed service I prefer, use the moderation list I want… all while still being connected to the larger protocol & network. It’s pretty neat.
You use routers as the beefy servers. Unicast, multicast, broadcast.
Unfortunately that means the implementation needs to reach all the way into the network layer.
So I agree with you that they should work like email -- but I've always said that Mastodon is better because it is like email; aka the power is in the nodes.
What do you think is wrong about Mastodon? Genuinely curious because I also am super skeptical that ATProto brings anything that we really need.
Unfortunately, the swarm is 99.99999% advertisements for penis enlargement pills. How can a P2P system filter them out? A federated system relies on each admin to filter them out. A centralised system does even better, relying on a single dictator to filter them out.
This isn't, and has never been a hard problem. Just pay for people's attention. People you follow don't have to pay, and make that transitive. Penalize people in your network who propagate spam by increasing the cost to get your attention.
If a scammer, advertiser, or some other form of spammer can get a payout just 1% of the time, they will be willing to pay much more than the average person posting the average tweet.
If you make everything explicitly transactional, you will be left with only people trying to make a profit.
Penis enlargement spam is worth like $0.00000001 per message. Any number higher than that makes them lose money. The real problem is that nobody will post on a social media network where you have to pay to post.
You have the graph of everything you follow, the graph of what they like, second order graphs ...
There are so many heuristics and models you can use to filter.
This is one of the most interesting properties of peer-to-peer networks.
You can run your own ingestion algorithms, and one of the things you can do is set up inbound rules that incorporate micro transactions.
We have to build a lot of infrastructure to make this work, but it seems ideal for a world full of agents and autonomous systems acting on our behalf.
Do the outbound rules of other participants include microtransactions?
And who besides a spammer would pay more than $0 to have their message read by you? If I wrote a blog post about vulnerabilities of blockchains, or how I ran Doom on a pregnancy test, and you don't read it because I'm not paying you, you're losing value, not me. You guarantee an inbox of only spam — but at least you get paid for it.
"View -> Page Style -> Basic Page Style" is required to read any of the text.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Indeed, it's a pity that the author placed so much focus on a cool looking font that they forgot to take basic properties like "good readability" into account. Form should follow function, not the other way around.
> Form should follow function, not the other way around.
According to whom? It's their personal website, they're allowed to place value on whatever they want.
According to them. They shared their opinion.
No, they asserted their opinion as a fact.
There is a world of difference between "I prefer x" and criticising something while asserting "everyone should do x (because I prefer x)".
> No, they asserted their opinion as a fact.
Interesting idea, let's see if they confirm they were talking facts. I'll be very surprised.
Or just toggle reader view (Firefox).
I don't have any issues with it but I've been computing since the 8 bit days which basically looked exactly like that :)
fair enough, the did:web flows are not documented even for technical atproto developers, and there needs to be a self-serve way to heal identity/account problems elsewhere in the network (the "burn" problem).
I do think that did:plc provides more pragmatic freedom and control than did:web for most folks, though the calculus might be different for institutions or individuals with a long-term commitment to running their own network services. But did:web should be a functional alternative on principle.
I'm glad that the PDS was easy to get up and running, and that the author was able to find a supportive community on discord.
Thanks for responding, Brian. While I don't agree with a lot of decisions Bluesky and the broader ATProto community have made, I am very excited that progress towards real decentralization is happening; Blacksky's app view, for instance, was the trigger for me to try to finally try to set up an account. I would love to see more of a focus on the parts of the system that make this difficult, so that myself and other people who are tired of coupling ourselves to centralized systems can participate. It's hard for me to trust that this is the direction the community is interested in moving, but I hope you prove me wrong.
I wrote a Bluesky app in preparation for a client project. ATProto is over-engineered for my purposes, though probably justifiably carefully engineered for the purposes of a big social Twitter-like thing. But since I didn't have to do the engineering, so what? It's a very solid platform for many kinds of multi-user information-sharing systems.
This article does give me the impression that I should make and use more test accounts than I currently do when mucking around with ATProto/Bluesky.
Complexity acts like a gate. When we make the code too hard to understand, we are telling regular people that they are not allowed to participate. True ownership of your data is only possible if you can actually afford to host it yourself. We should focus on making things simple enough for anyone to use.
My experience using ATProto is that it is somewhat like how the nascent blockchain apps were when they first came out: there's no written content that is viable. Instead, you're supposed to use ephemeral conversations and read a widely disparate set of notes in order to use it. In the end, the upshot of all this is that you get to use a slightly worse form of Twitter - which is already rather unpleasant to use for me because there's a lot of rage content there.
Microblogs are fun, and very often I can't justify a whole blog post, but I have seen that others just post their thoughts intermingled and it makes me wonder if perhaps that is what I should do. There's not that much utility to the wide audience anyway. Talking to people who understand you is much nicer anyway.
ATProto can be used be used for a lot more than just microblogs
Blockchain is still like that. Today I am setting up a blockchain node. The chain is actually two chains that recursively depend on each other. The docs say to start one of them first and wait for it to fully sync. It prints a timeout error for every block, saying the other chain node software was unreachable, and is estimated to catch up to current block height in about 200 years, which can't be right. Maybe I need to run both nodes at once contrary to the explicit instructions in the docs which say not to do so.
I wouldn't be surprised if half of all blockchains were vulnerable to some kind of trivial double–spend attack because it's not possible that all the complexity has eyes on it.
Edit: you're supposed to download a 2GB JSON file containing the state as of the last migration.
The normal way to set up most blockchain nodes these days is to rsync someone else's node's working directory. Obviously this is worthless as far as a decentralised and trustless system goes.
>you get to use a slightly worse form of Twitter
The protocol can support all sorts of other social networks. People are building things akin to instagram, tiktok, medium, allrecipies, etc
I'm building a place review system.
BlueSky has to be centralized right now because the quality of the federated network is too poor right now.
I am not convinced that is not by design.
This continues to confirm for me that there's nothing particularly valuable about ATProto, and that some of the percieved "flaws" in models like Mastodon's model are features just as much as bugs.
Honestly, this is making me go further in the other direction, can we just do "twitter but owned by a trust" or something?
No we can't. Beacuse at anytime people like Elon Musk can come in and mess everything up. If all of your data is in someones server you are one ban away from becoming noone. Of course that is still true with atproto since majority of users are on bluesky PDS's. But the whole tech is being designed in such a way to prevent such issues while still looking and acting qs traditional social media.
Twitter but run by a bunch of NGO PMCs sounds even worse than twitter.
Isn't that literally Bluesky? A PBC must act in the public interest.
The bigots and sociopaths will need a place to exercise their freeze peach. Groups that don't want to be involved with that rancor need a way to evict such people when they are disruptive. Wikipedia hangs on with its NPOV policy. You can't do that on centralized open fora where opinion is the currency of the realm.
The authors’ difficulty is legitimate and real, but there are less than 50 functioning did:web identities total on the planet.
Working outside of did:plc is a choice - this project is on the very ragged, least baked edge of Atmosphere development.
> Working outside of did:plc is a choice
What you're saying is: working outside of centralization is a choice. did:plc is a centralized database controlled by Bluesky.
Bluesky talks a big game about decentralization when it's extremely centralized. Everyone uses the centralized did:plc because it's the one way to really make it function. Until very recently, everyone used the centralized Bluesky AppView - and even now, well over 99% do. Bluesky will say things like "the protocol is locked open", but Bluesky could decide to shut off their firehose at anytime (leaving third parties cut off) and could decide to stop taking incoming data from third parties (leaving anyone on non-Bluesky servers cut off from basically everyone).
In a lot of ways, Bluesky is more like Twitter a decade or so ago. It offers APIs that third parties can use to build off of - but at any time, Bluesky could shut down those APIs. Back then, you could read the Twitter firehose and store the tweets and create your own app view with your own front-end if you wanted. Tweets would need to be sent to the Twitter APIs, but that's not really different than your third-party PDS server sending them to Bluesky if you want anyone else to read them.
You aren't open if someone controls the vast majority of a system because at any time they can decide "why are we doing this open thing? we could probably force the <1% of people elsewhere to migrate to our service if we cut off interoperability." Google Talk (GChat) offered XMPP federation and a lot of people bought into the platform because it was open. At some point, Google realized that the promise of openness had served its purpose and closed it off.
And it's important to think about the long-run here. Twitter was that benevolent dictator for a long time. Bluesky is still early and looking to grow - when they want people building off their system, giving them engagement, ideas, and designs they can copy. We're around year-5 of Bluesky. A decade from now after Bluesky builds its popularity on the back of "we're open and decentralized" while making decentralization extremely difficult, will that change? If Bluesky gets to a few hundred million users and then a third party starts looking like a potential threat, maybe they'll cut that off before they have genuine competition.
Maybe that won't happen with Bluesky. Maybe their investors won't care about the potential for a pay day. But if they have control (either through centralization like did:plc or by controlling the vast majority of the network), there will always be the potential for them to break interoperability. If they start monetizing Bluesky, why should they keep hosting, processing, and serving all that data for third party clients they can't monetize? Why shouldn't they stop federating with third parties before a third party becomes competition?
If Bluesky wants to be taken seriously they need to invest in decentralization themselves and not leave it as an exercise for the reader.
How many users actually care about decentralization?
None, and it's okay to make a centralised platform but I wish people wouldn't fall for the decentralised marketing hype.
Unfortunately most people couldn't care less. Bluesky has been lying about being decentralized since day 1, and yet they have millions of users.
Bluesky has been asymptotically approaching full decentralisation. A few years ago the gap was everything except a decentralised design, then it was AppViews, now it's "tooling and documentation" for the bit of the PKI that only 50 entities have done.
Meanwhile I lost my Mastodon account history because I moved once, couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance, lost my account again because I stopped paying for access to the instance I was on, all classic signs of centralisation.
> all classic signs of centralisation.
No, these are classic signs of decentralization.
> I lost my Mastodon account history because I moved once
Your posts still exist on every server that federated with you, there's just no central authority to coordinate reclaiming them.
> couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance
Independent implementations having compatibility issues is what happens when there's no central authority enforcing conformance. Frustrating, yes, but it's a symptom of decentralization.
> lost my account again because I stopped paying for access to the instance I was on
That's just how paying for services works. You could host your own instance, and nobody but yourself can revoke your access.
On Mastodon, if something goes wrong, nobody can cut you off the network entirely. On Bluesky, the author deleted an empty test account and is now blacklisted network-wide until Bluesky support decides to help. That is a classic sign of centralization.
Being beholden to a particular server I have no control over sounds like what happened with Twitter/X.
The posts might exist, but they aren't associated with me. Why not? Because I was locked into somewhere and unable to vote with my feet and go elsewhere.
Maybe I stopped paying because the instance owner enforced sanctions against my country? Why should I lose my identity because of that?
> Independent implementations having compatibility issues is what happens when there's no central authority enforcing conformance. Frustrating, yes, but it's a symptom of decentralization.
Compatibility issues means lock-in to instances under individual control. Shared protocols means lock-in to a protocol, but ultimately freedom to move. We know that open protocols trumps opt-in collaboration by private entities for freedom.
> You could host your own instance, and nobody but yourself can revoke your access.
See also: instances not federating with other instances that are too small. You technically can, but in practice it goes nowhere.
> On Mastodon, if something goes wrong, nobody can cut you off the network entirely.
Bluesky is not perfect, but where it's approaching full decentralisation quickly on a solid foundation, ActivityPub has become the Mastodon show, and is less a decentralised social network, and more a federated set of centralised services with little accountability to users. You can't move, you can't control the content you see, you can't even search. It's a reversion to the days of 14 year olds drunk on power as a mod on a phpbb forum, or the Reddit mods of today.
I honestly can't tell if this comment is trolling.
I'll admit it's a bit charged, but I'm frustrated with bad faith takedowns of ATProto/Bluesky, while Mastodon (and it is Mastodon, not ActivityPub) solves almost none of the actual problems. I tried implementing my own ActivityPub server and the spec is so hilariously lacking that it's understandable that everyone just uses the Mastodon API instead.
I think a lot of those users do care but they don't know they've been lying.
Key management shouldn't have to be difficult. Consider another open microblogging protocol nostr. There a keypair is crucial to the experience and every client automatically generates one if you don't have one to import.
I think this part of the UX is just being neglected by bluesky.
> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky?
Presumably to stop credential reuse attacks on Bluesky itself?
Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!)
I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
But this particular criticism seems unfounded.
It seems backwards to worry about attacks when basic functionality is undocumented/broken.
So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate?
I really like the ActivityPub approach more. There, if a domain changes hands, so potentially do all accounts associated with it. An account can be permanently deleted by sending a Delete{Person} activity to the network, but that doesn't prevent an account with the same username from being created again.
Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).
It's written in anger, but I'm optimistic that this will eventually get fixed, and documenting bad experiences like this will help.
Peer to peer, not federation, is the way forward.
We should only build peer to peer social protocols.
Websites and communities should simply sample from the swarm and make it easy for non-technical users to post and consume. They should be optional and not central points of failure (or control).
{Twitter, YouTube, Reddit, Instagram, TikTok, WhatsApp, Discord} should work like {Email, BitTorrent, PGP}.
Bluesky and Mastodon are the wrong architecture.
The web, fancy javascript UI/UX, and microservices shouldn't be the focus. The protocol should be the focus.
A fully distributed protocol would dictate the solution to this exact problem.
Email is the prime example of federated communication. From protocol inception to painful expansion and aging protocol all until corporate apropriaton. But I still think federation is the way forward, absolute centralisation is bad I'll let you figure why, but absolute decentralization is also bad, limitations due to its nature, unusual working for most users... Meanwhile federation is right in the middle, and users already use it with email without even noticing!
Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra.
Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But atproto architecture is a very fair experiment in this space. I can store my data on my own server, use a client app I wrote, subscribe to a specific aggregation/feed service I prefer, use the moderation list I want… all while still being connected to the larger protocol & network. It’s pretty neat.
You use routers as the beefy servers. Unicast, multicast, broadcast.
Unfortunately that means the implementation needs to reach all the way into the network layer.
So I agree with you that they should work like email -- but I've always said that Mastodon is better because it is like email; aka the power is in the nodes.
What do you think is wrong about Mastodon? Genuinely curious because I also am super skeptical that ATProto brings anything that we really need.
Unfortunately, the swarm is 99.99999% advertisements for penis enlargement pills. How can a P2P system filter them out? A federated system relies on each admin to filter them out. A centralised system does even better, relying on a single dictator to filter them out.
This isn't, and has never been a hard problem. Just pay for people's attention. People you follow don't have to pay, and make that transitive. Penalize people in your network who propagate spam by increasing the cost to get your attention.
If a scammer, advertiser, or some other form of spammer can get a payout just 1% of the time, they will be willing to pay much more than the average person posting the average tweet.
If you make everything explicitly transactional, you will be left with only people trying to make a profit.
Penis enlargement spam is worth like $0.00000001 per message. Any number higher than that makes them lose money. The real problem is that nobody will post on a social media network where you have to pay to post.
You have the graph of everything you follow, the graph of what they like, second order graphs ...
There are so many heuristics and models you can use to filter.
This is one of the most interesting properties of peer-to-peer networks.
You can run your own ingestion algorithms, and one of the things you can do is set up inbound rules that incorporate micro transactions.
We have to build a lot of infrastructure to make this work, but it seems ideal for a world full of agents and autonomous systems acting on our behalf.
Do the outbound rules of other participants include microtransactions?
And who besides a spammer would pay more than $0 to have their message read by you? If I wrote a blog post about vulnerabilities of blockchains, or how I ran Doom on a pregnancy test, and you don't read it because I'm not paying you, you're losing value, not me. You guarantee an inbox of only spam — but at least you get paid for it.
"View -> Page Style -> Basic Page Style" is required to read any of the text.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
https://news.ycombinator.com/newsguidelines.html
Indeed, it's a pity that the author placed so much focus on a cool looking font that they forgot to take basic properties like "good readability" into account. Form should follow function, not the other way around.
> Form should follow function, not the other way around.
According to whom? It's their personal website, they're allowed to place value on whatever they want.
According to them. They shared their opinion.
No, they asserted their opinion as a fact.
There is a world of difference between "I prefer x" and criticising something while asserting "everyone should do x (because I prefer x)".
> No, they asserted their opinion as a fact.
Interesting idea, let's see if they confirm they were talking facts. I'll be very surprised.
Or just toggle reader view (Firefox).
I don't have any issues with it but I've been computing since the 8 bit days which basically looked exactly like that :)
fair enough, the did:web flows are not documented even for technical atproto developers, and there needs to be a self-serve way to heal identity/account problems elsewhere in the network (the "burn" problem).
I do think that did:plc provides more pragmatic freedom and control than did:web for most folks, though the calculus might be different for institutions or individuals with a long-term commitment to running their own network services. But did:web should be a functional alternative on principle.
I'm glad that the PDS was easy to get up and running, and that the author was able to find a supportive community on discord.
Thanks for responding, Brian. While I don't agree with a lot of decisions Bluesky and the broader ATProto community have made, I am very excited that progress towards real decentralization is happening; Blacksky's app view, for instance, was the trigger for me to try to finally try to set up an account. I would love to see more of a focus on the parts of the system that make this difficult, so that myself and other people who are tired of coupling ourselves to centralized systems can participate. It's hard for me to trust that this is the direction the community is interested in moving, but I hope you prove me wrong.
I wrote a Bluesky app in preparation for a client project. ATProto is over-engineered for my purposes, though probably justifiably carefully engineered for the purposes of a big social Twitter-like thing. But since I didn't have to do the engineering, so what? It's a very solid platform for many kinds of multi-user information-sharing systems.
This article does give me the impression that I should make and use more test accounts than I currently do when mucking around with ATProto/Bluesky.
Complexity acts like a gate. When we make the code too hard to understand, we are telling regular people that they are not allowed to participate. True ownership of your data is only possible if you can actually afford to host it yourself. We should focus on making things simple enough for anyone to use.
My experience using ATProto is that it is somewhat like how the nascent blockchain apps were when they first came out: there's no written content that is viable. Instead, you're supposed to use ephemeral conversations and read a widely disparate set of notes in order to use it. In the end, the upshot of all this is that you get to use a slightly worse form of Twitter - which is already rather unpleasant to use for me because there's a lot of rage content there.
Microblogs are fun, and very often I can't justify a whole blog post, but I have seen that others just post their thoughts intermingled and it makes me wonder if perhaps that is what I should do. There's not that much utility to the wide audience anyway. Talking to people who understand you is much nicer anyway.
ATProto can be used be used for a lot more than just microblogs
https://tangled.org/
That is a really cool project, thanks for posting
Blockchain is still like that. Today I am setting up a blockchain node. The chain is actually two chains that recursively depend on each other. The docs say to start one of them first and wait for it to fully sync. It prints a timeout error for every block, saying the other chain node software was unreachable, and is estimated to catch up to current block height in about 200 years, which can't be right. Maybe I need to run both nodes at once contrary to the explicit instructions in the docs which say not to do so.
I wouldn't be surprised if half of all blockchains were vulnerable to some kind of trivial double–spend attack because it's not possible that all the complexity has eyes on it.
Edit: you're supposed to download a 2GB JSON file containing the state as of the last migration.
The normal way to set up most blockchain nodes these days is to rsync someone else's node's working directory. Obviously this is worthless as far as a decentralised and trustless system goes.
>you get to use a slightly worse form of Twitter
The protocol can support all sorts of other social networks. People are building things akin to instagram, tiktok, medium, allrecipies, etc
I'm building a place review system.
BlueSky has to be centralized right now because the quality of the federated network is too poor right now.
I am not convinced that is not by design.
This continues to confirm for me that there's nothing particularly valuable about ATProto, and that some of the percieved "flaws" in models like Mastodon's model are features just as much as bugs.
Honestly, this is making me go further in the other direction, can we just do "twitter but owned by a trust" or something?
No we can't. Beacuse at anytime people like Elon Musk can come in and mess everything up. If all of your data is in someones server you are one ban away from becoming noone. Of course that is still true with atproto since majority of users are on bluesky PDS's. But the whole tech is being designed in such a way to prevent such issues while still looking and acting qs traditional social media.
Twitter but run by a bunch of NGO PMCs sounds even worse than twitter.
Isn't that literally Bluesky? A PBC must act in the public interest.
The bigots and sociopaths will need a place to exercise their freeze peach. Groups that don't want to be involved with that rancor need a way to evict such people when they are disruptive. Wikipedia hangs on with its NPOV policy. You can't do that on centralized open fora where opinion is the currency of the realm.
The authors’ difficulty is legitimate and real, but there are less than 50 functioning did:web identities total on the planet.
Working outside of did:plc is a choice - this project is on the very ragged, least baked edge of Atmosphere development.
> Working outside of did:plc is a choice
What you're saying is: working outside of centralization is a choice. did:plc is a centralized database controlled by Bluesky.
Bluesky talks a big game about decentralization when it's extremely centralized. Everyone uses the centralized did:plc because it's the one way to really make it function. Until very recently, everyone used the centralized Bluesky AppView - and even now, well over 99% do. Bluesky will say things like "the protocol is locked open", but Bluesky could decide to shut off their firehose at anytime (leaving third parties cut off) and could decide to stop taking incoming data from third parties (leaving anyone on non-Bluesky servers cut off from basically everyone).
In a lot of ways, Bluesky is more like Twitter a decade or so ago. It offers APIs that third parties can use to build off of - but at any time, Bluesky could shut down those APIs. Back then, you could read the Twitter firehose and store the tweets and create your own app view with your own front-end if you wanted. Tweets would need to be sent to the Twitter APIs, but that's not really different than your third-party PDS server sending them to Bluesky if you want anyone else to read them.
You aren't open if someone controls the vast majority of a system because at any time they can decide "why are we doing this open thing? we could probably force the <1% of people elsewhere to migrate to our service if we cut off interoperability." Google Talk (GChat) offered XMPP federation and a lot of people bought into the platform because it was open. At some point, Google realized that the promise of openness had served its purpose and closed it off.
And it's important to think about the long-run here. Twitter was that benevolent dictator for a long time. Bluesky is still early and looking to grow - when they want people building off their system, giving them engagement, ideas, and designs they can copy. We're around year-5 of Bluesky. A decade from now after Bluesky builds its popularity on the back of "we're open and decentralized" while making decentralization extremely difficult, will that change? If Bluesky gets to a few hundred million users and then a third party starts looking like a potential threat, maybe they'll cut that off before they have genuine competition.
Maybe that won't happen with Bluesky. Maybe their investors won't care about the potential for a pay day. But if they have control (either through centralization like did:plc or by controlling the vast majority of the network), there will always be the potential for them to break interoperability. If they start monetizing Bluesky, why should they keep hosting, processing, and serving all that data for third party clients they can't monetize? Why shouldn't they stop federating with third parties before a third party becomes competition?
If Bluesky wants to be taken seriously they need to invest in decentralization themselves and not leave it as an exercise for the reader.
How many users actually care about decentralization?
None, and it's okay to make a centralised platform but I wish people wouldn't fall for the decentralised marketing hype.
Unfortunately most people couldn't care less. Bluesky has been lying about being decentralized since day 1, and yet they have millions of users.
Bluesky has been asymptotically approaching full decentralisation. A few years ago the gap was everything except a decentralised design, then it was AppViews, now it's "tooling and documentation" for the bit of the PKI that only 50 entities have done.
Meanwhile I lost my Mastodon account history because I moved once, couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance, lost my account again because I stopped paying for access to the instance I was on, all classic signs of centralisation.
On Mastodon, if something goes wrong, nobody can cut you off the network entirely. On Bluesky, the author deleted an empty test account and is now blacklisted network-wide until Bluesky support decides to help. That is a classic sign of centralization.
Being beholden to a particular server I have no control over sounds like what happened with Twitter/X.
The posts might exist, but they aren't associated with me. Why not? Because I was locked into somewhere and unable to vote with my feet and go elsewhere.
Maybe I stopped paying because the instance owner enforced sanctions against my country? Why should I lose my identity because of that?
> Independent implementations having compatibility issues is what happens when there's no central authority enforcing conformance. Frustrating, yes, but it's a symptom of decentralization.
Compatibility issues means lock-in to instances under individual control. Shared protocols means lock-in to a protocol, but ultimately freedom to move. We know that open protocols trumps opt-in collaboration by private entities for freedom.
> You could host your own instance, and nobody but yourself can revoke your access.
See also: instances not federating with other instances that are too small. You technically can, but in practice it goes nowhere.
> On Mastodon, if something goes wrong, nobody can cut you off the network entirely.
Bluesky is not perfect, but where it's approaching full decentralisation quickly on a solid foundation, ActivityPub has become the Mastodon show, and is less a decentralised social network, and more a federated set of centralised services with little accountability to users. You can't move, you can't control the content you see, you can't even search. It's a reversion to the days of 14 year olds drunk on power as a mod on a phpbb forum, or the Reddit mods of today.
I honestly can't tell if this comment is trolling.
I'll admit it's a bit charged, but I'm frustrated with bad faith takedowns of ATProto/Bluesky, while Mastodon (and it is Mastodon, not ActivityPub) solves almost none of the actual problems. I tried implementing my own ActivityPub server and the spec is so hilariously lacking that it's understandable that everyone just uses the Mastodon API instead.
I think a lot of those users do care but they don't know they've been lying.
Key management shouldn't have to be difficult. Consider another open microblogging protocol nostr. There a keypair is crucial to the experience and every client automatically generates one if you don't have one to import.
I think this part of the UX is just being neglected by bluesky.