Allow pings in interaction responses without requiring ping permissions from @everyone

[ThetaBird]

Description

A recent change was implemented (but apparently not documented) to discord's API where interaction responses no longer supported @everyone or @ROLE pings unless the @everyone role had the "ping @everyone, @here, all roles" permission. I suggest that this change be reverted.

Why This is Needed

• Bots with applications related to events, giveaways, information updates, announcements, and etc. need to be able to ping certain roles in servers where everyone obviously does not have the permissions to do so.
• Before the change, pings in interaction responses didn't work anyway unless specified in the payload by the developer, so unnecessary pings shouldn't have been a problem to begin with.
• Giving @everyone the permissions to ping everyone just so the interaction responses can do the same is a bad idea for obvious reasons. I don't know why anyone thought setting the new requirement was the right way to prevent bot abuse.
• If a bot has potential for ping abuse, it is more likely than not that the developer did not put enough effort into preventing the abuses from happening. Regardless, making this change affects all bots because of the actions of a few. Instead of locking pings in interaction responses unless @everyone has ping permissions, it is best to just let those bots die off as servers grow tired of poor bot design. Managing whether or not a bot pings a role is an easy task and is disabled by default... why must further restrictions be applied??

Alternatives Considered

Yes, you can send another regular message from the bot that contains the message with the pings that you wanted. However, why should developers settle for this method? It adds unnecessary clutter across all areas, from bot code to extra messages in text channels and inconvenient message order. My interaction responses come in the form of embeds, and since those can't ping anyone, the next best thing is to add regular message content (with the pings in question) to the embed that's being sent as an interaction response.
That way, the role pings and the embed are located in one "big" message that is easy to understand and manage. This recent change makes this method obsolete and forces developers to send more payloads/messages than needed. It's an unnecessary change that results in more inconvenience and no increase in security or developer accountability.

Additional Details

It's the developers' responsibility to ensure that only the proper pings are made. Before the change, this was an easy task that yielded convenient results. It seems overkill to completely shut down this functionality unless everyone in the server has permission to ping all roles. If a bot has poor design and is susceptible to ping abuse, it should be up to the developer to fix the issue or up to the server to remove the bot entirely. This alternative promotes responsibility from the developers to deliver better products to the community.

[ThetaBird]

I appreciate the thumb downs, why am I wrong?

[TwilightZebby]

A recent change was implemented (but apparently not documented) to discord's API where interaction responses no longer supported @everyone or @ROLE pings unless the @everyone role had the "ping @everyone, @here, all roles" permission. I suggest that this change be reverted.

@MaxJikharev You can use the allowed_mentions field to enable the pings within Interaction responses

Edit: nvm, see advaith1's comment below

[advaith1]

apparently it was changed after that but not announced publicly anywhere

[TwilightZebby]

Huh, interesting. Thanks for the heads up then :)

[Rapptz]

I appreciate the thumb downs, why am I wrong?

Because it was a permission escalation.

A bad actor can make a button and when pressed ping everyone or a role despite the bot having no permission to do so.

Managing whether or not a bot pings a role is an easy task and is disabled by default... why must further restrictions be applied??

This is not how this system works. Interactions have no permissions. Even if the bot itself has permissions they completely bypass them. As a compromise and final stopgap to abuse, it was made so interactions check the permissions of the everyone role since it wasn't possible to make it check for the bot's permission. Ideally interactions would be attached to an actual bot user with permissions -- however the bot API team is afraid of bots being in the member list so they decided that interactions should optionally have a bot user leading to this whole permissions mess.

[Pandapip1]

however the bot API team is afraid of bots being in the member list

Solution: remove bots from the sidebar member list

[ThetaBird]

A bad actor can make a button and when pressed ping everyone or a role despite the bot having no permission to do so.

What I'm getting from this is that permissions were escalated to prevent the worst-case scenario of potential ping abuse; a problem that is easily preventable by being wary of what bots you add to the server.

I get the intentions behind the change but it seems like it's an extreme stopgap to an insignificant problem. There are no security vulnerabilities (right?) that this change fixes. Removing abilities to ping roles for interaction responses to prevent ping abuse from a few bad actors (which can be fixed by simply removing the bot from the server and/or removing slash command usage permissions from the server members abusing the feature) handicaps an integral part of interactions for certain bot genres.

I still believe the change is unnecessary; if there is a bad actor, the servers themselves can handle the issue. If it was an unwanted feature, the developers can disable it (which it was by default, anyway) in their own code. Reverting the change would definitely bring back that freedom.