I was right about ATProto key management

> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky?

Presumably to stop credential reuse attacks on Bluesky itself?

Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!)

I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.

But this particular criticism seems unfounded.

It's written in anger, but I'm optimistic that this will eventually get fixed, and documenting bad experiences like this will help.

Complexity acts like a gate. When we make the code too hard to understand, we are telling regular people that they are not allowed to participate. True ownership of your data is only possible if you can actually afford to host it yourself. We should focus on making things simple enough for anyone to use.

My experience using ATProto is that it is somewhat like how the nascent blockchain apps were when they first came out: there's no written content that is viable. Instead, you're supposed to use ephemeral conversations and read a widely disparate set of notes in order to use it. In the end, the upshot of all this is that you get to use a slightly worse form of Twitter - which is already rather unpleasant to use for me because there's a lot of rage content there.

Microblogs are fun, and very often I can't justify a whole blog post, but I have seen that others just post their thoughts intermingled and it makes me wonder if perhaps that is what I should do. There's not that much utility to the wide audience anyway. Talking to people who understand you is much nicer anyway.

BlueSky has to be centralized right now because the quality of the federated network is too poor right now.

fair enough, the did:web flows are not documented even for technical atproto developers, and there needs to be a self-serve way to heal identity/account problems elsewhere in the network (the "burn" problem).

I do think that did:plc provides more pragmatic freedom and control than did:web for most folks, though the calculus might be different for institutions or individuals with a long-term commitment to running their own network services. But did:web should be a functional alternative on principle.

I'm glad that the PDS was easy to get up and running, and that the author was able to find a supportive community on discord.

"View -> Page Style -> Basic Page Style" is required to read any of the text.

The authors’ difficulty is legitimate and real, but there are less than 50 functioning did:web identities total on the planet.

Working outside of did:plc is a choice - this project is on the very ragged, least baked edge of Atmosphere development.

Key management shouldn't have to be difficult. Consider another open microblogging protocol nostr. There a keypair is crucial to the experience and every client automatically generates one if you don't have one to import.

I think this part of the UX is just being neglected by bluesky.