https://minds.com/ proposed NIP-26 because they didn't want to have full control over users' keys, but I am still confused about what exactly they wanted to do with that.
I was thinking about a process through which a hosted key slowly signals that it is in fact an "adopted child" of some parent key created elsewhere, then readers can slowly migrate to following that other key. This could be done with NIP-26 but that is not necessary even, there could be just a pointer and a hint. Is there a problem with this?
Would canaries work better than delegation?
I could announce a set of pubkeys which are to be looked at after a suspected „hack“. The canary pubkey could then do whatever, eg. redirect to another pubkey.
Clients could also monitor canaries for activities. Canaries could be way more flexible than delegated signing.
Please explain that concept better. What is a canary in the first place?
Also, have you seen https://nips.be/41?
Actually I did not see your proposal for key revocation. Thank you for the hint! Interesting approach. 👌
Let me see whether I find time tonight to propose something on GitHub.
I see, the idea is already out there, see note15g67u2cj406dn7r7ya3dm2rk8mnj4akj99ay260ek60ctr66k5ws5v5km6 for example.
So I prefer to link conversations here instead of GitHub. Let me sketch the idea:
After key generation you would publish one or more spare pubkeys with a special event id. They are the canaries. Clients can look them up to see whether they published other special events (or type 1 even). You could leave it up to further NIPs or clients what do do if a canary tweets.
The advantages of this are that it‘s fully compatible with currently existing pubkeys and that clients don‘t have to implement them for most things to work.
One problem I see is time. You would either need to be referenced by something newer but old enough or you would consider a canary only valid for checking after a fixed amount of time.
With old enough, I mean provably old enough.
