> “Alice is now using a new key.”
>
> Her followers don’t need to refollow and Alice doesn’t have to burn her whole account. Old posts stay signed by A1, new posts come from A2 Identity continuity is preserved.
So A1 has published a kind 0, which clients have fetched. A2 proves it is descended from A, indicating the A1 -> A2 migration. A2 therefore inherits the name "Alice", which means linking is happening on the client side, correct? Who is the end user following in this scenario, A or A1?
Clients follow the current key for an identity, not the historical ones. A1 was Alice’s active key and followers followed A1. When a valid lineage event shows A -> A2, the client simply updates the active pubkey for “Alice” to A2 going forward.
No different from how clients already update profile metadata, relays, mutes, pins, etc.
Users are following the identity, so the client treats A2 as the live key and uses it for new posts, profile info, and interactions. A1 remains only as the signer of old events. That’s the entire model.
> client treats A2 as the live key and uses it for new posts, profile info, and interactions
So the next time Bob mentions Alice, they use A2 instead of A1? In order to do that, Bob has to 1. fetch A2's association with A, and 2. maintain the mapping somehow (most likely by updating the follow list).
One problem that comes to mind: how does anyone know that A2 comes after A1? If A1 is compromised, it can always update the timestamp on its proof of ancestry to be more recent than the real user's.
Yes, when Bob interacts with Alice after a rotation, he uses A2 because that is now Alice’s active key.
Clients already maintain follow lists, so updating the entry from A1 -> A2 is just a metadata update on the client side, similar to when a user changes their relay list or update profile fields.
As for ordering: a compromised epoch key cannot create a valid “I come after you” lineage event, because the lineage link is signed by the root, not by the epoch key.
A1 can’t produce sig_root(A2) or any future link unless it has the offline root seed, so it can’t forge an ordering or jump ahead.
Timestamps don’t matter. The cryptographic signature enforces the direction.
That’s all clients need to know.
Got it, makes sense. I feel like we could have gotten there more quickly, saying things like "nothing is fetched from siblings" but also having to migrate from A1 -> A2 by fetching something from A1 is contradictory. But I understand now.
Like I said at the top, I think cold storage is not the right UX for most users, but the migration scheme is certainly very simple because it doesn't compromise the authority of the root key.
