This sounds like it would be a nice feature to have, but only if virtually every client supports it.
For instance, say I set this up for myself and start posting from a derived key. Any client that does not support this would treat me as a completely new user, right? So no one on such a client would be able to see my pfp or any other info that I had created with my root key on my derived key's profile page. And anyone who was following my root key's npub would not see any of my new key's posts in their feed unless they actively added my derived key's pubkey to their follow list, and even then, they would need to somehow remember that npub with no profile info is actually me, unless I republish a new kind 0 with the derived key.
Any client or relay that uses web-of-trust but does not implement this would also exclude any derived key's pubkey from the WoT by default, since that new key won't have any follows or anyone following it.
So, while it is not required for anyone to implement it, and Nostr will go on working as it had before for anyone who doesn't implement it, in practice it is next to useless unless virtually all clients implement it, since derived keys will be treated as completely new users by any client that doesn't, effectively wiping out their entire post history and social graph. Sure, all the previous notes will still exist, but that doesn't matter if the clients aren't associating them with the derived key.
I guess that means a user probably wouldn't want to set this up until there is pretty widespread client adoption.
And what is the idea for how users will safely store their root key?
My assumption is that ideally we would all want to switch to a new root key, rather than use our existing nsec, since it has been used hot. So that would require us to start fresh regardless.
Then what? We would need to get a device like a ColdCard to safely store our root key offline and generate our first derived key using that?
I can see the Nostr guides now... "Welcome to Nostr! To get started, first go buy this $150 piece of hardware. You can also build your own for a fraction of that price. You can also get started completely free by simply generating a key pair, but this is not recommended since there is a greater danger of your key being compromised, and if you wanted to upgrade to a more secure means of using Nostr later, you would need to start a whole new identity anyway."
Don't get me wrong, I think having a way to rotate keys and keep your root key offline is great, and I would probably do it myself if this method gained widespread client support. I am a bit more technical and familiar with cold storage already, though. I can't imagine this being the main way new users keep their keys safe, though.
Maybe I am misunderstanding how this works, though, and all the above concerns are moot.
You’re correct about one thing and misunderstanding another.
Correct:
If a user rotates before a client supports lineage, that client won’t associate the new epoch key with the root identity. Followers there would see it as a separate npub. That’s expected.
The part you’re misunderstanding:
Cold root identity is optional and backwards compatible. No one rotates until the clients they care about implement lineage. Nothing forces a migration. Nothing breaks for anyone who doesn’t use the feature yet.
This is the same adoption pattern as every optional NIP feature. If a client doesn’t support zaps, zaps are invisible. If a client doesn’t support DMs, DMs don’t work. Same here. Rotation is an additive capability.
The value doesn’t depend on universal adoption. Just like multisig, hardware wallets, Tor-only nodes, LNURL-auth, and NIP-46.
Even if only power users or security focused clients adopt it, it still solves real problems:
- key hygiene
- blast-radius reduction
- eliminating the hot key identity model
Practical rollout is simple:
1. Users keep using their current hot nsec.
2. Clients begin adding support for the lineage tag.
3. Once a client supports it, users can optionally switch to an epoch key.
4. The root npub remains the identity anchor.
The client maps the root to whichever epoch key is active.
This is exactly how PGP subkeys, Monero subkeys, and minisign key hierarchies work. The identity anchor never changes. Only the operational key rotates.
Additionally, You don’t need a new root key or any hardware. Your existing nsec becomes the root.
Even if it was used hot, it’s fine because the moment you generate the first epoch key, the root goes offline permanently.
No one needs to buy anything or start over unless they want to. Rotation simply gives users a safer operational model when they’re ready for it.
Except, I don't gave to just care about whether the client I prefer has implemented it. I also have to care about whether the clients those who follow me have implemented it. If they have not, then my posts on the derived key will not show up in their feed, since their client will treat my derived key as a completely separate identity that they are not following, right?
Correct. Rotation changes the key you post from, so followers on clients without lineage support won’t see those posts as coming from you. That’s expected.
This is why rotation is optional and timed to ecosystem readiness. You don’t rotate when a single client implements it. You rotate when the clients used by your audience support lineage. It’s the same adoption pattern as every new NIP feature: creators only switch once their readers can see the result.
This isn’t a flaw. It’s how optional, backwards compatible features roll out.
Nothing forces early adoption, and nothing breaks for existing followers as long as you wait for their clients to add support. Rotation just becomes a better operational model once the ecosystem is ready.
"This isn’t a flaw. It’s how optional, backwards compatible features roll out."
That's fair.
And maybe this does remain a feature only used by advanced users. Though, I would argue that it is less likely to see widespread client adoption if it is expected to only be for advanced users, and widespread client adoption is the only way this becomes useful, in my opinion.
Without it, users have to sacrifice a large chunk of their current audience in order to take advantage of the security benefits provided. Therefore, I could only see it being useful for new users who do not yet have an audience they would be sacrificing, or existing users who have had their nsec recently compromised, so they need to start over anyway, in which case their previous nsec would NOT be their root key.
If wide client adoption happens, then I could see it being useful for more existing users. Not until then, though, and I don't see something that is currently not helpful to hardly anyone gaining support from client devs. But then, I am not a dev. I think
@ hodlbod already chimed in on this, and had a similar criticism to mine, though more technically informed than me, by far.
Maybe some of the others, like
@jb55 ,
@Vitor Pamplona ,
@Fabian ,
@miljan ,
@hzrd149 ,
@Cody and others I am neglecting can chime in about likelihood of implementation by major clients, let alone widespread adoption by most clients, including the vast array of "other stuff" clients.
As I see it, this would have a huge impact on Nostr interoperability for any user who moves to using a derived key, since some clients would act as expected and others would treat them as a separate user until the vast majority of clients were on-board.
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.
"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.
To clarify, you aren’t abandoning your audience because this isn’t a second identity. The root npub is still the identity everyone follows. Rotation just changes the operational key underneath that root and only clients that support lineage switch to using it. Clients that don’t support it simply keep using the existing key.
Correct, a client ignoring the lineage event won’t associate the new key with the root. But the assumption that rotation is only useful when “most clients” support it isn’t accurate.
Rotation is optional, contextual, and tied to the clients your audience uses, not the entire network. You rotate when your actual follower base is on clients that support lineage. If they aren’t, you don’t. Or you never rotate at all if you choose.
This isn’t meant to be a universal switch. It’s a safer operational mode for the users and clients who opt in and it doesn’t break anything for anyone else.
Is the critique about implementation speed or something about the model itself?
I don't think that I have any criticism about the model itself. It's mainly that I don't see anyone really adopting it until most clients support it, but that most clients probably won't support it unless a large base of their users want to adopt it.
Some client devs might be up for implementing it because they philosophically agree with what it is designed to accomplish, and they think it is a solid way of going about it, regardless of whether their users are enthusiastic about it. That's why I wanted to hear from some of those devs, particularly since they have been working on a related solution to key rotation.
"To clarify, you aren't abandoning your audience, because this isn't a second identity. The root npub is still the identity everyone follows."
Except, it IS a second identity for anyone on a client that doesn't support lineage. Not abandoning your audience might be technically correct, since your main npub is still your main npub, but it is effectively true if your followers never see your notes, because their client is treating your derived key as a separate identity.
"Rotation is optional, contextual, and tied to the clients your audience uses, not the entire network."
Right, but I have no idea what clients my followers are using, and I have a relatively small amount of followers. I have no idea whether adopting lineage after say Amethyst, Damus, Coracle, Primal, and Nostur have implemented it will cover 90% of my followers or not. So how can I gauge when it would be "safe" to adopt it? If I don't know what clients my followers use, then I have to assume that my posts will no longer be visible to some subset of my followers, of which size I have no realistic means of measuring, unless I wait until all but the most obscure and abandoned clients have adopted it. So, effectively the entire network.
Maybe there are some users whose following is concentrated on a particular Nostr client, or small group of Nostr clients, but I would guess that most of us have followers using a wide variety of clients. Moreover, power-users probably have a large number of clients they use for various different things, and they would want to be able to log into all of them with their derived key before they switched, otherwise they would have to continue logging into some clients using their root key, and others using their derived key, and deal with some of their posts not showing up on clients that haven't adopted lineage. It would also defeat much of the purpose of lineage if they have to keep their root key hot so they can continue using clients that haven't yet adopted it.
If you’re a client dev, this gives you everything you need to support safe identity rotation today.
