digitalpulsesoftware / notabot Goto Github PK

Hi,

We are using Not a Bot on our server with quite some success, the recent spam module is an handy addition. From time to time, there are false-positives and a legit member gets wrongly auto-muted; e.g. a member sending multiple pastebin-like links, one per file he is working on, to ask for assistance. The logged message "<@x> had been auto-mute because of spam in <#y>" is very nice because it gives us the opportunity to look at the logs and verify which message triggered the auto-mute, then our policy is either kick the spammer or unmute the unfortunate member.

Because we are moderating a quite busy server (10k+ members), our logs are quite dense and it is not always easy to determine which message triggered the auto-mute. My suggestion is to add the message that triggered the auto-mute (the one whose score exceeded the configured threshold, if it is easy to do) in the logs to ease our job. Maybe there could be an unmute button next to the message.

Regards,

Cette issue n'est pas une RFC, néanmoins je vais essayer de décrire de la manière la plus succincte ce que je vois pour l'api.

Pour la structure de l'api, je pense à quelque chose du genre avec l'ensemble des actions possibles :

• https://notabot.fr/api/v1/guild/323076998576603137 : Permet de récupérer les informations d'une guild (serveur)

J'imagine aussi la possibilité de filtrer certains champs, comme avoir un paramètre GET afin de récupérer une seule information par exemple :

https://notabot.fr/api/v1/guild/323076998576603137?fields=memberCount,description

Certaines informations ne sont accessibles qu'a des personnes ayant des permissions particulières. Je propose donc cette approche pour l'authentification :

1. Connexion OAuth 2 avec Discord (afin de récupérer un token d'autorisation et l'identifiant de l'utilisateur)
2. L'utilisateur effectue une requête pour modifier un rôle sur le serveur par exemple, il passe en paramètre le token d'autorisation
3. L'api va vérifier au prêt du serveur si l'utilisateur est bien sur le serveur, et s'il possède les droits nécessaires pour effectuer l'action
4. Si c'est le cas, le serveur modifie bien le rôle et renvoie une réponse 200. Le cas échéant, il renvoie une 401 / 403

Il serait aussi bien de pouvoir de désactiver l'accès au serveur depuis l'api, pour x / y raisons. Ou au moins avoir un contrôle avancé concernant les permissions.

Concernant les informations globales du bot, je pense aux possibilités suivantes :

• https://notabot.fr/api/v1/guilds : Retourne les serveurs sur lequel est le bot
• https://notabot.fr/api/v1/guild/323076998576603137/stats : Retourne les statistiques d'un serveur
• https://notabot.fr/api/v1/guild/323076998576603137/channels?type=TextChannel : Récupère les canaux textes d'un serveur
• https://notabot.fr/api/v1/about : Retourne les informations du bot, comme le fait s'il est en ligne, sa présence, ect...

Je mets en évidence le fait que c'est un exemple, l'idée est (au début) surtout d'avoir une API qui permet de récupérer des informations basiques.

Moi, je voudrais par exemple communiquer avec l'api pour faire des statistiques.
C'est impossible de proposer une API complète dés le début, donc il faut y aller step par step.

📝 Proposal:

Add a softban feature that consists to ban a member and delete all his messages, and unban it directly after.
This could be useful in case of compromised accounts spamming advertisement where you want all the messages of the user deleted (in the last 24h for example), and don't want the user to stay banned (for him to be able to join back when he gets his account back).

When registering a command with !addreply, we shoud be able to have an option forward ping or message reply from trigger.

Example:

It would be nice to have the bot answering directly to the answered message ("Test") if needed as an option

KEEP ME OPEN

This issue is for tracking when the spam-submodule wrongly muted a member (false-positive) and when it didn't muted a spam (false-negative). Each entry in this issue serves as database for future updates of the spam-submodule, such updates should reference the entries in this issue but should not close the issue.

In the process to stop using Dyno on "Not a name" server, we will need this command to be added in Not A Bot.

prune X command is used to remove last X messages in the current channel. It should remove the command message as well (but not counted in the X counter.

What

The goal is to have a way to bind single-word commands to text blocks.

As an example, the !ask s-w command would make the bot print the following
text block.

"To maximise your chances at getting an answer, you should..."

Why

On help-oriented servers and channels, there are a lot of cases where the
"helpers" may need to regularly repeat the same messages, e.g. "give some info".

On a more "general" case, this can be used as a rule reminder, info. block, etc.

How

P1: A simple key-based message posting

The basics

Existing NaB modules are triggered based on a word.

In this case, the module may have a lot of words, and the same behaviour on
each trigger.

To avoid loading a lot of redundant instances of the same module, we should
develop a module that'd be triggered on every message, and post the right
message if needed.

Message storing and loading

A message is associated to its trigger word, its "key".

The most primitive implementation of such a feature would be to have a folder,
each file being named after the key.

The simplest way to name the file would be to only put the key.
Making extensions optional could simplify integration, but slow
down the module for "not in cache" keys.

On trigger, the bot would then load the message found inside the file, before
posting it on Discord.

Simple optimizations to do to avoid high disk IO/latency would be:

• On startup, make the bot scan the folder supposedly containing messages, and
  keep the list of found files in a "key" cache.
• On file read (command trigger with an existing associated message), keep the
  message content in cache along the key.

The base naïve algorithm then becomes:

On incoming message
// Taking the first item, removing the trigger character
key := split(message, " ", 2)[0][1:]
if key in loaded_messages then
	send(channel, loaded_messages[key])
// startup analysis, and FS check
else if key in found_keys or exists(key)
	loaded_messages[key] = load(key)
	send(channel, loaded_messages[key])
else pass

P2: Let the users remove bot-posted messages

Allowing the users to remove the messages the bot posted after being triggered
may help with self-moderation, spam avoidance (letting the users react to
a trigger spammer), or just to let them clear the chat once the message
have been read.

This could be done by allowing the user react on the message by adding a given
emoji reaction, which would remove the bot message.

Still, a naïve implementation of this feature may make the bot remove other
messages it posted, that aren't in the scope of this module.

For that, either the message should contain a flag to recognize it without
any bot-side cache (e.g. starting the message with a known keyword),
or the bot should keep a list of every answer it posted (message ID).

To avoid growing memory consumption, expiration would be required on the time
users have to remove the message.

The cache could be either in the NaB code (with a garbage-collector running
to reap every expired message watch) or in some specialized cache servers, like
Redis, which natively supports expiration on keys.

Add !addalias command to add an alias to a !addreply answer to prevent duplicating commands.
And !editreply to change behavior of a reply for a command and its aliases

Example:

!addreply !test My answer
!addalias !foo !test

!foo

My answer

!editreply !test My **amazing** answer
!foo

My amazing answer

I think a documentation can be good for this bot because, i'm noob you know and it's so difficult for me to understand how to setup the bot. I know you have a discord server for this project but i think a doc can be better x)

Add all unknown members to last activity list on plugin enabling, and set date as "now"

In order to avoid this kind of false positive, I think we should add a whitelist domain list (maybe hardcode it in the module code, it doesn't matter) containing discord.com.

It is annoying that multiple bots are using the same ! as prefix. There are places where NaB was added just for a very few modules and the admins wanted to replace ! by something else for NaB.

I'm suggesting to make it configurable and to add another hard-coded prefix. If the first word is a mention to the bot, it could be considered as a prefix i.e. you could do @notabot enable raid

!purgeKick for example

for as many commands as possible, add the support of Discord's slash commands. But, i suggest to not directly drop the prefix support

idk if discordia support by default slash commands, but community modules exist ([discordia-slash]https://github.com/GitSparTV/discordia-slash for example)

Le bot étant composé d'énormément de commandes, je pense qu'il serait préférable d'ajouter un exemple de comment utiliser une commande.
Lorsque la commande !config est faite, on obtient la liste de configurations et je pense qu'un exemple en dessous de chaque élément configurable serait nécessaire pour éviter de devoir sans arrêt demander de l'aide sur le discord.
Je dis pas que c'est une mauvaise chose de demander de l'aide, mais pour des insomniaques comme moi, parfois on peut demander de l'aide très tardivement et ne pas avoir de réponse...
Sinon bot toujours aussi clean, je recommande

In the process to stop using Dyno on "Not a name" server, we will need these features to be added in Not A Bot.

The current logs module is used to log deleted messages from channels. We also need to log username changes and channel (and if possible Threads) creation/deletion to make moderation task easier.

Hello, je viens faire une proposition de modification (majeure) pour NaB :
Mon idée serait de réécrire NaB, avec une librairie plus ''connue'' ou plutôt ayant une plus grosse communauté. Vous me direz sûrement que c'est une idée inutile (et c'est sûrement le cas), j'ai donc pesé le pour et le contre des deux librairies qui sont le plus adaptées pour un tel travail de réécriture selon moi, ainsi que pour la possibilité de rester avec discordia.

Voilà ce que j'en ai conclu, j'attends vos avis pour savoir si c'est une énième folie de ma part ou bien si je suis un génie du 21ème siècle.

Il serait intéressant de gérer le temps d'attente entre chaque annonce de stream par streamer et par serveur, au lieu qu'il s'agisse d'un paramètre global.

In the process to stop using Dyno on "Not a name" server, we will need this command to be added in Not A Bot.

userinfo log as many as possible information about the current user. Example:

If some more information are available and useful in a moderating context, they can be added to the embed as well.

I see this in a kubernetes@home discord :

Its simple 2 locked audio channels with the name updated every hours ...

When I use !userinfo, I'm interested in knowing when the user account was created and when did he join the server. When it is an user that has joined the server several months/years ago, I'm interested in knowing when the user was most active and in which channel.

What would be great is to see an activity graph, an image that show its activity grouped by month.

Example, in the image below, we see that the member was most active around September 2021

Then the bot should also logs the 3 channels the user posted the most and how many messages each time.

The bot read-the-bin is a bot that scan messages to find long snippet of codes, i.e. 12+ lines of markdown code-blocks. When such a message is found, it automatically uploads the content of the message to https://bin.readthedocs.fr, my own pastebin-like website. The objective of this bot is to prevent users from posting code that would take the entire screen.

The read-the-bin bot is not always available and its development staled. We suggest to re-implement it our way inside of not-a-bot.

✅ Expected Behaviour:

The permissions of the moderator are checked before each action to ensure he is allowed to do the specified action (like ban, mute, open tickets, etc.)

⚠️ Actual Behaviour:

Any member with an access to the channel that clicks on an interaction can ban, mute, etc. without any permission check

📝 Proposal:

Add a permission check to see if the member/moderator clicking is allowed to execute the specific action.