About Bluesky and federation:
Edit: There might be some mistakes, and my information could be outdated, but the point still stands - Bluesky wasn't built on 100% federation from the start.

I've been wondering about Bluesky's decentralization again. I can't think of any reason why I'd want to self-host Bluesky in its current form. I cannot 100% self host "my own Bluesky".

Their main selling points for building their own protocol were easier migration and better discoverability, but right now there's no simple way to migrate my Bluesky account to my own instance. And hosting the centralized parts yourself isn't really possible, or if it were, not affordable, they haven't made that feasible, by design, it seems.

Even if you self-host a PDS, Bluesky's Relay only indexes up to 10 accounts from it. You can run more, but they won't federate, the central infrastructure decides what gets seen. They control this (source: https://docs.bsky.app/blog/self-host-federation#:~:text=For%20a%20smooth%20transition%20into,for%20everyone%20in%20the%20ecosystem.). You can self-host a PDS (Personal Data Server), but you still depend on Bluesky's centralized Relay and AppView. There's no production-ready alternative infrastructure from what I gather.

It feels like I'd be renting a room in a hotel that someone else is running anyway, when I want my own hotel.

If Mastodon gGmbH vanishes tomorrow, my instance keeps running and federating with everyone else. If Bluesky PBC vanishes, the ecosystem would need to scramble to stand up replacement infrastructure that doesn't really exist yet.

ATProto keeps getting evaluated on its promises while other systems get evaluated on their merits. The "portability" selling point depends on infrastructure that isn't mature enough to actually catch you if Bluesky falls.

I trust W3C, the builders and fathers of the World Wide Web, ActivityPub and the Fediverse.

#Decentralization #SelfHosting #SelfHosted #Mastodon #Fediverse #Bluesky #Servers

Early Access Federation for Self-Hosters | Bluesky

For a high-level introduction to data federation, as well as a comparison to other federated social protocols, check out the Bluesky blog.

Well, I recently discovered that Bluesky got one step closer to decentralization:
It is now possible to set up DIDs without depending on Bluesky's services. If you look into the AT spec, you will find that there are now two types of DIDs that can be used for Bluesky: did:plc (which can only be issued by Bluesky) and did:web which essentially consist of a domain name. So an AT user of johndoe.example.com could have a DID of did:web:johndoe.example.com.

But now there are at

(1/3) @rolle #Bluesky

least 3 parts that remain to be done:
β€’ Alternative instances need own Relay and AppView -> should be feasable
β€’ Alternative instances need their own servers for private messages -> This is still a problem. How are you supposed to chat with someone if another instance can't find your chat server?
β€’ Bluesky still needs to adopt IPv6 -> This is also a problem. IPv4 is slowly heading for its end, and I wouldn't want to rely on IPv4 for Bluesky federation.

Another issue that
(2/3) @rolle #Bluesky

popped up recently is that Bluesky allowed ICE (Terrorist Organization) to open an account on their platform which might be a good reason for deferating them.

With those 3 issues (ICE, IPv4 and centralized Chat), I think I wouldn't want to federate with Bluesky anymore.

Oh, and btw, my Mastodon account which is bridged to Bluesky, recently was banned by Bluesky. I have no clue why this happened because Bluesky won't tell me.

(3/3) @rolle #Bluesky