After writing my previous article about Bluesky's centralization risks, I got into the weeds on how the PDS (Personal Data Server) works. The more I looked at it, the worse it got. I was originally worried about Bluesky going rogue and deleting accounts or locking people in. It's actually the least scary thing your PDS operator can do to you.
They can be you
Your PDS holds your signing key. It signs every commit to your repository. Every post, every like, every follow, everything. The PDS also holds your rotation key, which controls your identity. It can change your signing key, change which PDS your account points to, basically take full ownership of your DID (your permanent decentralized identifier on ATProto).
Your PDS operator can post as you, like things as you, follow people as you, and it would be cryptographically indistinguishable from your real activity. The signatures are valid. The commits are properly formed. As far as the protocol is concerned, you did it.
With a traditional platform, the blast radius is scoped. If Twitter's database admins wanted to post as you, they could mess with your tweets. Bad, but contained.
On ATProto, your PDS doesn't just store your Bluesky posts. It stores everything. Your git activity on Tangled (a git collaboration platform built on ATProto), your social interactions on Grain, your writing on Leaflet, whatever comes next. Every new ATProto app writes to the same repo, signed by the same key, controlled by the same operator. So whoever runs your PDS can impersonate you across every application in the ecosystem.
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 thing. Across every ATProto app, not just one.
And it works the other way too. If you do something your PDS operator doesn't like, they can kill your identity. Not just your Bluesky account. Your ability to post, commit, publish, or interact across every ATProto app. On a traditional platform, getting banned from Twitter doesn't touch your GitHub. Here, one operator's decision can lock you out of the entire ecosystem. Your data might still exist in backups or on the firehose, but your identity is dead. You can't use it anymore.
It's not the data, it's the keys
The repo data itself isn't the issue. It's all public anyway, broadcast on the firehose (ATProto's real-time data stream) for anyone to crawl. Compromise a relay (the service that aggregates and rebroadcasts network data) 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.
An attacker, a state actor with a warrant, or a rogue employee doesn't just get read access. They get the signing keys to create new activity and the rotation keys to lock users out of their own identities. One signing key, every app. And every new ATProto app that launches adds another surface where a compromised key can do damage.
The system trades convenience for sovereignty. I get why. Key management is hard, and most users will never want to deal with it. But the consequence is that the entire system's security rests on trusting your PDS operator, and that makes it brittle. One compromised or malicious operator and every account on that PDS is exposed, across every app.
What should change
You can enroll a self-controlled rotation key with higher priority than your PDS's key. If you do this, your PDS can still sign things as you, but at least it can't lock you out of your own identity. You could rotate the signing key, point your DID at a new PDS, and move on. But it's not the default, so the vast majority of users will never do it.
This should change. Backup rotation key enrollment should be part of the default account creation flow. It should be built into the clients, not just the API. Users should have a clear way to audit what their PDS has signed on their behalf. And the ATProto docs should spell out what it actually means that your PDS holds your keys, because right now most users have no idea.
ATProto asks you to put more of your digital life under a single identity, hand the keys to that identity to someone else, and trust that they'll be good. The protocol's decentralization promises are real at the architectural level. But at the key management level, it's a level of trust that would make even a centralized platform blush.