Nostr Web Client

> 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.

GHOST 1mo ago

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.

Reply to this note

Please Login to reply.

Discussion

hodlbod 1mo ago

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.