bu5hm4nn on Nostr: RE: NIP-41 discussion at #nostrasia https://www.youtube.com/live/Nz15SyiwQFk?t=16400 ...
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 PABLOF7z (npub1l2v…ajft) 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: hodlbod (npub1jlr…ynqn), Vitor Pamplona (npub1gcx…nj5z), jb55 (npub1xts…kk5s), JeffG (npub1zuu…c2uc))
2. Yes, in a separate NIP we should implement fiatjaf (npub180c…h6w6)'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. Karnage (npub1r0r…q9ac) dtonon (npub1000…vwqk)
https://www.youtube.com/live/Nz15SyiwQFk?t=16400
My thoughts on the different ideas discussed is: YES
1. Yes, we should consider implementing what PABLOF7z (npub1l2v…ajft) 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: hodlbod (npub1jlr…ynqn), Vitor Pamplona (npub1gcx…nj5z), jb55 (npub1xts…kk5s), JeffG (npub1zuu…c2uc))
2. Yes, in a separate NIP we should implement fiatjaf (npub180c…h6w6)'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. Karnage (npub1r0r…q9ac) dtonon (npub1000…vwqk)