Bot Permissions/Roles

[tgoins]

The bot needs a better permission system than relying on Discord roles/permissions.

For example, the bot uses Discord's ban permission to detect if the user can ban someone else, but allows users to ban people that are higher ranked than them or the same rank.

Need to create our own roles that use our own permissions.

This will allow us to complete control over who can do what with the bot.

Most roles will be tied to a guild, as the guild admins will assign the bot roles to its users.

Some roles may be global, like Owner will be a global role for the bot owner.

Each role will have a subset of permissions. Every permission will give access to a small piece of the bot.

[brandonbothell]

I understand the bot having its own roles/perms for development/support purposes, but I think when it comes to banning, kicking, etc. users the bot should just do it the way Discord does it. For example, if the user banning's highest role is less-than or equal-to the highest role the user being banned has, then they can't ban them.

[tgoins]

For many of the bot's commands, Discord's role system will work fine. Moderation features may only need to use the built-in roles, if I'm able to figure out how to prevent taking action on users that have the same or higher role.

There are several reasons, however, that led me to prefer a separate role/permission based system. For instance, with moderation, you may not want moderators to be able to kick staff members that have a lower role than them.

For example, say you have a Discord role structure like:

• Owner
• Admin
• Moderator
• Helper
• Member

You would probably want the moderators to be able to kick members, but not helpers. Discord's role system is very linear, which makes this idea impossible, unless you put helpers above moderators, which also doesnt make sense.

The idea for my role/permission system would fix this. It would replace Discord's linear roles with an advanced hierarchical role system. This system would allow roles to be on the same "level" as other roles rather than being above or below another role. It would also allow permissions to be bypassed for individual users.

Another big reason I intend to use a separate system is for API route authorization, if I deem this as a needed feature. This would allow me to be 100% sure that the request is valid and coming from a trusted user, at the API level. Specifically, I think it will be important once the web interface is functional, since it will allow the user to update their information and interact with their data. I want to prevent them from updating other users data, calling endpoints like ban, or viewing things I dont want them to view. I think it will be needed, because when a user accesses the web interface, they will be given an apiToken in the background, individualized to that users Discord and bot user, which specifies what that user can do. That token will temporarily allow them to make API requests if they find it, thats how the web interface is authorized to use the API.

I also want to use roles to allow server owners to specify who can use what bot commands, and where each bot command can be ran. Again, Discord does not let you say where a user can run bot commands, because Discord does not know what messages are bot commands.

The goal is to allow things like:

• Specify who can use music commands and what channels they can be used in.
• Allow only a specific command group to be used in a channel
• Allow certain roles to bypass the command restrictions
• Allow commands to be given and revoked per individual (if a user is abusing a command, instead of kicking them, demoting them, or taking a command group away from them, you may want to just take that specific command away)

Discord's role system is not capable of any of those things. Many people, myself included, gripe about these limitations often. The feature would solve an actual problem with Discord's role architecture.

A business may have a development team and a marketing team. Is one of those teams greater than the other? No. You cannot represent this in Discord roles. My role architecture would be designed to fix this, which would make my bot useful not only for normal servers and gaming servers, but it would be beneficial to businesses who decide to use Discord, because it would allow them to represent their corporate employee structure correctly.

If you remember when we worked on that Minecraft server, I had set up a role for each team, and each team had a leader who managed the members of that team. Although the teams were conceptually equal, I could not represent that in Discord. I had to place teams above others. This prevented me from giving team leaders permission to promote/demote/kick members of their team directly; instead, those actions had to be cleared by me.

My role system would fix that.

Let's back up for a moment..

Could I potentially tightly couple my bot to Discord and rely only on Discord's role system?
Yes, of course.
However, Discord's role system is for controlling access to Discord's features. My bot is not a Discord feature, and therefore would have some issues making everything work solely using the built-in permission system.

It may be worse off on the user-experience side to abstract the bot's permission system, but I don't view the bot as a part of Discord. I consider the project to be providing a "Service" in which I am interfacing heavily into Discord. The API and the web interface are completely separate entities from Discord. The bot interfaces between Discord and the other applications. The project is designed to be a commercial product, not a helper library that just adds a few commands to a server. For this reason, I want to keep features as loosely coupled as possible to Discord when I can. Small features, like rock paper scissors, would of course be tightly coupled because it only uses Discord and wouldnt be useful for the web interface or api, but features like the level system need to be abstract that way they can be accessed outside of Discord, and give me the possibility of allowing users to interact with the Service using other platforms like Twitter. In theory, everything is abstracted enough to where I should be able to interface the Service to Twitter, Reddit, etc fairly easily.

Right now the web interface would use Discord for authentication. If I interface my Service to other applications, then I could those applications to authenticate the user as well, and all authentication methods would give the user the same data --- their Discord, Twitter, Reddit, etc accounts would be tied to each other basically.

If I want to take it that far, I would need a separate permission system, no doubt.