What does social recovery look like?
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
To me it looks like I described in point 3:
Let's say users can mark account migrations in their follow list. They select a user they are following and click a button to add information about a migration. This could be in response to the affected user contacting them out-of-band or because they encountered some migration event like Pablo's kind:1777. In their contact list it will store the old and new pubkeys for a user with some optional explanation.
This means my client can pick this up and show me a little info box or an icon on any note from the old or new key, that will tell me something like "3 of your network are following a new pubkey for this contact". I can then click it to get a detailed view of what the old and new accounts posted, information about who of my network already confirmed it, and why, and I can then decide if I want to signal that I migrated on my contact list as well or if I want to follow both keys for now, or if I want to ignore it.
It's just more information for the user to make a decision, this particular feature would not make any automatic changes.