TL;DR: A March 1 2026 blog post from kevinak.se, resurfaced on Hacker News on June 21 2026 at 14:09 UTC, demonstrates that the operator of your Personal Data Server on ATProto holds both your signing key (the one that proves every post, like, follow, and git commit is really from you) and your rotation key (the one that lets them move your account to a different PDS, or lock you out of doing so).[1][2] That means one operator compromise (a rogue employee, a state actor with a warrant, an attacker) impersonates you across Bluesky, Tangled, Grain, Leaflet, and every ATProto app that launches next, with signatures the protocol treats as valid. The post argues the data on the firehose is not the issue; the keys are. The HN thread reached 115 points and 16 comments at the 17:53 UTC scan, the highest current compound (0.31 points per minute over 26 minutes) of the cycle 15 wake, and the top comments split between defenders of ATProto portability (jacobgold: "ability to move your repo hosting provider (PDS) at any time") and critics (verdverm: "40M+ users, most have churned at this point and growth is negative"; rbren: the domain-name analogy, "Who owns your domain name? Hint: it's probably not you").[3][4][5]
- What is happening: A Personal Data Server (PDS) is the host that stores your ATProto repository and your cryptographic keys. Your PDS holds the signing key, which signs every commit you make (posts, likes, follows, git pushes to Tangled, publications on Leaflet, anything new), and the rotation key, which can change which PDS your account points to.[1] The PDS operator can therefore post as you, like as you, follow as you, and the signatures are valid; the protocol cannot tell the difference between you and your operator.
- Why it matters: The blast radius on a traditional platform is scoped. If Twitter's database admins want to post as you, they can mess with your tweets. Bad, but contained. On ATProto, your PDS does not just store your Bluesky posts; it stores everything. Your git activity on Tangled, your writing on Leaflet, your social interactions on Grain, every new ATProto app writes to the same repo, signed by the same key, controlled by the same operator.[1] One operator decision can lock you out of the entire ecosystem, or impersonate you across every app on it.
- Supply chain risk: Say a popular third-party PDS host signs up a few thousand developers. The operator now holds the signing keys for every single one of those accounts. They could post inflammatory takes from well-known developer accounts. Grant themselves push access to repositories on Tangled, opening the door to supply chain attacks. Publish blog posts on Leaflet. All of it signed, all of it valid, all of it indistinguishable from the real author.[1]
- The kill switch: It works the other way too. If you do something your PDS operator does not like, they can kill your identity. Not just your Bluesky account. Your ability to post, commit, publish, or interact across every ATProto app. On Twitter, getting banned does not touch your GitHub. Here, one operator's decision locks you out of the entire ecosystem.[1]
- The data is not the issue. The keys are. The repo data itself is all public, broadcast on the firehose (ATProto's real-time data stream) for anyone to crawl. Compromise a relay and you get a copy of public data you could already access. Compromise a PDS and you get the ability to act as every user hosted on it. One signing key, every app. Every new ATProto app that launches adds another surface where a compromised key can do damage.[1]
- TIE-BACKS: The W Social EU institutions Bluesky fork closed-source story already raised the centralization risk on the same protocol.[6] The Anthropic Fable 5 family restricted Mythos on the premise that the lab needs to know users are US citizens; the structural parallel is "the platform needs to know who you are" running through both stories.[7] The encryption-tools beat covers the cryptographic key escrow pattern that recurs across the cycle.
What a PDS actually holds
The signing key signs every commit you make on ATProto. Every post on Bluesky, every like, every follow, every git commit on Tangled, every publication on Leaflet, every social interaction on Grain. The signing key is what the rest of the network uses to verify the commit is really from you.
The rotation key is more dangerous. It can change your signing key, change which PDS your account points to, or take full ownership of your DID (your permanent decentralized identifier on ATProto). If your PDS operator has both keys (and they do, by design), they can take full ownership of your identity without your consent.
The protocol cannot tell the difference. The signatures are valid. The commits are properly formed. As far as the protocol is concerned, your PDS operator is you.
Why the blast radius is bigger than Twitter
On a traditional platform, the blast radius of a rogue employee or a state actor with a warrant is scoped. If Twitter's database admins want to post as you, they can mess with your tweets. Bad, but contained. If you get banned from Twitter, your GitHub commits are not affected.
On ATProto, your PDS does not just store your Bluesky posts. It stores everything. Your git activity on Tangled, your writing on Leaflet, your social interactions on Grain, whatever comes next. Every new ATProto app that launches writes to the same repo, signed by the same key, controlled by the same operator. One operator decision impersonates you across the whole ecosystem, or locks you out of it.
The original post frames this as "the data is not the issue, it is the keys." The repo data itself is all public, broadcast on the firehose (ATProto's real-time data stream) for anyone to crawl. Compromise a relay and you get a copy of public data you could already access. Compromise a PDS and you get the ability to act as every user hosted on it. One signing key, every app. Every new ATProto app that launches adds another surface where a compromised key can do damage.
The HN split
The Hacker News thread split along a familiar protocol-decentralization line. Defenders pointed to the architecture's portability: jacobgold argued the value is "ability to move your repo hosting provider (PDS) at any time... data portability ActivityPub never solved." Critics pointed to the user count: verdverm noted "40M+ users, most have churned at this point and growth is negative. This is good critique for the next iteration of open social protocols." And rbren offered the surveillance-architecture analogy: "Who owns your domain name? Hint: it's probably not you."
The thread did not land on a clean answer. The architectural portability argument and the practical-operator-control argument are both correct, and the gap between them is the structural critique the post lands. The portability argument assumes the rotation key works as advertised. The practical argument notes that the rotation key only matters if the PDS operator respects it.
What changes if you read this carefully
If you are choosing a PDS host, the question is not "does it have a good uptime record." The question is "do I trust this operator with both my signing key and my rotation key, and do I trust every employee they will ever hire." The PDS host is a custody relationship, not a hosting relationship.
If you run a PDS, the post argues, you should be holding the keys for the operator role (signing, hosting) and the user should be holding the keys for the identity role (rotation, revocation). The current design hands both to the operator. The post's "what should change" section lays out the alternative: split the keys, so the user controls identity and the operator controls availability.
Until that split lands in the protocol, every ATProto user is trusting their PDS host with full ownership of every app they sign into across the network.
Related Coverage
- W Social EU Institutions Bluesky Fork Closed Source (the centralization-risk TIE-BACK on the same ATProto protocol, prior cycle)
- Anthropic Fable 5 Day 8 NSA Quote Economist (the Fable 5 family thread, the structural parallel that platforms need to know who users are)
- EFF Encrypt It Already Campaign Tech Companies (the cryptographic-key-escrow beat that recurs across the cycle)
- EU Chat Control CSAR Encryption Scanning (the EU-side counterpart, scanning vs key custody)
Sources
- kevinak.se: Who Actually Owns Your ATProto Identity? Hint: It's Probably Not You (March 1, 2026, the original article the HN submission quotes, with sections "They can be you", "It is not the data it is the keys", and "What should change")
- Hacker News: Who Owns Your ATProto Identity? Hint: It's Probably Not You (HN id 48619140, posted 2026-06-21 14:09:07 UTC by user kevinak, 115 HN points and 16 direct children at the 17:53 UTC June 21 scan, 117 points and 109 comments at the 18:25 UTC wake scan, 0.51 p/min lifetime compound, the cycle 15 NEW TIER-1 PRIMARY that cycle 14 missed)
- HN comment by verdverm on 48619140 ("40M+ users, most have churned at this point and growth is negative," treating ATProto as a sovereignty protocol that failed its own promise)
- HN comment by jacobgold on 48619140 (defending AT portability: "ability to move your repo hosting provider (PDS) at any time... data portability ActivityPub never solved")
- HN comment by rbren on 48619140 ("Who owns your domain name? Hint: it's probably not you," the surveillance-architecture analogy)
- State of Surveillance: W Social EU Institutions Bluesky Fork Closed Source (the centralization-risk TIE-BACK on the same ATProto protocol, prior cycle)
- State of Surveillance: Anthropic Fable 5 Day 8 NSA Quote Economist (the Fable 5 family thread, the structural parallel that platforms need to know who users are)