Key Management, ATProto, and Decentralization

There’s a big problem with the Fediverse. See, if you made an account on CybreSpace, you would have been SOL when it shut down. Well, sort of; you could migrate your follows and followers, blocks, settings, etc, but your posts that lived on CybreSpace would be gone.

Except, they’re not.

I was on CybreSpace, and I can easily find posts of mine still cached on other servers. That data still exists, and in theory, it could be imported into another instance. Setting aside slurp, a tool which does actually let you move posts to another instance, it’s theoretically possible to just get all the posts other servers have seen and put them into your new instance’s database, right?

The only problem is that you then have to trust those servers. A targeted attack could result in flooding your ne w instance with spam attributed to your name, or putting illegal material in its media store, or subtle but devasta ting edits to the meaning of charged political posts. (Imagine replacing every “do” with “do not” on a politically outspoken user’s posts.)

There is a known solution to this - known since long before Mastodon was a glimmer in Gargron’s eye. You associate a cryptographic key with each user, and sign their posts. The user delegates that authority to their server, while they’re there, but they always retain their identity’s main key, which can be used to sign messages like “I am moving to another server” (in a machine-readable way) in case that server goes down or becomes hostile. This means that each post, itself, verifies that it is authentic and correctly transcribed. Then, software doesn’t have to care where posts come from, just that they are signed by the correct key. This has been proposed before as a way to make user identity less vulnerable to instances shutting down - so why don’t we do that?

Because key management sucks, and you can’t ask users to do it. Think about it: you’re giving users, people whose only qualification is knowing how to type their email into your signup form, a cryptographic identity document. If they lose this magic gibberish, no more migrations. If they post it publicly, anyone can impersonate them. And users can’t really trust other services with their keys, because any service that promises to manage their keys becomes a single point of trust for that user.

So how does Bluesky solve this?

…

No, seriously, how does Bluesky solve this? As far as I can tell, the protocol docs simply assert that it is solved:

User data is stored in signed data repositories and authenticated by DIDs. […] DIDs provide a directory of cryptographic keys, similar in some ways to the TLS certificate system. Identities are expected to be secure, reliable, and independent of the user’s PDS.

Most DID documents publish two types of public keys: a signing key and rotation keys.

Signing key: Validates the user’s data repository. All DIDs include such a key.

Rotation keys: Asserts changes to the DID Document itself. The PLC DID method includes this, while the DID Web method does not.

The signing key is entrusted to the PDS so that it can manage the user’s data, but rotation keys can be controlled by the user, e.g. as a paper key. This makes it possible for the user to update their account to a new PDS without the original host’s help.

This is basically the exact scheme I laid out above, which the Fediverse considers too user-unfriendly to be feasible.

Current options for migrating between Bluesky PDSes are “manage your own keys and your own identity, via DNS” and “fully delegate to a centralized entity.” For example, Blacksky created the first easy-to-use full migration service, Tektite, which is awesome - but it only works for people who have delegated their key management to Bluesky-the-company. It doesn’t do any key management wizardry, just an API call. This is not a criticism of Tektite; it would be totally unreasonable to expect it to manage DNS records for people, which is exactly why this method of nomadic identity is not generally considered user-friendly.

Bluesky is all about the “credible exit”, and I’m excited to see growth towards a truly decentralized ATProto social system; in some ways, we’re already there technically, and getting closer socially all the time. But, I dread the day that a major news organization’s rotation key is stolen, or a government uses the threat of force to get someone’s account removed from the PLC registry. In my opinion, Bluesky’s approach to nomadic identity isn’t innovative; it’s reckless.

mtime Nov 18, 2025; 11ty.js; text CC-BY-SA 4.0; code AGPL 3.0;

view src

---kdl
title "Key Management, ATProto, and Decentralization"
tags "Software"
description "What stands between ATProto and real decentralization?"
---

There's a big problem with the Fediverse. See, if you made an account on [CybreSpace](http://web.archive.org/web/20200512040752/https://cybre.space/about), you would have been SOL when it shut down. Well, sort of; you could migrate your follows and followers, blocks, settings, etc, but your posts that lived on CybreSpace would be gone.
 
Except, they're not.
 
I was on CybreSpace, and I can easily find posts of mine still cached on other servers. That data still exists, and
 in theory, it could be imported into another instance. Setting aside [slurp](https://github.com/VyrCossont/slurp),
 a tool which does actually let you move posts to another instance, it's theoretically possible to just get all the
 posts other servers have seen and put them into your new instance's database, right?

The only problem is that you then have to *trust* those servers. A targeted attack could result in flooding your ne
w instance with spam attributed to your name, or putting illegal material in its media store, or subtle but devasta
ting edits to the meaning of charged political posts. (Imagine replacing every "do" with "do not" on a politically outspoken user's posts.)

There is a known solution to this - known since long before Mastodon was a glimmer in Gargron's eye. You associate a cryptographic key with each user, and sign their posts. The user delegates that authority to their server, while they're there, but they always retain their identity's main key, which can be used to sign messages like "I am moving to another server" (in a machine-readable way) in case that server goes down or becomes hostile. This means that each post, itself, verifies that it is authentic and correctly transcribed. Then, software doesn't have to care where posts come from, just that they are signed by the correct key. This has been proposed before as a way to make user identity less vulnerable to instances shutting down - so why don't we do that?

Because key management *sucks*, and you can't ask users to do it. Think about it: you're giving users, people whose only qualification is knowing how to type their email into your signup form, a *cryptographic identity document*. If they lose this magic gibberish, no more migrations. If they post it publicly, anyone can impersonate them. And users can't really trust other services with their keys, because any service that promises to manage their keys becomes a single point of trust for that user.

So how does Bluesky solve this?

...


No, seriously, how *does* Bluesky solve this? As far as I can tell, the [protocol docs](https://atproto.com/guides/overview#account-portability) simply assert that it is solved:

> User data is stored in signed data repositories and authenticated by DIDs. [...] DIDs provide a directory of cryptographic keys, similar in some ways to the TLS certificate system. Identities are expected to be secure, reliable, and independent of the user's PDS.
>
> Most DID documents publish two types of public keys: a signing key and rotation keys.
>
> - Signing key: Validates the user's data repository. All DIDs include such a key.
> - Rotation keys: Asserts changes to the DID Document itself. The PLC DID method includes this, while the DID Web method does not.
> 
> The signing key is entrusted to the PDS so that it can manage the user's data, but rotation keys can be controlled by the user, e.g. as a paper key. This makes it possible for the user to update their account to a new PDS without the original host's help.

This is basically the exact scheme I laid out above, which *the Fediverse* considers too user-unfriendly to be feasible. 

Current options for migrating between Bluesky PDSes are "manage your own keys and your own identity, via DNS" and "fully delegate to a centralized entity." For example, Blacksky created the first easy-to-use full migration service, [Tektite](https://tektite.cc/), which is awesome - but it only works for people who have delegated their key management to Bluesky-the-company. It doesn't do any key management wizardry, just an API call. This is not a criticism of Tektite; it would be totally unreasonable to expect it to manage DNS records for people, *which is exactly why this method of nomadic identity is not generally considered user-friendly.*

Bluesky is all about the "credible exit", and I'm excited to see growth towards a truly decentralized ATProto social system; in some ways, we're already there technically, and getting closer socially all the time. But, I dread the day that a major news organization's rotation key is stolen, or a government uses the threat of force to get someone's account removed from the PLC registry. In my opinion, Bluesky's approach to nomadic identity isn't innovative; it's reckless.