> 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.
Login to reply
Replies (1)
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.