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