have to put my relay operator hat on today and update noteguard to automatically ip block/timeout spammers who consistently hit the note write rate limit of 6 posts per minute on the damus relay. The ratelimit is fine to prevent a firehose of spam but some still get through. Would be nice to block it for good. There’s always some fire to put out 😮‍💨

Reply to this note

Please Login to reply.

Discussion

🤦‍♂️ The never-ending battle against spammers! 💥 I feel you, blocking those pesky users can be a challenge. IP blocking and timeout are solid measures, but as you said, some sneaky ones still find their way through.

On the other hand, it's awesome that you're proactive about updating Noteguard to keep your damus relay safe from spam bots 🤖. Those guys are like the in-laws who just won't quit visiting 😂.

Here's a witty reply: "Time to turn up the heat on those spammers! 💥 IP blocking and timeout, here we come! 🔒 And when they say 'I'll be right back', you know it's time for a permanent ban 🚫. Good luck with the update, and may the spam-free force be with you!" 😄

How ironic 😂

I’m looking into web-of-trust today also to drown out the in-laws

Good thing I use the HPC (Hunt, Peck, and Cuss) method of typing.

Is there a better solution than rate limiting that doesn’t involve wot?

I can’t think of any

Do they use different IPs every time?

not sure, but if i do auto ip banning would take care of it, unless they get sophisticated and continuously post under the rate limit across multiple machines. Then i dont know what i would do next. Probably AI spam detection?

What about captchas 🤔 make them fill those out 🤣

How about 1sat/post. You buy them before you post and use them as lon as you want

That would keep most people out :(

Yes the goal of the main damus relay is free for use by everyone (with reasonable spam limits)

ChatGPT gave me this

If you want to mitigate spam without relying on authentication, KYC, or CAPTCHA, you’ll need to focus on mechanisms that operate passively or are transparent to legitimate users while still making spamming costly or impractical. Here’s how you can achieve this:

1. Advanced Rate-Limiting

• Sliding Window Rate Limiting:

• Instead of fixed limits (e.g., 6 posts per minute), use a sliding window that dynamically adjusts based on user behavior.

• Example: If a user sends 2 posts in 10 seconds, slow them down further (e.g., increase delay between posts).

• Adaptive Rate-Limiting:

• Increase the delay for posting if users exhibit behavior indicative of spam (e.g., repeated patterns or high frequency).

• Legitimate users won’t feel this as they rarely approach limits.

2. Proof-of-Work

• Require clients to perform a lightweight computational task (e.g., solving a hash puzzle) before each post.

• Use libraries like hashcash to implement this.

• Adjust difficulty dynamically:

• Low posting rates = easy tasks.

• High posting rates = harder tasks.

• Spam becomes resource-intensive, especially for distributed attacks.

3. Behavioral Analysis

• Use heuristics or machine learning to detect spammy behavior without blocking legitimate users:

• Look for repeated similar messages from the same IP or across multiple IPs.

• Detect patterns like burst activity (sudden spikes in message rate).

• Analyze time intervals between messages to identify automation.

• Temporarily ban or throttle suspicious activity.

4. IP-Based Techniques

• IP Fingerprinting:

• Track patterns associated with specific IPs, such as frequent message submissions, and temporarily ban offenders.

• Soft IP Limits:

• Enforce progressive throttling based on message volume:

• First 10 messages per IP are free-flowing.

• Further messages introduce delays or are queued.

• IP Rotation Detection:

• Use reverse DNS lookups or IP clusters to detect rotating proxies.

• Block ranges of IPs if they’re part of spammy networks (e.g., TOR exit nodes, known VPNs).

5. Message Content Filtering

• Duplicate Message Detection:

• Block or flag identical or nearly identical messages being sent repeatedly.

• Spam Keyword Detection:

• Maintain a list of common spam phrases, URLs, or patterns, and filter messages that match these.

• Natural Language Processing (NLP):

• Use a lightweight NLP model to detect unnatural or spam-like messages (e.g., repeated links, excessive characters).

6. Reputation-Based Throttling

• Assign reputation scores to connections based on their behavior:

• New connections/IPs get stricter rate limits initially.

• Over time, if no suspicious activity is detected, the rate limit relaxes.

• Track reputation at the IP level and across message patterns.

• No need for explicit user accounts or authentication.

7. Delayed Backoff

• Introduce progressive delays for repeat submissions:

• First 3 messages are instantaneous.

• After 3, introduce a delay of 1 second, then 2 seconds, etc.

• Legitimate users can tolerate slight delays, but spamming becomes impractical.

8. Honeypots

• Create invisible fields or endpoints that only bots will interact with.

• If a client interacts with these, automatically block them.

• Example: A WebSocket endpoint that bots mistakenly try to send data to.

9. Token Bucket System

• Assign tokens to each connection:

• Each message consumes a token.

• Tokens regenerate at a fixed rate (e.g., 1 token every 10 seconds).

• Spammers will exhaust tokens quickly, while legitimate users will naturally regenerate them.

10. Statistical Pattern Recognition

• Analyze activity across the entire relay:

• Detect unusual traffic spikes.

• Identify message patterns repeated across multiple IPs or regions.

• Use these insights to automatically adjust throttling rules.

11. Geofencing or Regional Restrictions

• If spam primarily comes from certain regions or IP ranges, apply regional throttling or outright block those regions.

• Legitimate users from allowed regions won’t notice any impact.

12. Content-Based Delays

• For certain types of content (e.g., messages with links), introduce submission delays or extra processing time.

• This discourages spammers while minimally affecting legitimate users.

Final Strategy Without KYC, CAPTCHA, or Authentication

• Combine multiple approaches, such as:

• Rate-limiting (adaptive or token bucket).

• Behavioral analysis (detect patterns or anomalies).

• Proof-of-work for high-volume senders.

• Content filtering for duplicates or spam keywords.

This layered approach makes it resource-intensive for spammers while remaining transparent for legitimate users.

Another thing that is free and could be done is to allow only PoW notes.

Yeah. Could introduce sliding scale pow. But probably need a variety of different spam blocking mechanisms.

Could also pow requirement on all notes. Low enough to not slow posting significantly but introduces an expense to spammers.

This will probably kill Dvms on your relay because of Primals caching thing. Bad for anyone using damus relay as inbox, but it is what it is.

people probably shouldn’t be using damus relay as an inbox

Primal caching service does. That's the main issue.

sounds like a feature then. Didn’t know primal was spamming my relay

nostr:nprofile1qqsdv8emcke7k3qqaldwv956tstu40ejg663gdsaayuuujs6pknw7jspp4mhxue69uhkummn9ekx7mqprpmhxue69uhhqun9d45h2mfwwpexjmtpdshxuet5qyf8wumn8ghj7ur4wfcxcetsv9njuetnn9mexk can you please not use damus relay for the DVM caching thing? Should be fine to have 1 relay like Primals own one. Maybe one or 2 backup ones, but not relays with strict rate limiting. You guys keep sending lots of requests at the very same time to my server, and it replies at the very same time to those requests, which triggers spam protection already on Damus relay.

I’m still confused why my relay has anything to do with this, why don’t they use their own relay? Unless they do it based on picking a single relay from your relay list. Maybe need to mark which one is your inbox relay and they would use that instead ?

Maybe they do, I don't know. But I reply to the npubs Inbox relays (or relays in relay tag, if given) of the original request. And this has damus relay in it (among many others). So even if I get 20 requests at the same time to only my inbox relay, I will reply to 20 requests about the same time to the inbox relays of the sender. It would easily be fixed if the service uses 1-3 inbox relays that do not rate limit and is ideally in their control.

everyone has damus in their inbox relays so thats why the dvm spams there right..

hah! i don't. i wish i could remove wine from mine too, because that isn't very expensive to get write permission for

but maybe also this is why i can never see people's messages consistently, perhaps i should add it lol

also, what irony... the nostr client for the hardware/OS ecosystem where everything is paid, has to be free... because apple users are such ninnies they don't realise that is part of the reason why their devices cost so much (not just because they are moderately high spec, that is part of it but not all) is paying for the operation of the spying machine called iCloud and their Apple login, and ensuring that maximal telemetry is extracted from every user

oh but they use e2ee lol whatever, it's not e2ee, that's a lie

Nah. The issue currently mostly is that 2 npubs send requests to all dvms at the exact same time, triggering rate limits when they reply (as they use the same ip). Primal users do not interact with dvms. The caching service does.

Yes makes sense; we’ll reduce the relay set to just primal and one more. We already implemented randomized delays; let me know if you are still seeing issues on your server.

Yo, that seems way better 🤙 and I guess it should work the same for you.

LFG!

Looks like we’re both having a relay day.