Åkesson walks through the actual machinery: handles are DNS TXT records and DIDs are rows in plc.directory, an append-only log operated by Bluesky PBC. Because the rotation key lives on Bluesky's servers by default, they retain the operational ability to rewrite a user's DID document, contradicting the 'decentralized' framing.
Half of the thread points out that users can run their own PDS, host their own handle via DNS, and explicitly export their rotation keys to remove Bluesky's control. The technical capability for self-sovereignty exists within the spec — it's just opt-in rather than default.
Counter-argues that essentially nobody actually self-hosts a PDS or rotates their keys off Bluesky's infrastructure. Because the protocol's defaults route every new user through Bluesky-operated services, the theoretical decentralization is irrelevant to the lived reality of millions of accounts.
The editorial argues that switching from did:plc to did:web doesn't eliminate trust dependencies — it just moves them from Bluesky's database to the DNS + CA system. You gain control of the JSON file at /.well-known/did.json, but lose it if your domain registrar, DNS provider, or CA misbehaves.
Kevin Åkesson's post — "Who Owns Your ATProto Identity? Hint: It's Probably Not You" — hit 124 points on Hacker News by walking through the actual machinery behind a Bluesky handle. The TL;DR: your `@you.bsky.social` handle is a DNS TXT record. Your underlying DID (`did:plc:abc123…`) is a row in `plc.directory`, an append-only log operated by Bluesky PBC. If Bluesky decides tomorrow that your DID document needs different signing keys, the protocol gives them the operational ability to rewrite it — there's a rotation key, and the rotation key lives on their servers unless you explicitly took it back.
The post isn't novel research. Atproto's own docs say all of this. What Åkesson did was line up the words "decentralized" and "federated" against the actual control surface and let readers draw the obvious conclusion. The HN comment thread split predictably: half pointing out that you *can* run your own PDS, host your own handle, and even export your rotation keys; the other half pointing out that essentially no one does, and the protocol's defaults route every new user through Bluesky-operated infrastructure.
The interesting move is to stop treating this as a Bluesky-specific complaint and ask the harder question: what would actually owning your identity on a social protocol look like? Three protocols have shipped three different answers. They are not equivalent, and the tradeoffs are sharper than the marketing suggests.
The atproto spec supports two DID methods. `did:plc` is the one everyone uses — a centralized, append-only directory hosted by Bluesky, where DID documents can be updated by presenting a signature from a rotation key. `did:web` is the one the spec also blesses — your DID document is a JSON file at `https://yourdomain.com/.well-known/did.json`, and you control it the same way you control any other file on your web server.
The catch with `did:web` is that you've moved the trust root from Bluesky's database to the global DNS + TLS PKI, which is a different kind of centralized but emphatically not less centralized. Let your domain registration lapse, lose control of your nameservers, get your cert revoked by a CA mistake, and your identity is gone. Worse, `did:web` identifiers are not portable: the identifier *is* the domain. Move to a new domain, and from the protocol's perspective you are a new person with no history. `did:plc` solves this by decoupling identifier from hostname — your DID is a stable opaque string — but the price is the directory.
Nostr took the third route and refused to compromise on ownership. Your Nostr identity is a raw secp256k1 keypair. The public key *is* your identity (`npub1…`). No DNS, no directory, no rotation key held by someone else. Lose the private key and you lose the account permanently — there is no recovery, by design. This is the cleanest answer to "do you own your identity," and also the reason Nostr's growth ceiling is determined by how many people are willing to manage a 64-character secret like it's the codes to a nuclear silo. The recent NIP-26 delegation work and various "nsec bunker" remote-signer projects exist precisely because raw key custody is a UX disaster.
The community reaction to Åkesson's post is worth parsing because it surfaces the actual disagreement. Bluesky engineers (including some posting under their real names in the HN thread) point out — correctly — that the protocol *permits* you to rotate your rotation keys away from Bluesky and onto hardware you control, after which `plc.directory` becomes a notary that can refuse to publish your updates but cannot rewrite them. Critics respond — also correctly — that "the protocol permits" and "the deployed system defaults to" are different statements, and that a decentralization story which requires every user to perform a key-management ritual is not a decentralization story that scales.
If you're building on atproto and identity ownership is a real product requirement — not just a marketing line — there are three concrete moves worth making. First, rotate your rotation keys away from Bluesky. The procedure is documented; it requires generating a key, signing a PLC operation, and submitting it. After that, Bluesky-the-company can no longer update your DID document without your signature. This is a one-time action and it materially changes your trust posture.
Second, register a real domain and use it as your handle. `@you.bsky.social` is a Bluesky-namespaced subdomain — they can take it back. `@you.yourdomain.com` is a TXT record you control. If you're shipping a product that issues handles to users, give them the option (and the tooling) to bring their own domain on day one; retrofitting this later is harder than getting it right in the constructor.
Third, if your threat model is "Bluesky PBC goes hostile or gets acquired," don't use `did:plc` at all. Use `did:web`, accept that your identifier is now domain-coupled, and design your application data model around the assumption that identity migrations will happen. For most consumer products this is overkill. For anything in the enterprise, gov, or journalism space — where the actual question is "can the platform operator be subpoenaed into impersonating my user" — it's the only honest answer.
The interesting thing about the next 18 months in decentralized identity isn't which protocol "wins." It's whether anyone manages to ship a fourth answer — something that gives you the cryptographic finality of a Nostr keypair, the human-readable handles of atproto, and the recovery story of a traditional account, without smuggling a central operator in through the back door. ENS gestures at this. Various account-abstraction wallet flows gesture at this. None of them have shipped at a scale where your non-technical sibling can use them. Until that happens, the honest framing is the one Åkesson landed on: pick which of {ownership, portability, usability} you're willing to give up, and stop pretending the protocols have abolished the tradeoff.
Who owns your domain name? Hint: it’s probably not you. Your hosting provider could take down your domain, or even steal traffic and direct it to their own IPs
One of the core features of AT is the ability to move your repo hosting provider (PDS) at any time. This is the "data portability" problem that ActivityPub never solved.Bluesky Social, PBC runs a PDS service (bsky.social) for free, there are a number of free public alternatives, and thousa
I think most people don’t need to worry about their host abusing its power to impersonate them, but the cool thing is, the people who do need to/want to worry (journalists, politicians, celebrities, activists, open source maintainers, etc etc etc) can self host a PDS and be a lot safer, and sti
Sure, somebody else holds your identity, but it's pretty easy to control it yourself. By its nature if you're using somebody to host your stuff, you're trusting them with it. I made Cirrus so you can self-host your PDS for free, but you still need to trust Cloudflare to run it.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Most people don’t worry about it for the same reason they don’t worry about GitHub abusing their GitHub account and are even willing to use “login with GitHub” to access their other accounts. Account takeover by a third party is a bigger risk. If you’re concerned about supply chain risks, there are