Åkesson argues that the 'account portability' marketing pitch breaks down under spec-level scrutiny: handles resolve through DNS (owned by registrars or Bluesky PBC for bsky.social subdomains), and ~99% of DIDs use did:plc, a centralized log run by Bluesky PBC that holds rotation keys and can in principle rewrite identity history. He concludes that while PDS portability is real, identity portability is not, because the resolvers sit on infrastructure users don't control.
The editorial frames atproto's choice as the same compromise every 'decentralized' social protocol has made, contrasting it with ActivityPub (server-bound identity) and Nostr (raw pubkeys that are self-sovereign but unreadable and unrecoverable). Atproto deliberately picked a middle path — human-readable handles plus a DID layer — accepting centralized resolvers as the cost of usability and key recovery.
Åkesson highlights Bluesky PBC's stated intent to spin PLC out to a non-profit consortium, but stresses that today it remains a single company running a single service. His implicit position is that the credibility of atproto's decentralization claims hinges on whether and when that governance transition actually happens, not on the protocol's design alone.
Kevin Åkesson's post — "Who Actually Owns Your ATProto Identity? Hint: It's Probably Not You" — hit 124 on Hacker News by walking through the parts of the Bluesky pitch that don't survive a careful reading of the spec. The marketing line is that atproto is an open, federated, account-portable protocol: switch PDS hosts, keep your followers, your posts, your handle. The post's argument is narrower and sharper. Portability across PDSes is real; portability of the identity itself is not, because the two pieces of identity atproto exposes — your handle and your DID — are both controlled by infrastructure you don't run.
The handle (`alice.bsky.social`, `kevin.example.com`) is just a DNS name with a TXT record pointing at a DID. If you use a `bsky.social` subdomain, Bluesky PBC owns the zone and can revoke or repoint it. If you use your own domain, your registrar can. Either way, the resolver is DNS, and DNS is not yours in any cryptographic sense.
The DID is the part most people don't look at. Atproto supports two DID methods: `did:web` (resolved via HTTPS on a domain you control) and `did:plc` (resolved via plc.directory, a centralized log operated by Bluesky PBC). Roughly 99% of accounts use `did:plc`. The PLC directory holds your rotation keys, your signing key references, and the audit log of every change. Bluesky PBC has stated that PLC will eventually be spun out to a non-profit consortium, but today it is a single company running a single service that can, in principle, rewrite your identity history.
This isn't a gotcha — it's the same compromise every "decentralized" social protocol has made, and atproto made it deliberately. ActivityPub punts identity to whichever Mastodon server you signed up on; lose the server, lose the account. Nostr uses raw secp256k1 pubkeys, which are genuinely self-sovereign but unreadable, unrecoverable, and unrotatable. Atproto picked a third path: human-readable handles plus a DID layer that can rotate keys and recover from loss, paid for with a trusted directory in the middle. The author's complaint is that the marketing doesn't say "trusted directory in the middle" out loud.
The HN thread split predictably. One camp argues this is a fair, pragmatic tradeoff — Nostr-style key sovereignty is a UX disaster, and a non-profit PLC consortium is a reasonable destination. Another camp points out that "we'll federate PLC eventually" has been the answer for two years, and that the spec for a federated PLC (multi-operator, BFT-style consensus over the log) still doesn't exist in a form anyone can implement. A third camp — smaller but technically the most interesting — notes that `did:web` already works today, costs you a domain and a static file at `/.well-known/did.json`, and gets you actual portability. Almost nobody uses it because the Bluesky app onboarding doesn't surface it.
There's also a quieter point in the comments about key rotation. On `did:plc`, your rotation keys are listed in the PLC log; rotating them requires submitting a signed operation to plc.directory, which Bluesky's service can accept or reject. If you lose your rotation keys and you're on did:plc, Bluesky PBC support can — and does — help you recover, which is exactly the property that proves they have control. On `did:web`, recovery means restoring `/.well-known/did.json` from backup. On Nostr, recovery means "you don't." Pick your poison.
The deeper issue is that atproto's account migration story — the demo where alice.bsky.social moves from Bluesky's PDS to a self-hosted one and keeps her followers — relies on the DID staying stable across the move. That stability comes from PLC. Remove PLC, and migration breaks for 99% of the network. The protocol is portable; the population is not.
If you're building on atproto — a client, a feed generator, a PDS, a labeler — the practical advice is unchanged but worth stating out loud. Treat `did:plc` as the default and `did:web` as the escape hatch you offer power users. Document which one your service requires. If you're storing user references, store the DID, not the handle: handles change, DIDs (theoretically) don't, and the whole point of the DID layer is to give you a stable pointer.
If you're a user who actually cares about identity portability, the steps are: register a domain you control, point a `did:web` document at it, generate your signing and rotation keys offline (a YubiKey or an air-gapped machine, not your laptop), and host the document on infrastructure you trust. Bluesky's tooling for this is thin but functional. You will be in a population of roughly 1% of atproto users, which is itself a signal — if self-sovereign identity were easy, more people would have it.
If you're an enterprise evaluating atproto as a federation substrate (a few are — internal social, customer communities, brand-controlled feeds), the PLC dependency is the line item to put in the risk register. It's not disqualifying, but "our user identities are written to a log operated by a Series A startup" is the kind of thing a security review will flag, correctly. The mitigation is `did:web` on a domain you own, with the rotation keys in your HSM.
The Bluesky team has been transparent that PLC needs to federate; the question is whether the consortium model ships before the centralization becomes load-bearing for the rest of the ecosystem. Two years in, the network has the momentum but not the institutional structure — there is no PLC foundation, no published BFT spec, no second operator running a mirror. Until that changes, atproto is a federated protocol with a centralized identity root, and pretending otherwise is the kind of thing that gets posted to Hacker News and pulls 124 points in a morning. Build accordingly, and if identity sovereignty is actually in your threat model, use did:web today instead of waiting for the consortium that may or may not arrive.
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