what's needed for proper key rotation? who is working on this?
Discussion
👀
If I had to do it myself from my ignorant savant point of view: I'd want a 3-2-1 sort of thing on my profile. (3 backups, 2 mediums and 1 remote location.)
To validate my key today in a sovereign way, I have nip-05. Gimme 2 more ways, one in a different medium and one in a remote location.
Which.. I could have: a secondary nip-05 different locations, check. The one outside the internet is harder to parse automagically. Unless of course I could gather my homies around a 40, a blunt and have them unfollow my old key and follow my new one. Different medium, check.
Likely all of the above has been tested and disproved, but who knows?
IMO, web-of-trust key signing attestations and revocation as similar to PGP.
this, yes
cc nostr:nprofile1qqsw2feday2t6vqh2hzrnwywd9v6g0yayejgx8cf83g7n3ue594pqtcpz9mhxue69uhkummnw3ezuamfdejj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshsd8m8kr i think graperank can help here
Had a discussion on this topic recently
Yep! This is exactly how I imagined it would work.
"Oh Vinney's mom says this is Vinney's new npub? welp, that settles it [everything updates accordingly]"
...Also pretty nuts that graperank-flavored WoT can solve nostr's "big scary nsec problem".
Although I'm kind of an extremist here - I don't think there is much subjective WoT can't solve. Trust is humanity's superpower; welding it onto global-scale networks and lightspeed information transfer is..... unimaginable.
i proposed a scheme for separating identity from authorization in a manner similar to web sessions. this lets you better protect your actual identity key, avoids guessing whether a rotation was valid, can be verified without external requests, and in the event of loss is basically the same as bulk nip-09 deletions
Thats quite interesting and might play nicely with my prototype of ZK and bip-85 hierarchical nostr keys
https://github.com/wujifoo/nostr-bip-85-prototype
The zk can assert ownership/relationship of another key, doesn't help if the root is compromised though. So ideally you would never use the root for anything other than generating other keys. (Which can also do the same)
I agree the inability to do key rotation in Nostr is a major concern. It’s one of several things that make me sometimes think of making a derivative protocol that fixes some of the problems that have cropped up with Nostr. So far I’ve resisted the temptation.
We were musing on something similar but it needs widespread use of NIP-03 to be effective and lots of client coordination:
nostr:naddr1qqgrgdpexuenxvenv4jxxvf5xf3rqq3qnkfqwlz7xkhhdaa3ekz88qqqk7a0ks7jpv9zdsv0u206swxjw9rqxpqqqp65wrpemue
A single key per person and for life is too core to how the protocol works. Everything is built on top of that. It's the core of the core of the core. Rotate-able subkeys are a non-starter.
All you've got is a bunker-esque solution or a protocol fork.
https://frostr.org keep an eye on us, we are almost done with mobile, then V2, then problem solved