[Spam Control] Add spam filtering to all our relays

[setch-l]

Add the same tools for spam filtering to all of our other relays that we did for relay.nos.social.

dwebcamp.nos.social
news.nos.social
olympics2024.nos.social

[dcadenas]

• news.nos.social: PR ready
• relay.nos.social: already merged
• dwebcamp.nos.social: I need to know where is the repo, branch used and how it was deployed cc @mplorentz
• olympics2024.nos.social: Doesn't need it

[dcadenas]

I just sshd to dwebcamp, it's the same server as relay.nos.social so it's already done, same filters and policies

[mplorentz]

@dcadenas what do you mean it's the same server? It's running on a different droplet right?

This was a good prompt for me to clean up this PR. If you approve go ahead and merge it.

[dcadenas]

Oh sorry, yep, that's what I meant, same repo branch as relay.nos.social, and it receives all updates after each push

[setch-l]

@dcadenas @mplorentz - This issue skipped UAT and should not have. I will create new tickets for the issues I'm seeing related to this work.

[dcadenas]

@setch-l I agree that the text-based filter is easily tested by anybody, but most backend code usually doesn't go through UAT, so I just missed the opportunity to do so this time. Should we always move to UAT from now on? I think it would be a good idea, but I'm worried we may not have enough people to do so effectively.

The other thing we wanted to do for this PR was to rate limit writes. That requires more technical tools to test, at least nak, so I just went ahead, mentioned that it was done, and moved on.

Of course, I confirmed this was working fine manually and sent an example output of the rate-limiting side privately to @mplorentz, who would have been the only candidate to test this if it was officially moved to UAT. This has little friction, especially for a small company like ours, and I know we are all overloaded. So although I like the idea of UAT, I'm also worried that it may be overkill for this type of work.

Anyway, next time, if I see that at least some part of a PR can be manually checked by someone, I'll move it to the UAT column.

[setch-l]

@dcadenas - Anything that impacts the user should go through UAT. This problem is still very much not resolved. By skipping UAT the discussion about the issue gets dispersed to Slack and beyond instead of remaining in a single location. This results in unnecessary churn.

[dcadenas]

Yes, that makes sense. However, this issue is in fact resolved, which is why I moved it to "done" myself. UAT is a good idea, and I agree it would be nice to avoid doing it myself manually in the future, it's like doing your own code reviews, not ideal.

We should have a larger issue dedicated to solving spam and outlining the different solutions we're rolling out. At least as a summary of slack conversations and current state. Without this, it becomes unclear what our definition of "done" is, gives the wrong idea that PRs don't solve what it was planned, what is pending, and how the various PRs across different repos contribute to global solution.

[setch-l]

@dcadenas - It was not done until this weekend and I had to advocate for additional work to make sure reply-guy wasn't using the dwebcamp relay. I just tested it now and it looks like it is working.

[dcadenas]

@setch-l that's not correct, this was done 2 weeks ago. It implementes exactly what the issue description is asking to do. You can check the history of this issue, this is implemented PR #4

I think you are confusing with the PR that added IP bans which doesn't have an issue. This is what I'm talking about, the lack of an top level issue is bringing a lot of confusion about the conversation, the work done and what's pending.