Why give clients 90 days+? This NIP cannot be required, it must be optional. If you think it is required then we shouldn't do it.
RE: NIP-41 discussion at #nostrasia
https://www.youtube.com/live/Nz15SyiwQFk?t=16400
My thoughts on the different ideas discussed is: YES
1. Yes, we should consider implementing what nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft suggests, but we should give clients time (90 days+) from merging the NIP to implement it before clients offer this tool to their users. (reviewers: nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn, nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z, nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s, nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc)
2. Yes, in a separate NIP we should implement nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6's original idea of a masterkey. It is so good and powerful, I believe it's worth the pain. It would allow holding the masterkey in cold storage. Done right it would allow creating Schnorr multi-sig masterkeys. I would call this a 2.0 nostr account. We should merge the NIP and client's should not start using these until 180 days later (or longer) to give all clients time to implement them before they are used.
Once these 2.0 accounts go live after the implementation grace period, clients should offer their users the option of migrating to a 2.0 account using Pablo's NIP-41 (or another) approach.
3. Yes, we should have social recovery support. It should be a separate NIP and it can be additional to all other migration concepts. Once a key migration is detected, a client should ask the user whether they want to trust this migration. In case the user has out-of-band confirmation of the migration, they can accept it and it will be marked in their kind 3 by listing both old and new keys for the account. Other clients can now pick up on this information and display to their users how many of their own network trust the new key. The user can then decide themselves when they want to start trusting the new key as well. This scheme does not require any history of the old key, as users would simply be trusting their own network. I believe this is much closer to how trust and relationships work in real life as well: you trust your own friends, not who another says are their friends. This could be part of a general Web-Of-Trust NIP that harmonizes how clients calculate and present WoT scores.
The most important aspect in all of this is to clearly mark everything for the user. An account in migration (by whichever scheme) should be marked as such until or unless the user decides to mark his trust in the migration as final.
We should ask the designers to come up with a nostr design best practice UX that clients should strive to implement. nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk
Discussion
I assume you are referring to my point "1", Pablo's current PR for NIP-41?
It's as much required as NIP-26 is required: If your client doesn't support delegated keys it then it won't show them with the correct author, or not show them in the feed at all. In the case of NIP-41 if none of your clients supports it then you loose the connection between the new and the old account (you might not know about the new account).
So for example lets say Pablo needs to renew his key and he uses NIP-41. I decided to keep using an old client that doesn't support NIP-41, I am now going to see his hackers posts. If I'm lucky, someone else we both know will post about his account being hacked and I then decide to follow up and somehow determine what his new npub is (maybe from his github, or because I have another channel with him somewhere). I then manually unfollow his old account and follow his new account. In this sense it is not required. It's a user experience improvement to have NIP-41 support.
The 90 days I wrote was a more or less arbitrary number which I would think is a nice thing to do, a curtesey time that developers give each other in order to give users a better experience.
I don't think this is close to NIP-26 at all. With NIP-41 you can keep using whatever client you want, doesn't matter if it has support or not, as long as every now and then you visit the other NIP-41-specific app that you have and let that app update your follow lists for you -- you could even do that only after being prompted by some message that someone posted about someone else having lost their key. It's a single action that takes a few seconds and you don't have to think about it ever again.
NIP-26, on the other hand, would be a lifelong commitment from everybody.
I was just trying to come up with an example we already know, probably did not choose the best one.
But it seems we agree it's not required.
What do you think of my main point: implementing all 3 solutions in the long run?