https://urbanists.social/@sam/110339902538138997
Let me start by making a list of his claims.
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. — @sam@urbanists.social
Not. In fact, this directly ties in to the idea that DIDs serve no purpose. Your server going down does not mean that all your followers are lost, because they don’t follow your account on the server itself. Instead, they have, in AT Protocol terminology, a “follow” record that points towards an imaginary document called a DID Document. This DID is basically your entire identity on the AT Protocol. It looks like this: did:plc:ofpi7p2eniusp5ckakb52p76
Now, there are many valid criticisms of DIDs, including that the kind BlueSky uses, DID:PLC, is extremely centralized. Every DID:PLC document is stored at a central registry, plc.directory. You can view a DID Document at https://plc.directory/did:plc:ofpi7p2eniusp5ckakb52p76 , for the example of my DID. This JSON document is what other people actually follow when they follow you, and it will have something that looks like the following in it:
service:
[
{
id: "#atproto_pds",
type: "AtprotoPersonalDataServer",
serviceEndpoint: "https://bsky.social"
}
]This tells everybody which ATProto server your data is actually stored at, and where clients and/or your server should look for it. So even if your server goes down, the DID which people actually follow is still there, and once you’ve moved to a new server, you simply use your recovery key to update your DID document to point to a new serviceEndpoint.
This is by no means a perfect system, especially since it forces everyone to rely on a central registry (plc.directory), and also forces people to keep a recovery key safe with them. Plus, if you want to restore all your actual posts and following list, etc, you have to keep a local backup of them in a CAR file. However, in my opinion, that is still a better system than the current state of things with Mastodon and ActivityPub, where there is no standard way to restore all your data between servers.
I may accidentally have started to address this while rebutting the previous point. But let me go a bit more in-depth here.
Since Sam brings up Mastodon specifically, rather than the Fediverse