Mute functionality and Storing them between sessions

[zaida04]

Is your feature request related to a problem? Please describe.
A popular question asked in the Support Server is on the topic of mutes, and in addition, how to keep them persistent between restarts.

Describe the solution you'd like
A page for setting up a muted role, and a separate page for storing the mute timeouts persistently. The storing of the data would be handled by Sequelize.

Additional notes
This is more of me just asking for approval before I go ahead and make a PR.

[kernel-dev]

I personally think that this would be a great addition to the guide.
👍

[almostSouji]

There are a few reasons that make me hesitant about this request:

Creating the role

Setting up a muted role is not really a thing a bot should do automatically. Servers permission systems can be very very sensitive to these kind of features.

A lot of servers use roles to manage access to writing in certain channels (think special games/team other opt-in channels, that are viewable by everyone). Setting up an automated mute role will either...

1. ... not work at all (if any role has the explicit permission enabled in an overwrite only a personal overwrite can deny it, not the denying of the permissions for any other role - your mute role included)
2. ... completely destroy the servers permission setup (if you remove said conflicting overwrites)
3. ... potentially be very API spammy (personal overwrites per user on every channel)
4. ... remove functionality you don't want to be removed (if you remove all roles, save them and re-apply them later)

In conclusion the role should probably be created by server owners, not bot developers (though a lot - and I mean a lot - of bots out there just do it, messing up very carefully crafted permission systems)

A Schedule or timer

While a temporary role looks like it "can't be that hard to do, right?", doing so well and be robust against down time is not an easy or beginner-friendly task whatsoever.

At the very base level you can just assume that your bot has a good amount of uptime and deal with the feature through a base js setTimeout(cb, duration) .setInterval(cb, duration) (not timeout, typo on my end). Now the API has an outage, your bot encounters an unrecoverable error or your host has one of its (maybe rare) moments of down time. The timeout is gone and the target will be muted forever.

To make this robust requires a scheduling system to either be used (node schedule, to name one example) or be implemented (rolling timeout during uptime, which checks the current time against a persistently saved timestamp, resolves the case and removes the role (if the target is still on the server)).

Circumventing mutes (persistence)

A mute is either a personal or role based overwrite on every channel of the server with assignment of said role.

Both of these approaches can very easily be circumvented by leaving and re-joining a server, which will both remove the role as well as personal overwrites (role overwrites will persists as long as the role isn't deleted).

This means to have a functional mute role you will also need a system to persist roles, re-applying them on join which comes with its own considerations and caveats as well.

TL;DR:

Implementing temporary roles (even more so mute roles) is hard to do well and the guide would probably need to cover

• (role creation, good overwrites without destroying present setups, covered (although not exhaustively) in the permissions section of the guide)
• role persistence (database read and write, which we covered in keyv and sequelize examples)
• scheduling
• caveats ("what could go wrong"-section)

Which raises the question if it might be a better idea to cover the missing piece (persistent reminder) and leave the whole mute role feature as a project for people to combine what they learned from different parts of the guide.

[kernel-dev]

I agree entirely with the aforementioned flaws of this proposal.
However, here are a few sections that might provide good solutions/suggestions to the issues present:

What if there's no prepared role?

This one's a bit tedious, as the best solution, or explanation, I can come up with is to create a separate command for creating the mute role itself, and adding the permissions overwrites in every channel. Though, a functionality that could be possibly added is to accept arguments of which channels not to overwrite it in.

So for example,
?create-mute Muted [#channel-123, 123456789012345678]

• Muted - Representing the name of the "muted" role.
• #channel-123 - Representing a channel mention.
• 123456789012345678 - Representing a channel ID.

This shouldn't be too difficult to achieve, though the API spam part is definitely a concern to be raised.
Though, I oppose to the idea of per-user overwrites, as it doesn't seem logical.

However, there is an option to entirely circumvent this and look for a role called muted in the guild, and if it is not found, to simply stop executing.

Or, to have a table(?) dedicated to setting a custom muted role per guild.

What if the user leaves the guild and comes back?

Implementing a system to store the roles upon a member leaving the guild definitely seems intriguing, though it might be bloated.

Which is why a timer, or “sweeper”, would be a good solution for this. The sweeper data would be stored in a database, then populated into a collection upon start-up.

And once they’ve joined, set their roles back and stop the sweeper, and completely remove it from both the collection and database.

How difficult is all of this?

It is most certainly not beginner friendly, as Souji previously mentioned.

Though, if you really destructure each part of the process, it might be quite the topic to learn upon. It teaches you a variety of techniques and ways of achieving “difficult” tasks such, which require persistency.

All in all, it’d be intriguing for the guide to have a more “advanced” section and include this sort of project.

TL;DR

Mute role

• Two viable options:
  • If there isn’t one, simply return. Or have a table to store the “custom” mute role per guild.
  • Have a separate command for creating the role itself and adding the overwrites.

User leaving and coming back after being muted

• Implement system to store roles upon a member leaving the guild
• If so, add timer, or “sweeper”, which would delete the entry from the database.
• Upon the user joining (if the data is still present), give them back their roles, stop the sweeper & delete it from the database.

Difficulty

Due to the difficulty and complexity of a system like this, it’d be best if it were to come with a part of the guide for more, “advanced” features, rather than the basics.

Conclusion

A feature like this will be complex, but a great addition; though not beginner-friendly.

If an “advanced” section of the guide ever is to be made, this feature should definitely be added.

At least in my opinion.

[zaida04]

Hey, thank you both for your time in reading and thinking of solutions. I have some clarifications that are free to be changed by others, but this is what comes to my mind.

Setup of the Muted Role

the muted role itself would be created by the guild owner and such, we would have details on how to properly setup a muted role manually, in order to not mess with any preexisting permissions system. This would also eliminate any risk of API Spam from the bot, instead putting the responsibility on the user. One caveat of this is it might induce people to try and get support for when they fail to setup their muted role correctly. This can be solved with a simple warning that the muted role is their responsibility and a simple checklist for them to go through to ensure they have their muted role work.

Setting the timeouts and keeping them persistent.

The idea would be instead of adding another dependency of some cron package, we could just iterate through the database on startup, and create setTimeouts accordingly. In this case, even if the bot restarts, it will still create a new setTimeout ensuring the user doesn't stay permanently muted. However the easier alternative would obviously just be to add a cron package, and perhaps we could have both on the page, sort of a pick which one you want, as essentially they should be nearly identical in how they work in their supplied functions.

Attempted Circumvention

For keeping the muted role applied even if the person leaves, we can just have a check on the Client#guildMemberAdd event to see if the user is in the database, and if so to reapply the muted role. However this wouldn't be responsible for reapplying all the other roles the user had before leaving and rejoining.

TL;DR

• Setup of a muted role and Permission Overwrites
• How to store the mutes in a database with Sequelize
• How to keep the timeouts persistent by creating all the timeouts on startup through iteration of database
• How to reapply muted role in the event of an attempted circumvention

[iCrawl]

To your 2nd point:

The proper way to handle things would be to not do a timeout of the whole duration, nor use the cron package, but rather set an interval that checks the DB ever 5min or so (so you have a tiny margin of error), that sets a timeout for all mutes that run out in let's say... 10 minutes, or 5 minutes in this case.

[zaida04]

I see, one addition question would be whether to use Client#setInterval and Client#setTimeout to ensure that all intervals and timeouts are cancelling on destruction of the client, since we obviously cannot remove/add roles without a logged in client.

[iCrawl]

Yes you'd obviously use the client methods, correct.

[zaida04]

Alright, then I'll get to work. I'll open a WIP PR shortly.

[almostSouji]

Mute has now been introduced to Discord as a native feature, which includes session persistence. There is no longer a need for elaborate mute setups.