The identity stuff is hard to fit into a soundbyte. But I think it's still worthwhile keeping up on other protocols. To unpack atproto identity, the ultimate authority for identity for most people is did:plc, and the ultimate authority for did:plc is the self-signed and self-certifying operation log for each individual did. (There’s also did:web—but fiatjaf is right that that's like 100 or 200 weirdos.) The complaint against Bluesky is a directory complaint, specifically that they operate plc.directory, and that did:plc IDs need a lookup with a that particular Bluesky-owned server. That’s true to a degree, plc.directory is the largest and most used directory. To keep it honest people have set up mirrors and live replicas, and there can be active-active cross-replication, write-through, etc., but no getting around the fact plc.directory is the big fish. But zooming out, it’s, well, a directory. You need a directory, you don’t necessarily need that directory (or a single directory, as consensus from multiple directories also works). So the nuance is that the identity issue is a directory issue and not an underlining identifier issue. But most of that is besides the point. They’ve recently publicly confirmed plc.directory itself is moving to an independent org soon (some say ICANN, some say elsewhere) and it’ll also likely be grouped with other directories as part of a a consensus mechanism. We have to wait for that, but I'd be very surprised if it didn't. There are already 'outside of bluesky' implementations of relays, appviews, clients, etc. Once plc.directory moves out then these will be 100% outside of any control of Bluesky PBC. And there are thousands of independent PDSs, with their own keys. (Could be in a few months that the number of atproto users part of an infrastructure chain fully independent of Bluesky is higher than the number of nostr users.) Then the only control argument after that is that it's bad to have to trust ICANN or whatever org holds plc.directory (or it's bad to trust the consensus mechanism, which is even more unlikely to suffer from tampering.) Given that nostr (unlike Pubky) relies quite heavily on DNS itself, nostr arguments against ICANN would be a little much. Anyway for nostr it's worth being on top of these things because it helps you figure out where nostr is truly unique and where it's not. And then go hard where it is unique. And it prevents red-faced things from happening, like back when Primal announced how Primal offered far more algorithmic choice than Bluesky, having no idea what Bluesky actually offered in that department at the time (a lot more).