Nostr Web Client

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

Yonle 2y ago

> 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)

Requiring every single clients to support this NIP just for this function? Sounds like rewriting an standardized RFC to achieve what you exactly wanted.

Requiring them 90 days to implement this feature is BS. No. We do NOT need this NIP in every nostr client. Let the developer decide.

I even personally think this NIP is stupid. Just let the client tell to the follower that this user has been migrated to new pubkey by reusing the `kind 0`, By putting `moving` as the new pubkey.

Reply to this note

Please Login to reply.

Discussion

Yonle 2y ago

So, our metadata should be:

```

{

"name": "Yonle",

"display_name": "Yonle",

"about": "Self taught programmer from Indonesia",

"website": "https://yonle.lecturify.net",

"nip05": "yonle@yonle.lecturify.net",

"lud16": "humidprocess01@walletofsatoshi.com",

"moving": "341xxxxxxxxxxxx" // <- New pubkey in hex

}

```

Yonle 2y ago

And remember this.

> This UX wouldn't be very different from the one we have today, in which an attacker can steal someone's key and start publishing notes every day saying: "this key is compromised, switch to my new account npub1..." -- pointing to an account controlled by the attacker.

https://github.com/nostr-protocol/nips/pull/829#issuecomment-1778055274

And that's why i am strongly disagree with this new NIP.

bu5hm4nn 2y ago

No, I disagree with nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 that the UX would not be much different.

With Pablo's proposal, once a user fires of the kind:1777 to initiate migration, if your client supports it, depending on how the client implements it, you would not be seeing the attackers notes, or they would have a red border and warning signs telling you that these notes were written after the valid kind:1777.

Today the client has no way to know. With kind:1777 your client can now warn you about the situation.

Of course it's not a mandatory feature. But it's very central and I think any client that relies on kind:3 or other lists will want to implement it.

The 90 days was an idea to prevent front-running by a few clients, as we have seen in the past, it's how long the fast implementers wait as a curtesey to the others, not a deadline.

fiatjaf 2y ago

Then if you lose your key the attacker can put his own key in the "moving" field and then all your followers go to him.