Fucking Christ the @protocol is the most obtuse crock of shit I've ever looked at. It is complex solely for the sake of being complex and still suffers from *all* of the same problems as Mastodon.
Your server goes down? Sorry, all of your followers are lost. Account portability is no better than Mastodon. 'DIDs' serve literally no purpose. And none of the API code that Bluesky uses in their own app validates ANY of the crypto they're doing on the server. NONE OF IT.
Not only that, but instead of just... making a simple Rest API spec or something simple, they REINVENTED THE FUCKING WHEEL and made 'XRPC' and 'Lexicon', AKA a shittier, less flexible version of OpenAPI and JSON Schema (respectively) that works with absolutely NO existing tooling.
The actual protocol itself is poorly confused and incredibly awfully designed. Because of the useless bullshit crypto they're putting into it, it requires you to write a server that's strongly consistent with other servers. THAT IS EXTRAORDINARILY HARD TO DO!! And BLUESKY'S OWN SERVERS DON'T HANDLE THE EDGE CASES!!!
It uses pull-based federation instead of push-based like Mastodon. You have to write a separate 'indexer' that has your 'feed' on it. That requires a LOT more resources.
And because things must be strongly consistent, AND because any user can REWRITE THEIR OWN FUCKING HISTORY AT ANY TIME, you have to, as an indexer, account for lots of different edge cases where your recorded history diverges.
The protocol for federation is built to make federation as difficult and painful as possible. It is built so that Bluesky, the private company that makes the protocol, is the only 'indexer', the only one with a whole view of the network.
WHY DOES A FEDERATION PROTOCOL NEED USER AUTH API METHODS IN IT???? WHY DOES A FEDERATION PROTOCOL NEED A CONCEPT OF 'INVITE CODES'??????
Oh wait, BECAUSE IT ISN'T A FEDERATION PROTOCOL!!! It's literally JUST the API for Bluesky. That's it.
It's quite literally impossible to use this in more flexible environments. You just can't. You cannot build anything on this because it is so poorly designed and isn't generic enough.
And I went into this with an open mind. I was like "I'll just make a simple alternative to the BlueSky server in Elixir". But it CAN'T be a simple implementation like ActivityPub can be, because it is extraordinarily complex and requires you to make guarantees about your storage and how your application works.
It turns out using Git, which is almost always used with a centralized 'remote', to do federation, which needs to be weakly consistent, IS A BAD IDEA!!!!!
What this comes back to is... who cares about any of the crypto bullshit? Having a private key and signing everything with it proves nothing because that private key must have a reputation.
You can verify a domain on Mastodon. You can point a domain to a Mastodon server. You can do that with Pleroma. You can make your own alternative to Mastodon that works exactly like how Bluesky works with domains, but it would take a 4th of the time because ActivityPub is simple to implement!!!!
The ONE thing that this protocol brings to the table is the idea of strong consistency in federation. The only issue is, it makes that strong consistency so resource intensive and so hard to implement that it decreases community servers' ability and ease of federation!!!!
And also, NOBODY CARES ABOUT STRONG CONSISTENCY IN SOCIAL NETWORKS!!! Social networks are built on the idea that we all have a different view of things. We care about seeing stuff from our friends, not seeing EVERYTHING.
The 'account portability' piece is bullshit! The way 'account portability' works is by having two separate keys, one for signing and one as a 'recovery' key. You're supposed to be able to use the 'recovery' key to rewrite history if your account gets hacked or some shit.
WE HAVE THE ABILITY TO DO THAT AS SERVER ADMINS!!! MASTODON HAS THIS ALREADY!!
Additionally, if a Bluesky server goes down, their way of keeping access to your data is by STORING ALL OF IT ON YOUR DEVICE!!!!
Imagine if I had to store the 50k+ tweets I've made on Twitter on my device, and upload ALL of them to a new server whenever a community server went down. Imagine being a server admin having to deal with people uploading tons of JSON data and media a whole bunch at a time. And if you're implementing the protocol correctly, EACH JSON BLOB REQUIRES VERIFYING THE SIGNATURE!! So you'd have to do 50K SIGNATURE VERIFICATIONS! WHICH IS CPU INTENSIVE!!! AND SLOWS DOWN THE SERVER!!!
Additionally, the domain name is NOT your identifier. If you have a custom domain, that is NOT your identifier. Instead you have a 'DID:PLC', which is a kind of 'DID' (invented by, not a surprise, CRYPTO PEOPLE).
There is NOTHING FUNDAMENTALLY USEFUL ABOUT THIS IN FEDERATION. Because this DID is never made visible to a user, it is not human readable (it's a hash), and it doesn't do anything!!!
And if you're wondering why this senseless overcomplication wreaks of the same crypto overcomplication, it's because THE CEO IS A CRYPTO PERSON!!!!
The entire protocol is just layering on top of a lot of some useless, bullshit standards that the crypto community built.
