Fair enough, but child keys and key rotation have been a reoccurring topic in Nostr since I started working on it three years ago.
It's complicated, but I think there are two parts that I commonly hear.
Key derivation / child keys and then key rotation. The first will never work in Nostr, IMO. The second one is a very hard problem.
The problem with key derivation and child keys is that it pushes the complexity of the implementation to the edges. So for every user that uses derived keys, all of their followers must look up, check, and verify the keys. Which is a difficult task on its own without considering that users could intentionally or unintentionally use multiple child keys at the same time and increasing the complexity even further.
And finally the problem with key rotation is always keeping key material safe. In thoery an offline master key protects against leaked child keys. But it requires the user to protect the master key, something that apparently they can't do with the child key.
I don't pretend to have all the answers with key rotation, and I admit it's a problem we have to still solve. But IMO it's not as simple as using key derivation
It’s complex. Agree. But, I am not happy with the voodoo on key rotation I see in the fiat world. Yes, it is complex, and the default should be just a npub. But if there can be an indication that the event originated from a master npub - that could be a good thing. Right now, npubs are perfectly fine for social media and fun stuff, but no way would I pin any business dealings on a using a nsec freely shared in the client-wild. This likely would be for business use cases.
Thread collapsed
