Rotation doesn’t require abandoning an audience because it doesn’t change the identity people follow. The root npub remains the stable anchor and clients simply map that identity to an epoch key once they support lineage. A derived key is just an operational key under the same identity. Rotation only happens after the ecosystem you care about supports it, so existing followers aren’t affected. Adoption follows the same pattern as NIP-05, DMs, zap receipts, and badges. Features spread gradually, early adopters benefit first, and broader support comes as value is demonstrated. Most users can use their current nsec as the root. A root key doesn’t need to be pristine, it simply goes cold after the first epoch key is generated. PGP and minisign have relied on this exact model for years. Interoperability stays intact because rotation only occurs once the clients used by your audience implement lineage. Until then nothing changes. And if someone prefers not to rotate at all, the model stays entirely optional. The goal is to provide a backward compatible alternative to the hot key identity model without forcing anything on any user or client.

Replies (1)

"Rotation doesn’t require abandoning an audience because it doesn’t change the identity people follow." Again, that is true, so long as the client the followers are using has adopted lineage. If it has not, then they will only be seeing the old posts that were signed with the root key, and they will only see the notes from the new derived key if they actively follow the derived key's npub, unless they happen to stumble upon those notes naturally via others they follow who have shared them, or by browsing relay global feeds. Even in the latter case, though, unless their client supports lineage, they would not know that these notes were posted by the same person they already follow, because their client would not be associating them with that root pubkey, it would just appear to be an npub with no profile metadata who posted the note. Is that correct? If so, then adopting this derivation scheme effectively abandons all followers who aren't using a client that has adopted it, making it next to useless unless and until virtually all clients have adopted it, unless the user is ok with the tradeoff of a large number of their followers no longer seeing their posts. This makes it very different from the other features you mentioned that have gained gradual adoption in the past. NIP-05, DMs, zap receipts, and badges all had benefit immediately, even if only one client adopted them, and so users were happy to try them out, and then pester the devs of their favorite clients to implement them, when they saw the benefit for themselves. Lineage, on the other hand, doesn't seem to be beneficial to most users unless and until the majority of clients support it. Until then, it is a detriment to them to start posting from a derived key when most of their followers are using clients that don't support lineage, since those followers would not see their notes. If they want to use it without these drawbacks, they will have to wait until "after the ecosystem you care about supports it, so existing followers aren’t affected." The ecosystem we are talking about here is the entirety of Nostr clients, or at least the most popular ones.