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?

Replies (1)

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.