Nostr Web Client

"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 nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgsm3u0w6 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 nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3g4h5cp7 , nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqelpt5w , nostr:nprofile1qqsfhc97pejd8z3f488vnfwgaawcw0ptlffk9f94trd9la5mc09ms8s0y9649 , nostr:nprofile1qqsdv8emcke7k3qqaldwv956tstu40ejg663gdsaayuuujs6pknw7js20dc33 , nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fg729x4s , nostr:nprofile1qqsgzfdez8ksa9xmuvqg5zly3nl9e5xqkpvj8nllj9aw06ra4pqq3qcq9n0c5 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.

GHOST 3w ago 💬 1

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.

Reply to this note

Please Login to reply.

Discussion

Dikaios1517 3w ago 💬 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.

GHOST 3w ago 💬 1

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?

Dikaios1517 3w ago

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.