The thing with Bluesky is that people want to believe.
You can go blue in the face pointing out that the decentralisation simply doesn't exist, and people say "hmm, well, benefit of the doubt, seems like they're working on it..."
You can give lengthy chapter and verse about how this is not a workable design for a decentralised system and it just doesn't get much response.
That's because people want to believe it, and so they do.
As briefly as possible:
If you read the spec, Relays jump out. There's a reason why there's only one and it's under the control of Bluesky.
did:plc (the usernames directory) jumps out. There's only one and it's under the control of Bluesky.
Appviews jump out. There's only one and... you get the idea.
*Lots* of people are looking at all this right now. If it were possible to run these things themselves, they'd be doing it for fun/interest. But it isn't.
(It is possible to run a relay in the strict technical sense of "possible", but it's a massive hosting cost for zero gain and so no one is doing so.)
Just to expand that last point, the relay (there is only one!) is a key part of the conjuring trick. It goes:
Q: Are you decentralised?
A: Yes, anyone can run a relay. It's open source.
OK, so what happens if you actually do that?
1. You have to re-host all data posted to Bluesky EVER.
2. You get to pay a load of money to do so.
3. You don't get to federate.
4. You don't get a say in the network.
No one has jumped at this opportunity, so there is only one relay – Bluesky's one.
If you push them further on this (as some people have) they'll say well, the relay is supposed to be run by some other big (hypothetical future) atproto-using app, not by hobbyists.
And then talk up the PDS (personal data storage) – a small piece which *is* practical to self-host – as "data portability" between these hypothetical future apps.
But this isn't decentralisation in any meaningful way. It's a fancy export mechanism.
The whole thing is sufficiently complex that a discussion of any component can easily be diverted into a discussion of a different one.
The key thing to remember is that a relay is too big to self-host on any reasonable scale. (Hypothetically a future company with money to burn could do it, but I'm not sure why they would.) From this the rest flows.
@tomw theoretical equality, a (neo)liberal specialty.
@DetersHenning Yes, that's an interesting way of looking at it. It is "possible" for you or I to run a relay in much the same way as it is "possible" for us to buy, say, a private island.
@tomw When you say "relay", are you talking about brid.gy?
Or is this something else?
@roland That's a Mastodon-Bluesky bridge which isn't 'officially' part of either system. A relay in Bluesky is a bit like an instance in Mastodon, except there's just one big one
@tomw Ah, thank you!
@tomw to me, even with the fediverse Relays seem like a single point of failure for injection - nothing stopping a bad actor selling ads being put into them.
@tanepiper The role of relays in the fediverse is minor – it's to help out smaller instances mostly. In Bluesky everything goes through the relay.
So it is a "single point of failure" in Bluesky but not fedi.
Also, relays are totally optional on the Fediverse. AFAIK most servers don't use them.
@FediThing @tanepiper Yes, it's the same name but not comparable.
@fabrice Yes, that is the one component it is currently plausible and practical to self-host, while relay, PLC and appview are not
@tomw Let's be honest, this is all as practical to self host as a Mastodon instance. It's really sad to see Mastodon aficionados criticizing BlueSky for things that are not better in the fediverse.
@fabrice Total number of Mastodon instances: thousands
Total number of Bluesky relays: 1
So take your false equivalence and bore off.
@tomw Re. the did:plc thing, even if issue over control of the database was fixed, there's the issue of control over the individual records.
If you are a Bluesky user and wanted to move your personal data to another server (or self host), you'd need to update your identity record to point at the new PDS.
The identity record lists a set of keys that are trusted to sign changes to the record. Those keys belong to Bluesky rather than the user.
@jamesh Yes, and their early language about this being a "placeholder" has shifted. They have no particular plan to replace it
@tomw It feels like they wanted to build a blockchain identity system, but took some shortcuts in the implementation and left out consensus and rollback prevention. So they could potentially rollback an identity to a state where it was controlled by a different set of keys.
They publish a full transaction log, so this could be detectable in theory. But I'm not sure what recourse you'd have.
@jamesh Yeah, the design has quite a lot of blockchain-inspired-looking elements but then tends to short circuit them ultimately
@tomw most of these complaints are non-issues if you think of the directory as a centralised service.
But by trying to make it look like it might be decentralised, it seems to have worse privacy than a simple centralised user database would have.
You can enumerate every account, including deleted accounts. You can also see the full username change history of every account. It seems like a great trove of information for research, but I'm not sure users are aware that it is being published.
@jamesh I noticed this warning the other day:
"Handle history could potentially de-anonymize account holders if they switch handles between a known identity and an anonymous or pseudonymous identity."
Of course this is buried on a page where hardly anyone will ever see it...