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.
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!!!!
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.
@Loukas No, your data is stored in a server that can be a community or an individual person. But that doesn't store your feeds, like Mastodon does. So like your feed on here exists on your server, and it's built by people sending messages to and from your server.
On Bluesky, there is a single, more 'global' feed called an indexer. That builds your feed.
@sam I had the opposite reaction. There is a huge potential in the long term benefit of having a large infrastructure of globally unique identifiers mapped to portable human names. This opens up the potential for strong public key verification and real authenticity to e2e communication.
DID potentially allows for better portability since you only are changing the human name, despite the problem of your archive. Yes, it is overkill for a social network, but it allows the AT protocol to be used for so much more. Imagine it combined with WhatsApp's new key transparency.
Yes, the AT protocol completely dodges the recovery problem, but so what? The recovery problem is hard and unsolved.
@elijah The crypto stuff *is* overly complex because human beings just don't care that much about cryptographically verifying that you have access to a private key. Keybase tried solving that problem, it was unprofitable and failed.
The AT protocol *is not a protocol*. It is API documentation for how to get your backend server to work with the Bluesky apps. If it was a protocol for federation, it wouldn't include 'invite codes', hard-coded authentication requirements, or any of the other shit.
@MetalSamurai @elijah This is correct, DID:PLC is basically DNS for DIDs. Then they layer DNS (domain names) on top of that. That is now two ways of doing effectively the same thing.
This is a pattern with the entire thing. Instead of using an OpenAPI spec, they invent XRPC (objectively useless). Instead of using JSON schemas, they invent Lexicon.
Each layer does barely anything and does not exist for a good reason. The sole function is increasing confusion and making it harder to implement.
@elijah @sam Elijah, I'm curious how this will play out for BlueSky with some fundamental human readability vs. decentralization tradeoffs such as the ICN naming tradeoff and Zooko's triangle. (Often folks point to biometric binding for DID's to get around Zooko's triangle, which is problematic from a privacy/trust standpoint.)
Mastodon avoids running into these problems because of its direct and implicit use of DNS for its namespace. (And use of DNS embedding in DIDs ends up undermining the value of flat naming.)
@rakoo @elijah @sam Would love to see this as a reality. Right now the usernames thing gets to folks but because there's a second @. They don't complain about the Bsky ones cause there's no second @, so it's like a domain. Doing some sort of repeat lookup starting from the first . in order to split the username/domain would be neat!
Would almost want to try crafting this; masto server at one domain, put a webfinger on another manually pointing, and create account manually that IDs as remote DNS
@sam The whole thing reminds me a lot of that "Web5" slide deck that was making the rounds last year.
So it turns out that the biggest difference between a fellow like Jack and me is that, while we both think about these things a lot, I look at the prior art and say, "Oh yeah, that's entirely possible with existing technology, so the problem is clearly meatspace."
Jack just thinks he can engineer a solution that will allow him to take investor dollars/make investors buckets of cash.
@sam They like to keep repeating that they are not a blockchain and not built on a blockchain.
But, yeah, at any point in time where a design decision had to be made, they choose the option that was most closely tied to the cryptochain bros while retaining the ability to deny any *overt* blockchain connections.
DID is one of the most awful W3C specs (and if you like bad specs, look into DIDcomm). And the hero image on https://ipld.io/ speaks for itself.
@sam Not my field, but does it have be visible? It’s my understanding DIDs solve the problem of encrypting the ownership of data, so anything a user publishes (and most sub-pieces of it) are always linked to their unique user dID? Is there something inherently bad about that concept in your view? Couldn’t it solve a lot of different problems for a renewed and more open web?
(I have no dog in any related hunts. Just looking for clarity).
@sam I actually really like the idea of local history for posts.
Storing lots of data on your phone can be expensive, but it's also expensive for server admins!
If everyone is responsible for storing their own toots as a backup, that gives a lot of resiliency to the network.
Sam 
Loukas (They/Them) 🏳️⚧️
bumblefudge
Vexnatos
Elijah Waxwing
Kevin Davidson
pg
INVISV
Stephen J. Anderson
rakoo
Kay Ohtie 🎈🌵🐺
Stanley Black-Decker
nilesh
Sammy (friend of foxes)
Jessamyn
Miles
Wayne Werner
husbandpanda 🐼
Polychrome 
John Francis
BibbleCo
Henryk Plötz
Shoq 🌿
SirLich