Moderation suite

[dawnofmidnight]

(part of the Carl ⇒ Ferris migration)

A huge part of what we got from Carl is the moderation suite, and we need to move that to Ferris. We could do a 1:1-ish port, but I know that generally we had some gripes with Carl. As opposed to the other issues, I won't propose a particular design here, although I will leave a comment with my very tentative design ideas. This is primarily here for discussion and tracking.

However, I will note that we should have integration with inbuilt Discord moderation. Regardless of the system, if a mod does a ban/kick/timeout using the native system, it should be registered in our database as being no different from an action done by our own commands.

[dawnofmidnight]

This is my personal design sketch for the moderation suite. It's primarily based on a my main pain point with Carl—namely, that warns, notes, bans, etc. are all separate kinds of things. I think it necessary that we have a unified infraction (bikesheddable name) interface that manages all of these.

Fundamentally, each infraction should have the following information:

• ID: a serial ID (to keep it short and writable, but unique)
• type: what kind of infraction it is
• user: the person it applies to
• actor: the mod who performs the action
• reason (optional): why the infraction was applied
• creation source: a link to where the infraction was created, to easily find context after some time
• creation: timestamp when it was created
• expiration (optional): when the infraction expires for temporary bans, mutes, and voice mutes (if we have those)
• active: true unless the infraction has already expired or been removed (e.g. unbans)
• notified (optional): not super sure about this one, but it might be useful to note whether a DM was successfully sent to the user or if they had those disabled.

These should be associated with the following commands (all of these can also be slash commands, and I'm using i as short for infraction):

• ?i <infr id> (show infraction information)
• ?i expiry edit <infr id> <time/duration>
• ?i reason edit <infr id> [reason]: change the reason of the infraction to reason, or remove it if it's empty
• ?i reason append <infr id> <text>: append text to the infraction, potentially after a delimiter such as |. This could be useful for quickly adding a message link of context that's not part of the message sent to the user (since only the original reason is sent).
• ?i user <user> should list all of a user's past infractions

Here are the types of infractions I think we should have. These should also be accessible at the top level (i.e. as both ?i ban and ?ban):

• ?i note <user> <reason>: (permanent, internal) keeps a piece of information regarding the user, no Discord action
• ?i warn <user> [reason]: (permanent) sends the user a message as a formal warning, no Discord action
• ?i kick <user> [reason]: removes the user from the server
• ?i mute <user> <expiry> [reason]: applies a temporary mute to the user
• ?i unmute <user> [reason]: unmutes the user and appends reason to the original infraction reason
• ?i ban <user> <expiry> [reason]: applies a permanent ban to the user
• ?i purgeban <user> <duration> [reason]: applies a permanent ban to the user and deleted their messages over the past <duration> time
• ?i tempban <user> <expiry> [reason]: applies a temporary ban to the user
• ?i shadowban <user> [reason]: applies a permanent ban to the user and does NOT send them a DM. useful for people we believe pose a safety risk to the server.
• ?i unban <user> [reason]: unbans the user and appends reason to the original infraction reason
• We may also want voice-specific functionality akin to mute and ban as voicemute and voiceban respectively.

So, yeah. This is my very tentative design of the moderation suite. None of this is final or approved in any way, it's just my thoughts.

[troiganto]

For things like temporary offtopic bans and VC bans, Carl has generalized commands that work like mute/tempmute/unmute but for any given role. Given the large number of moderation-related roles we have, I think this would be useful here.

To avoid misunderstandings, mute/unmute should be renamed to "timeout" to make clear it uses the Discord built-in feature. Our classic muted role would then be applied by ?i temprole @Muted and ?i role @Muted or something similar.

One pet peeve with Carl is that if you don't specify a time frame for a mute, it defaulted to, I think, 30 minutes. I think that's a very minor design decision we should avoid here.