And as it stands rn, all that wealth would be tied to your nsec.
Nostr really needs to sort out the whole, everything you do and log-into is tied to a single shared identity (nsec).
We need the ability to create unlimited child keys based on parent keys.
This way, like a password manager, you aren't worried about one breech compromising everything and the annoyance of creating a new disassociated key pair before logging into the myriad of micro apps in the #Nostr ecosystem.
+1
+1 for me too.
I like that. Are there any logical arguments against it?
Absolutely. If I had the time I'd write it myself. A practiced nostr coder could do it in a day or two, would take me a few weeks or more due to research.
It needs to do 3 things:
1. Handle bip-32 derivations using nsec/npub formatting.
2. Handle signing via derivation.
3. Be modular so that any client can implement it.
Most of this code exists, it just requires adaptation. Primary reason I haven't done it over the last year is that without also making a client I couldn't test it. I also didn't know about NAK.
I use subkeys for this. It's quite a hard technical problem to solve. But the harder part is getting people to agree on something.
💯 problem is, this "something," means everything.
#subkeys ftw, I've been playing with them for a while, and they are great
