Endpoint to fetch resolved channel/guild permissions

[jagrosh]

To preface this discussion/request, please consider this request from the perspective of a bot that does not connect to the gateway, and thus does not have a persistent and always-up-to-date cache of all of the guilds, channels, etc it is in.

Description
An endpoint for getting resolved permissions, such as GET /channels/{channel.id}/permissions/ that would return an array of resolved permissions for the provided channel (or guild) for the self user, similar to how the permissions field in the resolved data of channels provides the resolved permissions of the invoking user.

Why This is Needed
Performing an action in response to an interaction (other than responding to the interaction itself) often requires additional permissions. These permissions are often a hassle and/or likely quite costly to retrieve for every action. Caching the permissions works to an extent, but most insufficient-permissions-related problems have the following workflow:

1. A user attempts to use a command
2. The bot fetches the current guild roles, its own member (for the list of roles it has), and the channel overrides of the channel (3 API calls)
3. The bot determines that it doesn't have permissions to perform the action, and returns this information to the user
4. The user attempts to fix the permissions
5. The bot, if caching permissions, will continue to return a failure (until the permissions fall out of cache). If not caching, the bot will repeat the same 3 API calls until the user succeeds in fixing the permissions.

This feels like an abundance of API calls that could be significantly reduced, especially considering that Discord will eventually need to resolve the permissions for the final API call anyway. An endpoint to get the resolved permissions would reduce the total number of API calls need (although it does not solve the caching problem).

Alternatives Considered
Current Alternative (A): Don't cache permissions and rely on HTTP response 403
This is probably the most common approach, as it reduces the total number of API calls significantly, and the API already returns a fail code if the bot doesn't have permissions to perform an action. However, these requests are seen as an "Invalid Request" from Cloudflare, and at a large scale, could end up getting a bot Cloudflare Banned. These can be partially mitigated to an extent by mitigating attempts if a user consistently runs a command that the bot has previously gotten failure codes for, but at a large scale, even this might not be enough to prevent a ban.

Current Alternative (B): Cache until failure
While this can certain reduce the number of excessive API calls, it doesn't prevent the aforementioned workflow.

Alternative Idea (C): Don't count 403s towards a Cloudflare ban,
(or use a different HTTP status for actions where permissions are missing within a valid guild), and instead, consider them a standard response that is (likely) more efficient than making multiple requests. Or, add a flag/header to requests that causes a permissions issue to be considered a success, but with an error message. (Overall, this alternative feels the most hack-y, but is also likely the most efficient/performant one for Discord to supply, as it would reduce the total number of requests).

Alternative Idea (D): Add authorization links for channel-level permissions
From my experience, most permissions-related issues arise from users assuming that bot can do things in channels where they've disallowed regular users from doing things (like posting in a read-only channel). Adding an authorization link that would add a channel permission overwrite could significantly reduce the abundance of permissions-related issues, especially repeated permissions-related issues.

Additional Details
I don't really think that this idea is the best solution to the problem. At the end of the day, if a bot is attempting to send a message in a channel it doesn't have permission to, or making a request for its resolved permissions, Discord has to resolve the permissions either way. Keeping it to one request seems like the most logical option. However, I do think that this idea would significantly improve the workflow if Discord wants to stick to the philosophy of avoiding 403s by inspecting role or channel permissions and by not making requests that are restricted by such permissions. Ideally, Discord will look deeper into the workflow of bots that don't connect to the gateway and come up with a better solution than anything that currently exists.

[advaith1]

I think #3310 would be a better solution to this issue, since it doesn't require an additional HTTP request (iirc Discord does not like bots making one request to see if they can make another request, which is why there is no endpoint to check if you can DM a user)

[jagrosh]

That would also be useful, it would need to include the guild and channel permissions, and ideally also the bot's permissions (not just the user's) in any resolved channels.

The other reason I am suggesting this endpoint is for actions that may happen at some time later than the interaction, at which point the permissions may have changed.