damus-io / damus

iOS nostr client
GNU General Public License v3.0
2k stars 289 forks source link

Add nostr event signature verification toggle in settings (Verify, Don't Trust) [Feature Request][Performance][UX] #617

Open alltheseas opened 1 year ago

alltheseas commented 1 year ago

User Story

As an uncompromising verify, don't trust nostr & Damus user, I want an option to toggle Damus checking signatures of received events in my settings, so that I do not have to rely on relays validating signatures on my behalf.

Acceptance Criteria

  1. In settings menu, add verify nostr signature toggle
  2. User can clearly see above toggle, and know when it is off and on
  3. For newbies there is a tooltip that explains the trade-offs of turning off or on nostr event verification
  4. Learn more leads to information website (e.g. nostr-resources.com)
  5. Got itexits tooltip

Mockup: Event Verification Tooltip (1)

Known Tradeoffs Toggle nostr event verification on trade-offs include adding compute crunch, which results in stutters & battery drain Toggle nostr event verification off trade-offs include being reliant on relays to verify events, and improve app performance

Prospective future tickets Multi-threaded support is lacking for incoming messages in Damus, and may improve above performance issues.

Discussion: I'm sorry man, I'm not trying to rain on your parade. I don't even have an iPhone. I am just personally floored by this as signatures are what attracted me to nostr in the first place. It's like that PGP moment, we all finally have signatures, we finally convinced people to use them!! Am in the only one thinking this?

Mobile is very hard and I have no doubt someone will have to centralize an app to really provide a good mobile experience with push notifications and low bandwidth usage. What I did not expect was for the heavyweight clients we have now to skip sig checks. Half the clients I use connect to relays that I didn't even pick when they start. -cloudfodder@rogue.earth https://snort.social/e/note1q9jjqv0jpaqka8k8wq8qavthvucefuqqt39l4kcw6dvkgwjvnkms0mtucl

I'm not even against it, it will just take some time to make it performant. Damus only connects to a set of relays you trust/vet and does not connect to random relays. It is not an unreasonable tradeoff in those settings and the perf/battery life gain is noticeable. I had it on originally until the perf hit was too bad to justify when the servers are already validating sigs. People should PR this if they think its a huge issue, I do not at this time but obviously this will not be true forever. -Will

If you get a duplicate event that's already validated, you can toss it and skip validation. I don't know if that improves performance or if you were already doing that.

This looks relevant but also looks hard (unless some library already does it): https://bitcoin.stackexchange.com/questions/80698/schnorrs-batch-validation -mikedilger

pjv commented 1 year ago

Below are maybe relevant sections of a longer rant I posted on nostr.

At the very, very, very least, it seems like every client should absolutely verify signatures on any events posted by a users follows.

But I can definitely see where mobile clients could optimize on signature verification by not verifying events in global feeds (which are 99% garbage anyway). Every event from a follow should be verified though. Maybe also every event from a follow of a follow too if that doesn't get too expensive. Would that work?

@jb55

alltheseas commented 1 year ago

At the very, very, very least, it seems like every client should absolutely verify signatures on any events posted by a users follows.

But I can definitely see where mobile clients could optimize on signature verification by not verifying events in global feeds (which are 99% garbage anyway). Every event from a follow should be verified though. Maybe also every event from a follow of a follow too if that doesn't get too expensive. Would that work?

Thanks for the suggestions @pjv. Here's a go at writing down the two user stories suggested.

User Stories

1) As an uncompromising verify, don't trust nostr & Damus user who wants to have confidence in the veracity of my follows notes, I want Damus to verify note signatures of all of my follows posts, so that I can have confidence I have reading my follows posts 1:1.

2) As an uncompromising verify, don't trust nostr & Damus user who wants to have confidence in the veracity of my follows notes, I want Damus to verify note signatures of all of my follows, and follows follows posts, so that I can have confidence I have reading my follows, and follows follows posts 1:1.

@pjv what do you think about the below story:

3) As a Damus user who occasionally wants to check the veracity of a user's note that I do not follow (e.g. in global feed), I want the capability to manually (ad hoc) verify a note of a user who I and my follows don't follow, so that I can gain confidence in notes from users not in my network (one or two hops).

pjv commented 1 year ago

@alltheseas I’m not currently a Damus user so I don’t feel like I have any legitimate “standing” for those stories. I just was surprised to learn that Damus was not verifying signatures by default because I think sig verification is core to the nostr protocol.

But I understand needs of mobile devices and while I was ranting about the non-verification in another conversation I thought of the idea of significantly lowering the quantity of verifications by just ignoring all the events not posted by my direct follows or maybe also follows of follows.

In particular, if Damus is downloading global feeds, or even popular public chats, then I’d imagine that the overwhelming (>99%) majority of the events it is ingesting on those feeds are probably “junk” to the user and so not verifying sigs on events in those feeds (except if they are by follows or maybe follows of follows) makes sense as an optimization.

But I do think that if there are going to be some events that are verified by default and some that are not, that it makes sense to have some UI/UX (an icon? Or maybe just a colored line or colored background so it doesn’t eat space) to indicate the difference and it would be also great if part that UX let the user request signature verification on any arbitrary event that was not verified.

I know that coding all that UX takes a lot longer than coding the plumbing, so if I were a user, I’d definitely expect to wait longer for that stuff than other changes that can be built faster.

alltheseas commented 1 year ago

Thanks for the context @pjv. This helps provide color to the various novel challenges relays pose to nostr client users. If you search for relay in issues, you will find a collection of relay stories that intend to guide the new nostr user.

But I do think that if there are going to be some events that are verified by default and some that are not, that it makes sense to have some UI/UX (an icon? Or maybe just a colored line or colored background so it doesn’t eat space) to indicate the difference

Was thinking about a visual indication as well. Example user story:

  1. "As an advanced Damus user who is examining the veracity of a note, I would like to see a visual indication that Damus has checked & verified a note's signature, so that I have confidence this is the note the note sender intended to send."

it would be also great if part that UX let the user request signature verification on any arbitrary event that was not verified.

I attempted to write up this user story to your problem statement above:

"As a Damus user who occasionally wants to check the veracity of a user's note that I do not follow (e.g. in global feed), I want the capability to manually (ad hoc) verify a note of a user who I and my follows don't follow, so that I can gain confidence in notes from users not in my network (one or two hops)."

alltheseas commented 1 year ago

https://github.com/damus-io/damus/pull/674

alltheseas commented 1 year ago

Profiles are verified with latest nostrdb update.

alltheseas commented 9 months ago

@jb55 are all notes now verified on latest nostrdb powered Damus iOS build 1.7 (11)?

If yes, do you have an understanding on the performance impact?