Nostr Web Client

Most spam tends to use pubkeys ephemerally though, so what are you rate limiting? Ultimately you’re just going to be blocking their first few messages or allowing all spam.

If you have access to network level info (we don’t as an aggregator) you could do some IP or other network rate limiting but that is still imperfect.

کیهان 7mo ago

It's a hierarchy:

1. IP and network rate limiting.

2. Paid access.

3. WoT minimum rank (so they are not hot keys generated just right now.)

4. If they have a low rank and high potential to spam, we slow them down rapidly.

5. Event classification service would report if its repeated and we immediately ban them. Also, report events are supported so people can report as well.

Spamming such systems would be very hard.

The wine approach is also seems interesting but I need to take deeper look. You may want to start a repository or resource of different nostr spam protection models?

Reply to this note

Please Login to reply.

Discussion

کیهان 7mo ago

Consider that client spam protection is also important which will be easier using WoT.

Mazin 7mo ago

Glad you’re thinking about it! Definitely agree multitiered approach is required and sounds like you have some good ideas.

It would definitely be easier if they were writing the events directly to us and we had network visibility.

Clients definitely have a role to play, but if relays store spam indefinitely (even without surfacing it to users) they will eventually run out of resources.

کیهان 7mo ago

Thanks. 🫡 its was our 1st priority from beginning.

Yes, we already solved the same issue with different context!

I agree. The first actor must be relays, then clients.