Probably not a problem for clients, since they only get what they ask for. Relays can use auth, PoW, rate limiting, payments, etc. Users need clients to build better tools
Discussion
I think he means relays who don't play by the rules.
A malicious relay coud:
- send the same message(s) multiple times
- send extra messages that don't match the filters
- do this both for stored events (pre EOSE) and for streamed events (post EOSE)
IMO its a viable attack vector, because clients have less resources so by doing the above, a relay could DoS a client.
Even if unexpected events are "filtered out" by the client before showing them to the user, the client still presumably verifies they're valid events, and signature verification is quite intense. So unexpected large events are also an attack vector, they can hit the client CPU hard.
Nostr SDKs used in clients could defend against most of this by
- only returning events that match the subscription filters
- only validating if an event is valid (signature) if the above is true
- not processing and returning events that have already been seen before (much harder to do)
cc nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet
Probably not a concern now, because Nostr is small.
(Another defence for clients is to use a semi-trusted relay aggregator like Wine or caching service like Primal)