More control and feedback for bot and applications.commands scopes

[ckohen]

Description

This is a multi-faceted suggestion with a few different parts.

OAuth / scope grant: Add more control over required scopes, similar to the current Require OAuth code flow toggle.
HTTP based interactions: Add a callback event for when the application is added to a guild with the applications.commands scope
Gateway connected applications:

• Add a new event for when the application is added to a guild with only applications.commands (possibly emit this event on identify like GUILD_CREATE)
• Add a with_application_commands (or similar) property to the GUILD_CREATE event that tells a bot whether it has applications.commands in the guild

Why This is Needed

OAuth / scope grant

Currently there are a few different ways to go through the authorization process for an application with a bot and slash commands.

• With bot and applications.commands
• With only bot
• With only applications.commands

Depending on how your application is developed, you may want it to be only possible to add both to prevent situations where you need to tell your user to add the bot or add the applications.commands scope when they run commands.

HTTP based interactions

Currently the only data you get via HTTP interactions is interaction events. This obviously works great except for one small problem. When your commands are added, you have no way of knowing this. While that doesn't cause many issues, it many cases it may be helpful to have the data on roles / owner when being added, not to mention just having the guild id.

Reasons for needing this information include having default_permision: false on a command simply because you do not want it to be useable in DM's, therefore needing the guild id to be able to add permissions for the everyone role to true. To further stretch this, some commands may be default_permission: false because they are potentially dangerous, and therefore setting them to only be useable by roles that have admin, or only owner etc... would be useful, without a config command that is always open.

Gateway connected applications

Similar reasoning for the new event type as with HTTP interactions

For the GUILD_CREATE event, this prevents an extra call to fetch guild commands simply for the purpose of determining access. Again this allows developers to set up permissions when the bot is added.

Alternatives Considered

Manually determining if the bot / commands are added for a guild via API calls that are expected to error.

Setting up permissions the first time any command in the guild is run and / or use a /config or similar command.

Additional Details

For applications that run gateway and HTTP, this prevents some of the need (if there was) for inter-communication as well.

[tjrgg]

I fully agree with the points regarding scope grant and would appreciate being able to have more control regarding how bots can be added to guilds and what scopes they need to have.

For future bots I create, I intend for most of them to require both the applications.commands and bot scopes so commands operate via the Slash Commands feature exclusively. For this reason, I would like to see some kind of option in the developer portal where I could tell Discord that a bot user for an application should not be added to a guild unless the end user has authorized both the applications.commands and bot scopes, if my application so requires.