Allow interaction tokens to inherit external emoji permissions

[muddyfish]

Description

Allow interaction tokens to inherit external emoji permissions from either the everyone role or the bot permissions, whichever is more permissive.

Why This is Needed

Currently, when sending a response to a slash command, assuming you also have a regular bot in the channel, you have two ways of responding to that command (ignoring any manage webhooks you may have as that probably won't change the outcome too much).

1. Using the interaction token
2. Using the regular send message endpoint with your bot token

The interaction token and your bot can have a different set of permissions, which makes it complicated to work out which is the best choice to use if you want to send a given message without hitting a 403.

Interaction tokens have:

• @everyone permissions
• TTS if you so want it
• Multiple embeds; and always embed links
• The usage of external emojis hooked up to the everyone role

Bot tokens have:

• Whatever permissions you have set on your bot in the current channel

You want to use bot tokens when:

• The everyone role doesn't have external emojis in the current channel and you're using an external emoji.

You want to use interaction tokens when:

• Literally every other case; that's the only permission you might care about

This makes choosing which token to use rather difficult; in order to choose you need the following information:

• Does the everyone role have 'use external emojis' in this channel? Whilst not too awful to calculate, it's a little annoying and requires caching which slash commands otherwise let you get away with without in most cases.
• If not, does the message I'm sending include external emoji anywhere, including the content and any embeds you might wish to send
  • This implies that you need to run a regex over the message content as well as all embeds where emojis might render, extract their ids and then see if they're in the current guild. This implies yet more caching as well as some pretty complex code just for a permissions check.
  • If there is an external emoji, then you need to decide which set of permissions you'd prefer; your bot token might not have 'embed links' but that might be preferable to external emojis not working

Alternatives Considered

• Choosing one over the other by hand
• Making interaction tokens inherit from the bot permissions if the bot is there so there's no alternate set of permissions to choose from. Give a default set when the bot is not present.

Additional Details

This is really inconvenient to compute, and as you can hopefully tell, really non-obvious to consider when explaining. Most users are probably unaware that external emojis are linked to the everyone role and even if they are, it takes a lot of thinking to decide what should be done.

In the worst case, you have to choose which of a disjoint set of permissions you'd prefer to use for a given command, which is pretty bad from a usability standpoint; I'd prefer it if there was always a 'best choice' you could make or make said choice not matter.

[erkinalp]

allow interaction tokens to inherit external emoji permissions from either the everyone role or the bot permissions, whichever is more permissive.

s/more/less/

[ckohen]

I'd like to add on to this maybe the possibility to have a separate toggle for slash command responses (per integration would be nice, but as a general thing would be fine).
It may be desirable to have an integration with application commands where most people do not have a role and external emojis disabled. This would make it a requirement to add the bot to the server just to override its permissions to use external emojis.

[DaStormer]

Any update on this?

This will be especially significant in light of the upcoming message content access deprecation since bots and users would actively use slash commands/interactions. Users would expect external emojis to work if the bot has the permission as that's the logical assumption.

[Alex1304]

I second this. I just completed the migration of my bot to slash commands, and currently I have to tell my users to enable external emojis for the everyone role for some of the replies to display properly. Really annoying...

[LukeHankey]

Adding onto this, you are currently unable to mention roles via interactions without having the @everyone role have the Mention @everyone, @here and all roles permission enabled which for obvious reasons is not ideal to have enabled.

[UltimateSppy765]

No, interaction responses can ping any role/@everyone/@here, which is controlled by the allowed_mentions field. Discord had disabled role, @everyone and @here mentions by default (meaning that by deafult these will depend upon if the @everyone role has the permissions to ping any role or not) because of this being exploited in raids. You can enable those in the allowed_mentions object if you wish to.

[LukeHankey]

No, interaction responses can ping any role/@everyone/@here, which is controlled by the allowed_mentions field. Discord had disabled role, @everyone and @here mentions by default (meaning that by deafult these will depend upon if the @everyone role has the permissions to ping any role or not) because of this being exploited in raids. You can enable those in the allowed_mentions object if you wish to.

Even with the allowed_mentions object, interaction responses don't ping roles. I've tried and tested this without success. This does work for message responses, but not for interaction responses.

[elderlabs]

Has there been any progress towards a resolution? Interaction Responses should inherit all non-destructive permissions from their bot's integration role (rather, they should have the perms of the bot/integration's role, otherwise default to @everyone if the bot isn't in the guild). Not having the ability to issue responses containing emotes or proper mentions breaks functionality that exists in the message replies to non-integration commands.

With the deadline still months away, but rapidly approaching, I'd like to release slash commands to my users long before the cutoff window. I cannot do that as things currently stand. Slash commands have come far from their initial introduction, but there's still a fairly decent amount of polish needed API-side before we can remotely consider the approaching cutoff date, otherwise countless toes will be left trampled.

Thanks.

[asrvd]

This needs to be fixed actually, for small bots it may not be a problem, but for bots which are in a large number of servers, there would definitely be issues because you can't expect each server to have send external emoji perms enabled for @everyone role.

[EasyXploit]

Of course. There are many guilds that restrict the possibility of using external emojis only for active people (as a reward for participating), for example. Having to use unicode emojis on servers that don't have that permission enabled makes app design unnecessarily inconsistent.

[mr-tech]

I'd take this a step further and say that messages posted as a response to interactions should be able to use all emojis like components can. This would make the expectation / behavior consistent within the ecosystem that is application commands.

Additionally, interactions already ignore most permissions (View Channel, Send Messages, Attach Files, and Embed Links to name some of the big ones), whether by design or side-effect, so it's odd that this is one of the few things that are still enforced.

[elderlabs]

I don't see why interactions aren't allowed the same perms assigned to the integration's built-in role. Given it's been months, I don't see this going anywhere, sadly, as with most other features on the platform these days.

[kingmigdor]

This is actually a good idea. Also sometimes there are user-defined emojis that bots should use, and not everyone wants to invite the bot to that server.

[msciotti]

This feature has been merged and deployed.

If an interaction is owned by an application with a bot in the server, the interaction will respect the bot's permissions for MENTION_EVERYONE, USE_EXTERNAL_EMOJI, and SEND_TTS_MESSAGES.

The same is true for webhooks created/owned by bots in the server.

Interactions owned by an application without a bot in the server will continue to respect @everyone for those permissions.

[elderlabs]

Thank you, Mason!

Now for the numbers, Mason, what do they mean