Chat

[Nico8340]

Chat

This Pull Request removes chat management from all game modes and adds a new, separate solution that is highly configurable and customizable, with automatic moderation by today's standards.

Fixes #460 Follows #461

Preps

• [x] Remove onPlayerChat handlers from gamemodes
• [x] Remove onPlayerChat handlers from admin and admin2
• [x] Remove onPlayerChat handler from playercolors

Tasks

• [ ] Implement message sending
• [ ] Implement message logging
• [ ] Implement chat filter config
• [ ] Implement chat filter
• [ ] Implement sanctions
• [ ] Implement anti-spam
• [ ] Implement anti-repeat

Backlog

There was discussion that it would be nice to include a user interface in the existing admin panel to configure moderation. This will be implemented optionally after the later works.

[Dutchman101]

Copying over my proposal from the previous PR..

How about some advanced anti-spam features, like:

• Configurable limits with action, like: mute, kick, or ban player for x duration if they repeatedly get flagged for spamming. Mute is the first line defense, to store serials of repeat offenders for persisting spamming rap sheet, an SQLite .db can be used. The more times they get a lighter automatic punishment (mute, kick), the sooner it will escalate to a more severe punishment, Mute > kick > 30 mins ban > longer bans as defined in meta.xml. In this case, also add a toggle for automatic .db clearing (choice between interval or to do it on server launch)

Measures against coordinated spamming, like: Multiple players are sending the same or similar message (not a single source, but it'll be big) or different ones; measures like anti-repeat or chat limits per player won't be effective

• If chat activity exceeds a certain amount (specified in meta.xml) of messages per the polling window (specified in meta.xml, default: 10 secs), an abnormality has started and the system will offer a meta.xml toggle-based resolution: slowmode (limit chat messages globally, from anyone.. and return "You need to wait, slowmode has been activated due to possible spam" to anyone that tries to talk while it's still active

Server owners can tweak the # of messages/polling interval based on what's normal for their server. For example, if it's a gamemode some people can get hyped up and send a burst of happy messages, like end-of-round, they would need to make the polling interval longer. If the server gets more popular (leading to increased chat activity), they would need a higher message count tolerance.

So a spamming incident can be resolved without the presence of a server admin. If one is present when slowmode is activated, they should be able to use a command to lift it if they go to manually resolve it (like: ban the coordinated spammers)

Bonus points: every time slowmode has been applied, automatically send a "suspected spamming incident report" into the admin panel reports list (submitter: not player, but system) eventually with a recap of the chat lines ( + author) around the time it got triggered. Using the same functionality that already captures a player's last chat messages if they got reported with /report & selected in the target player dropdown.

[Dutchman101]

In the upcoming code reviews (when all commits are added to the new PR), there should be extra attention for conditions/optimal branching of the code in onPlayerChat, to ensure that there's no grave performance consequences that comes with complexity; ideally, most chat messages (to say: ones that don't trigger any detection or additional checks) shouldn't take much more CPU time/be slower than 'clean' onPlayerChat handlers present in various gamemodes before this.

I didn't review or test this, but we need to keep our eye on this aspect, it has to be checked off on when the PR is in its final state.

[Nico8340]

A few people said it during the previous PR and also on Discord, they think it's not a good solution to implement the chat in the admin resource, since quite a lot of people use the admin resource in their own projects, so they need to turn off the chat or change the code if the latest version is used. In addition, if we want to implement all of this in the admin, two resources must be managed at the same time.

What do you think, wouldn't it be easier to create a new resource called 'chat' for this? @Dutchman101

[Dutchman101]

What do you think, wouldn't it be easier to create a new resource called 'chat' for this? @Dutchman101

yes. Then also output a console warning if one of the gamemodes are running (that now rely on the chat resource) but the chat resource isn't.. or even preserve the original chat handlers in those resources, but attach/detach them based on whether or not the new chat resource is in use; this will provide server owners the freedom which road to walk entirely. It can also be compounded with an opt-in or opt-out (meta.xml) above the running state of 'chat', and since the old chat handlers containin the old code will be present as well, it can just fall back on it. Any server owners that run into issues can conveniently return to the old behavior.

[jlillis]

A few people said it during the previous PR and also on Discord, they think it's not a good solution to implement the chat in the admin resource, since quite a lot of people use the admin resource in their own projects, so they need to turn off the chat or change the code if the latest version is used. In addition, if we want to implement all of this in the admin, two resources must be managed at the same time.

What do you think, wouldn't it be easier to create a new resource called 'chat' for this? @Dutchman101

I think if you are going to go forward with these expanded features it makes sense for it to be in a separate resource. However, I would personally like to see a section in the admin2 panel added to interface with chat and manage these settings in a way that gives appears to the user that it is part of the admin panel rather than an add-on. I think that can be covered as a separate scope of work in a later PR.

[Nico8340]

I think if you are going to go forward with these expanded features it makes sense for it to be in a separate resource. However, I would personally like to see a section in the admin2 panel added to interface with chat and manage these settings in a way that gives appears to the user that it is part of the admin panel rather than an add-on. I think that can be covered as a separate scope of work in a later PR.

It's a good idea, I'll think about it after completing the remaining tasks.