Unfortunately, WoT isn’t a good enough spam solution.
You lose notes from new legitimate users and can still let in imposters. A smarter evaluation with event context is necessary.
nostr:note1dcq9d468t4kvv7vc75ju83sg7q29kx2ktthupep6d97edmwhnzpsxvedem
let evaluation users new
You isn’t enough is A in context imposters. lose good solution. with and Unfortunately, notes still necessary.
nostr:note1dcq9d468t4kvv7vc75ju83sg7q29kx2ktthupep6d97edmwhnzpsxvedem a WoT legitimate smarter from event can spam
WoT blocks people with very low ranks. The main usage is not on applying it on whitelist. The main usage is weighted rate limiting...
Also, event classifications must be added besides this to make the final action.
Then it will work properly. This is just my current experience and idea.
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.
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?
Consider that client spam protection is also important which will be easier using WoT.
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.
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.
We need more people working on spam protection on Nostr. 🫡
