pjv on Nostr: I was also freaked out when I recently read that at least one splashily public mobile ...

I was also freaked out when I recently read that at least one splashily public mobile client is completely not verifying signatures by default. I can understand alpha testing in that mode with plenty of DISCLAIMERS everywhere, but in my mind, signature verification is so completely and totally fundamental to the nostr protocol that i don't see how you can call it nostr with a straight face if your're not verifying signatures by default. I don't think it's correct to even have an option to not verify them.

Personally, I don't see how anyone can release a public version of a client that isn't verifying signatures on every note that the user sees (but not every note! - see below).

Which brings me to the question of parsimony. Years ago when I was messing with scuttlebutt I was disturbed by the amount of "waste" overhead that the whole protocol relied on. It felt to me like everyone who wanted to participate had to download and lug around their own redundant copy of the entire Internet. That made me feel that there was no way SSB could scale beyond toy use but I was looking for something that could topple the platforms.

I've seen @vitor exploring the use of merkle trees or bloom filters as a way of pairing down the amount of events that a client is receiving from a relay. I don't understand enough about either to know if that is a viable approach but it seems like some kind of significant deduplication is needed at the client level. Ideally it could happen in the negotiation between client and relay so it saves bandwidth, but every event includes a globally unique, content-addressable ID and at the very least clients could/should be discarding any event they get from a relay that they already have, right?

In my naive mental model of client data, events are stored in a DB table uniquely indexed by their event.id. So whatever code is inserting new events into that table would first query whether the db already has that id (which should be a relatively instant query) and toss it if so. If not, then verify signature and then insert. Is something like that scenario not workable in practice? Or is this already what all the clients are doing and that level of optimization is still not adequate to make signature verification viable on mobile?

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

But maybe this all speaks to how people are using nostr. I personally do not at all get why or how anyone cares about the firehose of "global" feeds. That to me seems like 100% anti-value. Who the hell cares to see (for more than a second out of curiosity) what a mad mixture of bots, spammers, scammers, and people they don't know (or know of) are spewing into the interwebs? That is attention pollution. It's totally toxic. But, whatever, I guess. Maybe I should add a Seinfeldian "not that there's anything wrong with that".

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?