Åkesson walks through the actual mechanics of DID resolution on ATProto and concludes that while the protocol describes decentralized identity, the dominant deployment routes every default signup through did:plc, which resolves through plc.directory — a single service run by Bluesky PBC. He extends this to the Relay and AppView, noting all three structural chokepoints are operated by the same company, making 'decentralized' a spec-level claim rather than an operational reality.
Åkesson points to did:web — which anchors identity in DNS and a .well-known/did.json file on a server the user controls — as the path for anyone wanting actual self-custody. He notes it exists in the spec and works today, but first-party tooling makes it inaccessible and several pieces of the ecosystem implicitly assume PLC, which he frames as a choice rather than a technical limitation.
The editorial frames ATProto's gap between spec and deployment as exemplary of a broader pattern: decentralization rhetoric routinely survives at the protocol layer while collapsing at the operational layer. It identifies three structural — not incidental — centralization points (PLC directory, Relay, AppView), all run by Bluesky PBC, with only the PDS being meaningfully user-operable.
A blog post by Kevin Åkesson titled *Who Actually Owns Your ATProto Identity? Hint: It's Probably Not You* climbed to 97 points on Hacker News, with a comment thread that read more like a postmortem than a debate. The piece walks through the actual mechanics of identity on AT Protocol — the network underneath Bluesky — and lands on an uncomfortable conclusion: the protocol describes a decentralized identity system, but the dominant deployment is functionally centralized on infrastructure operated by Bluesky PBC.
The technical core is the DID (Decentralized Identifier). ATProto supports two methods: `did:plc` and `did:web`. Roughly every Bluesky account created through the default signup flow gets a `did:plc` identifier, and the PLC directory that resolves those identifiers is a single service run by Bluesky. PLC stands for "Public Ledger of Credentials," but it is not a ledger in any blockchain sense — it's a signed-operation log hosted on plc.directory. Your handle (`@you.bsky.social` or a custom domain), your signing keys, and your rotation keys all resolve through that one endpoint.
The alternative, `did:web`, anchors identity in DNS and a `.well-known/did.json` file on a server you control. It exists in the spec, it works, and it is the path Åkesson points to for anyone who wants actual self-custody. The catch, as the post and the HN thread both note, is that almost no first-party tooling makes it easy, and several pieces of the ecosystem implicitly assume PLC.
Decentralization claims usually break at the operational layer, and ATProto is the cleanest current case study. There are three points in the protocol where centralization is structural rather than incidental: the PLC directory, the Relay (which firehoses all events on the network), and the AppView (which builds the feeds and threads you actually see). Bluesky PBC operates the production instance of all three. The Personal Data Server (PDS) is the only piece that meaningfully runs at the edges today, and even there the migration tooling for moving a PDS while keeping a `did:plc` requires cooperating with the PLC directory operator.
The comparison practitioners keep reaching for is ActivityPub, where Mastodon servers are independent and your identity is `@you@yourserver.social`. That model has its own pathologies — server death = identity death, no portability — but it doesn't pretend otherwise. ATProto's pitch is portability: take your data, take your handle, take your followers, move servers. That pitch holds only as long as the PLC directory chooses to honor your DID's rotation operations, which means "portability" in practice depends on the goodwill of a single nonprofit-adjacent company. If Bluesky PBC is acquired, runs out of money, gets a court order, or simply changes its mind about your account, the rotation key you hold is worth what plc.directory says it's worth.
The Hacker News thread surfaced the usual counter-arguments. One: Bluesky has published plans to federate the PLC directory or hand it to a consortium. Two: anyone can run a PLC mirror, and the operations log is cryptographically verifiable, so a fork is theoretically recoverable. Three: did:web is right there, use it. The first is a promise, not a system. The second requires every AppView and Relay to actually accept the mirror as authoritative — a coordination problem with no current solution. The third is real but vanishingly used: as of mid-2026, did:web accounts are a rounding error in the network's user base, and several popular clients have been observed mishandling them.
What makes this not just an ATProto problem is the broader pattern. Every "decentralized" social protocol that achieves mainstream usage seems to find a centralization sink — an API gateway, a default relay, a moderation service, a directory — that ends up being where the actual product lives. Email federates and yet Gmail and Outlook deliver most of the mail. Matrix federates and yet matrix.org carries most of the rooms. ATProto's distinction is that the centralization is in the identity layer itself, which is the layer hardest to migrate away from after the fact.
If you're building on ATProto — a client, a feed generator, a custom AppView, an indexing service — assume PLC is a dependency you do not control and plan for its degradation. Cache DID documents aggressively, treat plc.directory as a third-party API with a real SLA risk, and build your data model so that a user's PDS endpoint is the source of truth for content even if directory resolution lags or fails. A 90-second outage of the PLC directory today means new lookups break across the network; design for that to be a 6-hour or 6-day event at some point.
If you're a user who cares about identity sovereignty, the practical move today is to register a custom domain, point it at a `did:web` document you host, and run your own PDS — or accept the tradeoff and use did:plc with eyes open. The diagnostic question is the same one you'd ask of any SaaS dependency: if this vendor disappeared tomorrow, what could you actually take with you? With did:plc, the honest answer is your content and your private keys, but not your network identity. With did:web on a domain you own, the answer is everything that matters, at the cost of running infrastructure most people are not equipped to run.
For product teams considering ATProto as a substrate for non-Bluesky applications — and there is a growing crop of these — the identity question is not academic. If your app's value proposition depends on users being able to take their data with them, you are inheriting Bluesky PBC's roadmap for PLC federation as part of your product's roadmap. That's a vendor-lock-in surface that doesn't appear on any architecture diagram.
The path out of this is a credibly federated PLC, with multiple independent operators running mirrors that the network treats as equivalent authorities. Bluesky has signaled intent in this direction, but a year and a half after the public launch, the production directory remains a single operator, and no published timeline exists for changing that. Until the federation work ships and at least one independent operator runs a directory that AppViews and Relays accept on equal footing, the honest framing is the one Åkesson's post arrives at: ATProto is a well-designed decentralized protocol with a centralized identity dependency in the critical path, and calling it "yours" is a stretch the architecture doesn't quite support.
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