Yeah, it's coming NIP-26 I believe.
Discussion
NIP-26 will be huge, cheering Keith on.
Then we'd just need a proper tool to migrate all follows and followers from an old set of keys to a new set of keys and we can all start using key delegation moving forward.
NIP-26 is delegation, but that doesn’t help if your main identity PK is already “dirty” from being stuffed in a browser.
Need an identity migration NIP, if one doesn’t already exist.
I’ve been thinking of something like a pre-dated http 300 redirect:
* my current key X would say that new key Y will be my new key starting at timestamp (which can be in the future).
* Y’s metadata confirms: I came from X
Y points back to X to make it easy to follow the identity migration chain backwards. But that alone can’t be authoritative because scammers could just claim to be your next key.
X has to point to Y to prevent the above identity migration hijacking.
If you change your mind and want to migrate back to key X, you can just clear the migration fields on key X and maybe for convenience set some kind of `reversion` flag on key Y to redirect back to X.
And why a future timestamp? Allows you to have a migration plan in place in case you ever lose key X. You don’t necessarily plan on using key Y but it’s there to preserve your identity if you need it. Your client could regularly push the migration date for key Y off another 30 days or whatever.