.svg)
Before we talk about how to moderate voice channels, it's important to consider why it's necessary. In some servers voice channels are rarely used, or only used for events where a moderator is present. If this is the case for your server, moderating voice channels is likely much more straightforward. This article will focus on how to moderate voice channels in servers where voice channels are used frequently and without moderators present. However, the information in this article is still useful to any server with voice channels. Although these situations may be rarer for your server, it doesn't hurt to be prepared if they do indeed occur.
Many of the moderation issues you will encounter while moderating voice channels will be the spoken equivalent of situations you would encounter in text channels. However, you can't keep records of what is said in voice channels without recording everything with a bot, which is not easy to do, nor is it something your server members will likely be comfortable with. This means that if no moderator is present in the voice channel at the time of a user being troublesome, you will likely hear about the situation from a user who was present for it. We will discuss best practices in handling these user reports in the next section of this article. There are also a few situations specific to voice channels to be aware of.
Common situations that would require moderator intervention that might occur in voice channels are as follows:
Before we even consider how we plan to moderate situations that may arise in voice channels, let's discuss ways to prevent them from happening in the first place, or at least make it easier for us to deal with them later. One of the easiest and most useful things you can do is set up voice channel logging. Specifically, you can log when a user joins, leaves or moves between voice channels. Many moderation bots support this type of logging. You can read more about using bots for moderation in DMA article 321. For reference, here's what this kind of voice channel logging might look like:
Having voice logs will allow you to catch voice hoppers without having to be present in a voice channel. It will also prove useful in verifying reports from server members and ensuring users can't make a false report about other users who weren't actually present in a voice channel at the time. Another thing you can do to prevent trolls from infiltrating voice channels (and every other part of your server) is having a good verification gate. You can read more about verification gates here.
*Unless you are using the channel description for verification instructions rather than an automatic greeter message.
If you want to use the remove unverified role method, you will need a bot that can automatically assign a role to a user when they join.
Verification Actions
Once you decide whether you want to add or remove a role, you need to decide how you want that action to take place. Generally, this is done by typing a bot command in a channel, typing a bot command in a DM, or clicking on a reaction. The differences between these methods are shown below.
In order to use the command in channel method, you will need to instruct your users to remove the Unverified role or to add the Verified role to themselves.
Now that we know what to look for when moderating voice channels and how to take some preventative measures, it's time to address the elephant in the room. What do we do when a member of the server reports rule breaking behavior in a voice channel, but no moderator was there to witness it? If we believe them and treat their word as fact, we can take care of the situation accordingly.
While this may work for certain situations, there is the possibility that troublesome users may realize that the moderators are acting on all reports in good faith and begin to try to take advantage of this policy and create false reports. This is obviously very problematic, so let's now consider the opposite scenario. If a moderation team doesn't believe any of the reports and moderate situations only when a moderator is present, it's likely that the troublesome user can keep getting away with their rule breaking behavior. In some cases, even if a moderator is available to join a voice channel when they receive a report, they might find that the troublesome user stops their behavior when the moderator joins, thus making it impossible to verify the report. This can be partially mitigated by moderators using alternate accounts to join the voice channel and appear as a user, but ultimately there will be situations where mods aren't available and reports will need to be considered.
In general, any singular report should not be believed based on the report alone. When a user reports a situation in a voice channel, the following questions should be asked:
Active users who make many legitimate reports can likely be trusted. The more legitimate reports a user has made, the more likely it is that they can be trusted. Even if a trusted user makes a false report at some point, it is often easy to undo any false actions taken.
Positive contributions in your server (such as quality conversations or being welcoming and supportive of other server members) is also a way that members might gain trust. This trust is something that can be handled the same way you handle trust gained from legitimate reports.
If multiple users report the same issue, and you know they are not connected, the report can safely be trusted as long as the information in the reports are consistent with each other. Knowing when users are connected can be difficult in some cases, but some signs you can look for are: users who joined the server at the same time, users with IDs close to each other (signifying similar account creation times), similar behavior or patterns of talking, or interactions with each other which signify the users know each other from somewhere else. It is important to ensure that this isn’t an organized effort from a group of friends or alternate accounts targeting another user.
There are many things you can look at when examining the user being reported. Some things to look out for are offensive or inappropriate usernames, profile pictures, or statuses, and any inappropriate messages sent by the user in the past. Inappropriate messaging can be anything from spam to rude or offensive behavior or even odd or confusing behavior.
If the answers to these questions leads to more skepticism and questioning of the legitimacy of the report, then it may be the case that the report can't be trusted. If you are not confident in the report's legitimacy, you should still make a note of the report, in case similar reports are made in the future. Repeated reports are one of the most common ways to discover that a report is likely legitimate and allow you to make a better informed decision later on. It may also be the case that the answer to these questions reveals that the report is likely illegitimate, in which case you may punish the reporter(s) accordingly. Intentional false reporting is a breach of trust with a moderation team, but reports made in good faith that are unactionable should not result in punishment.
Markdown is also supported in an embed. Here is an image to showcase an example of these properties:
Example image to showcase the elements of an embed
An important thing to note is that embeds also have their limitations, which are set by the API. Here are some of the most important ones you need to know:
An important thing to note is that embeds also have their limitations, which are set by the API. Here are some of the most important ones you need to know:
If you feel like experimenting even further you should take a look at the full list of limitations provided by Discord here.
It’s very important to keep in mind that when you are writing an embed, it should be in JSON format. Some bots even provide an embed visualizer within their dashboards. You can also use this embed visualizer tool which provides visualization for bot and webhook embeds.
Occasionally, you might find yourself faced with a difficult, time sensitive situation where someone is at risk of being harmed, or harming themselves. Because nothing is recorded in voice channels, it is not possible to report these types of situations to Discord. If you witness situations such as these, or if you receive reports of them, you should reach out to those involved in DMs or a text channel in the server. You can also attempt to dissolve the situation in the voice channel if you are confident in your abilities to do so, but it may be harder to get the authorities involved if it is necessary if there is no evidence of the situation in a DM or text channel. Once you have done that, follow the steps in DMA article 104 to report the user(s) to Discord. Whether or not you are able to move the situation to a DM or text channel, call your local authorities if you believe someone is in imminent danger. If you know the area where the person in danger lives, you may also want to call the authorities in their area.
Handling situations in voice channels can be difficult, but with the right tools and protocols in place, your servers’ moderation team can be prepared for anything. After reading this article, you should have a good understanding of when voice moderation is needed, and how to properly enact voice moderation scenarios. This article outlined some of the most common situations that you should look out for, as well as how to prepare for some situations proactively. It also showed how you can handle user reports in a way that minimizes the possibility of actioning false reports. Finally, you learned how to handle severe, time-sensitive situations, where someones’ life may be in danger. There's a lot to consider when you're moderating voice channels, but by following these tips, you should be well equipped to moderate voice channels in your server!
Even though this comparison is important for better understanding of both bots and webhooks, it does not mean you should limit yourself to only picking one or the other. Sometimes, bots and webhooks work their best when working together. It’s not uncommon for bots to use webhooks for logging purposes or to distinguish notable messages with a custom avatar and name for that message. Both tools are essential for a server to function properly and make for a powerful combination.
*Unconfigurable filters, these will catch all instances of the trigger, regardless of whether they’re spammed or a single instance
**Gaius also offers an additional NSFW filter as well as standard image spam filtering
***YAGPDB offers link verification via google, anything flagged as unsafe can be removed
****Giselle combines Fast Messages and Repeated Text into one filter
Anti-Spam is integral to running a large private server, or a public server. Spam, by definition, is irrelevant or unsolicited messages. This covers a wide base of things on Discord, there are multiple types of spam a user can engage in. The common forms are listed in the table above. The most common forms of spam are also very typical of raids, those being Fast Messages and Repeated Text. The nature of spam can vary greatly but the vast majority of instances involve a user or users sending lots of messages with the same contents with the intent of disrupting your server.
There are subsets of this spam that many anti-spam filters will be able to catch. If any of the following: Mentions, Links, Invites, Emoji, and Newline Text are spammed repeatedly in one message or spammed repeatedly across several messages, they will provoke most Repeated Text and Fast Messages filters appropriately. Subset filters are still a good thing for your anti-spam filter to contain as you may wish to punish more or less harshly depending on the spam. Namely, Emoji and Links may warrant separate punishments. Spamming 10 links in a single message is inherently worse than having 10 emoji in a message.
Anti-spam will only act on these things contextually, usually in an X in Y fashion where if a user sends, for example, 10 links in 5 seconds, they will be punished to some degree. This could be 10 links in one message, or 1 link in 10 messages. In this respect, some anti-spam filters can act simultaneously as Fast Messages and Repeated Text filters.
Sometimes, spam may happen too quickly for a bot to catch up. There are rate limits in place to stop bots from harming servers that can prevent deletion of individual messages if those messages are being sent too quickly. This can often happen in raids. As such, Fast Messages filters should prevent offenders from sending messages; this can be done via a mute, kick or ban. If you want to protect your server from raids, please read on to the Anti-Raid section of this article.
Text Filters
Text filters allow you to control the types of words and/or links that people are allowed to put in your server. Different bots will provide various ways to filter these things, keeping your chat nice and clean.
*Defaults to banning ALL links
**YAGPDB offers link verification via google, anything flagged as unsafe can be removed
***Setting a catch-all filter with carl will prevent link-specific spam detection
A text filter is integral to a well moderated server. It’s strongly, strongly recommended you use a bot that can filter text based on a blacklist. A Banned words filter can catch links and invites provided http:// and https:// are added to the word blacklist (for all links) or specific full site URLs to block individual websites. In addition, discord.gg can be added to a blacklist to block ALL Discord invites.
A Banned Words filter is integral to running a public server, especially if it’s a Partnered, Community or Verified server, as this level of auto moderation is highly recommended for the server to adhere to the additional guidelines attached to it. Before configuring a filter, it’s a good idea to work out what is and isn’t ok to say in your server, regardless of context. For example, racial slurs are generally unacceptable in almost all servers, regardless of context. Banned word filters often won’t account for context, with an explicit blacklist. For this reason, it’s also important a robust filter also contains whitelisting options. For example, if you add the slur ‘nig’ to your filter and someone mentions the country ‘Nigeria’ they could get in trouble for using an otherwise acceptable word.
Filter immunity may also be important to your server, as there may be individuals who need to discuss the use of banned words, namely members of a moderation team. There may also be channels that allow the usage of otherwise banned words. For example, a serious channel dedicated to discussion of real world issues may require discussions about slurs or other demeaning language, in this exception channel based Immunity is integral to allowing those conversations.
Link filtering is important to servers where sharing links in ‘general’ chats isn’t allowed, or where there are specific channels for sharing such things. This can allow a server to remove links with an appropriate reprimand without treating a transgression with the same severity as they would a user sending a racial slur.
Whitelisting/Blacklisting and templates for links are also a good idea to have. While many servers will use catch-all filters to make sure links stay in specific channels, some links will always be malicious. As such, being able to filter specific links is a good feature, with preset filters (Like the google filter provided by YAGPDB) coming in very handy for protecting your user base without intricate setup however, it is recommended you do configure a custom filter to ensure specific slurs, words etc. that break the rules of your server, aren’t being said.
Invite filtering is equally important in large or public servers where users will attempt to raid, scam or otherwise assault your server with links with the intention of manipulating your user base to join or where unsolicited self-promotion is potentially fruitful. Filtering allows these invites to be recognized, and dealt with more harshly. Some bots may also allow by-server white/blacklisting allowing you to control which servers are ok to share invites to, and which aren’t. A good example of invite filtering usage would be something like a partners channel, where invites to other, closely linked, servers are shared. These servers should be added to an invite whitelist to prevent their deletion.
Anti-Raid
Raids, as defined earlier in this article, are mass-joins of users (often selfbots) with the intent of damaging your server. There are a few methods available to you in order for you to protect your community from this behavior. One method involves gating your server with verification appropriately, as discussed in DMA 301.You can also supplement or supplant the need for verification by using a bot that can detect and/or prevent damage from raids.
*Unconfigurable, triggers raid prevention based on user joins & damage prevention based on humanly impossible user activity. Will not automatically trigger on the free version of the bot.
Raid detection means a bot can detect the large number of users joining that’s typical of a raid, usually in an X in Y format. This feature is usually chained with Raid Prevention or Damage Prevention to prevent the detected raid from being effective, wherein raiding users will typically spam channels with unsavoury messages.
Raid-user detection is a system designed to detect users who are likely to be participating in a raid independently of the quantity of frequency of new user joins. These systems typically look for users that were created recently or have no profile picture, among other triggers depending on how elaborate the system is.
Raid prevention stops a raid from happening, either by Raid detection or Raid-user detection. These countermeasures stop participants of a raid specifically from harming your server by preventing raiding users from accessing your server in the first place, such as through kicks, bans, or mutes of the users that triggered the detection.
Damage prevention stops raiding users from causing any disruption via spam to your server by closing off certain aspects of it either from all new users, or from everyone. These functions usually prevent messages from being sent or read in public channels that new users will have access to. This differs from Raid Prevention as it doesn’t specifically target or remove new users on the server.
Raid anti-spam is an anti spam system robust enough to prevent raiding users’ messages from disrupting channels via the typical spam found in a raid. For an anti-spam system to fit this dynamic, it should be able to prevent Fast Messages and Repeated Text. This is a subset of Damage Prevention.
Raid cleanup commands are typically mass-message removal commands to clean up channels affected by spam as part of a raid, often aliased to ‘Purge’ or ‘Prune’.It should be noted that Discord features built-in raid and user bot detection, which is rather effective at preventing raids as or before they happen. If you are logging member joins and leaves, you can infer that Discord has taken action against shady accounts if the time difference between the join and the leave times is extremely small (such as between 0-5 seconds). However, you shouldn’t rely solely on these systems if you run a large or public server.
User Filters
Messages aren’t the only way potential evildoers can present unsavoury content to your server. They can also manipulate their Discord username or Nickname to cause trouble. There are a few different ways a username can be abusive and different bots offer different filters to prevent this.
*Gaius can apply same blacklist/whitelist to names as messages or only filter based on items in the blacklist tagged %name
**YAGPDB can use configured word-list filters OR a regex filter
Username filtering is less important than other forms of auto moderation, when choosing which bot(s) to use for your auto moderation needs, this should typically be considered last, since users with unsavory usernames can just be nicknamed in order to hide their actual username.
One additional component not included in the table is the effects of implementing a verification gate. The ramifications of a verification gate are difficult to quantify and not easily summarized. Verification gates make it harder for people to join in the conversation of your server, but in exchange help protect your community from trolls, spam bots, those unable to read your server’s language, or other low intent users. This can make administration and moderation of your server much easier. You’ll also see that the percent of people that visit more than 3 channels increases as they explore the server and follow verification instructions, and that percent talked may increase if people need to type a verification command.
However, in exchange you can expect to see server leaves increase. In addition, total engagement on your other channels may grow at a slower pace. User retention will decrease as well. Furthermore, this will complicate the interpretation of your welcome screen metrics, as the welcome screen will need to be used to help people primarily follow the verification process as opposed to visiting many channels in your server. There is also no guarantee that people who send a message after clicking to read the verification instructions successfully verified. In order to measure the efficacy of your verification system, you may need to use a custom solution to measure the proportion of people that pass or fail verification.
.svg)
.png)
.svg)
.svg){kind=icon}
.svg)