This document describes our ideal Matrix moderation bot.
Currently, the Ubuntu Matrix project is using Mjolnir, with a medium-term plan to switch to Draupnir. But those bots don’t support all the features we want. The Ubuntu Matrix team currently doesn’t have the resources to invest in developing a new bot. Nevertheless, if anyone is interested in working on this we welcome any contributions. Additionally, if any developers of existing bots are interested in adding these features to their bot, we’re happy to have a discussion with them.
Feel free to continue the discussion below about this wishlist.
Possible Programming / software stack
- Python
- Most well-known language in our ecosystem. This might allow more people to contribute.
- Golang
- Fast, easy to learn, native, and used widely in Canonical.
- Node.js
- Already used for Mjolnir & Draupnir. But less popular in the Ubuntu ecosystem.
Feature set
- CoC acceptance challenge
- Passive mode - informs the user that the CoC exists upon entry via a private message, immediately grants talking privileges
- Passive + delay - same as Passive, but waits for a configurable length of time before granting talking privileges
- Active mode - informs the user that the CoC exists upon entry via a private message, requires explicit acceptance via a reaction click or text message before granting speaking privileges to the user
- Active + delay - same as Active, but does not permit the user to accept the CoC until a configurable delay has passed
- Server-wide ban, mute, and kick via bot commands provided directly in the room where the offending user is
- These commands require confirmation in a bot control room
- Local-only ban, mute, and kick should also be provided
- Ban list following
- Must be compatible with existing ban list rooms
- User authentication for mods and defenders
- Moderators can take any action against anyone in a room that they moderate.
- Defenders can only take action against users who have not had (significant?) activity in the channel for a configurable length of time, excluding the most recent activity since of course that activity may be the user causing trouble.
- Defenders may be local or global, moderators are always local.
- Users that attempt to pass bot commands without sufficient privileges must be informed that they don’t have the rights to do that.
- “wallops” - sending a message to everyone in every Ubuntu room at once
- use @room to make this easier rather than pinging everyone
- Defenders and even moderators must not be able to trigger this, perhaps only Matrix Council can use this?
- Flood protection
- Take into account number, type, and size of messages - lots of small text messages are far less likely to be trouble than lots of large messages or lots of images
- Prohibited word handling
- Have configurable “punishment levels” for certain words - strong language may warrant only a warning, repetitive use of strong language may warrant a mute, certain words may trigger a ping to mods and defenders in the bot control room, use of a select few “always evil” words results in an immediate server-wide ban.
- Decent unbanning features that avoid weird Mjolnir-like fiascos
- Max thresholds for different types of user activity for newly interacting accounts. Ranked against other newly interacting accounts performing the same activity at the same time or on their own.
- “Differential moderation” so regulars of a room and/or chosen users gain the ability to kick/ban/redact newly interacting accounts without having to give them full moderator powers.
- Auto-hardening so room engagement requirements for newly interacting accounts scale based on how many thresholds were expended in a given period.
Out of scope
- Factoids. This should be Maubot’s job
Technical requirements
- High concurrency, should make use of multiple threads to be able to quickly handle incidents across many, many rooms, must NEVER, EVER block for any significant period of time if at all possible since it has to be responsive. This has to scale to potentially hundreds of rooms and thousands of events per second.
- Use some high-speed database backend or (maybe?) rely heavily on RAM for fast scanning of events and remembering what’s happened.
- Must package well into a Snap since that’s probably how it will be deployed.
- devcontainer considerations for making contribution easy?
Testing framework
- We need something that can emulate a /sync endpoint for testing how the bot behaves, this should deliver configurable JSON messages at a defined rate