are nostr clients doing some type of signature verification for messages received from relays?
reason i ask; if a popular relay is hacked: what is to prevent an attacker from flooding that relay's subscribers with counterfeit messages?
are nostr clients doing some type of signature verification for messages received from relays?
reason i ask; if a popular relay is hacked: what is to prevent an attacker from flooding that relay's subscribers with counterfeit messages?
clients shouldn't be responsible for this; even for spam filtering, i get it; however, that extra layer of protection would be glorious
No. It would be nice but very expensive on device performance according to many developers
NostrGram verifies the signatures of all events going into its caching server. The client isn't currently re-verifying the events once they reach the client from NostrGram's database since 1) they've already been verified and 2) event verification is a CPU expensive process so it saves the mobile devices CPU and battery power. But it would be simple to do. The function is in my library. I'd just have to drop a line of code into the client.
ahhhhh so nostrgram indexes them in a middle layer, and client fetches from nostrgram?
even this is good though actually, if nostrgram is shielding its' users from this
imo, no client should ever show a message that isn't sig verified. but in nostrgram's case: it fits my ask, considering it has a middleware layer ☺️
Yes that's what it does. Also saves a ton of bandwidth for mobile devices since they only have to read from one server instead of a dozen or more. It's currently indexing the top 100 relays, but I'm updating that tonight (doubling it) now that more relays are coming online. Writes go out to all configured write relays in the usual way, but of course writes are a tiny fraction of bandwidth and CPU usage to create the signatures on those.
this is a really good approach. actually for the simple clients (the ones i imagine will onboard the masses who shouldn't care how nostr works internally), should follow a similar architecture. really good work
Damus seems to have support for this but is disabled. Note sure what performance impact it would have.
https://github.com/damus-io/damus/blob/master/damus/Nostr/NostrEvent.swift#L100