Context Menus should be their own interaction type

[MinnDevelopment]

Currently, context menu items are defined as "context menu commands" and share an interaction type with slash commands (application command type). My proposal is to make context menus their own interaction type.

As of now, context menu "commands" are essentially just a single-argument slash commands which is a rather unfitting and underwhelming feature. All context menus could be replaced by slash commands that have a single argument such as "message" or "user", so really these context menus just run the commands when you click them instead of typing them out.

Motivation

Introducing a new sub-type for command interactions is a breaking change, as existing clients do not expect commands to have types and are not implemented to be type-aware. This means we will have to change our type hierarchy to adjust to these new types properly, as our existing implementations will treat all command interactions as slash commands inherently.

Context menus are an inherently different way of interacting with the interface, whereas slash commands are purely a text input. The way you should respond to these two different ways of interacting, SHOULD be different and must not be merged into one interaction response.

Problems with same type semantics

Since slash commands are a text input in a text channel, it makes complete sense to reply to them with messages. This does not apply to context menus which should function regardless of the current open channels. Examples where context menus cannot possibly respond with messages:

• Youtube together
• Stage channels
• Any settings screen (such as audit logs, member list, ban list, etc...)
• Simply being scrolled up in the channel, which would require scrolling down to the bottom just to see the reply of the context menu (which is REQUIRED btw)

Another problem with using the same type is that they are restricted by the similarity aspect of the same interaction type in general. Slash commands and context menus are now equated as "commands" which implies they behave, interact, and respond similarly. This is a restrictive and non-robust definition that limits the possibilities for future API design.

Since context menus are also sharing all endpoints with slash commands, you must specify them when updating your slash commands with the PUT endpoint. Obviously, this is a symmetric requirement that applies to any "command type" which is a non-intuitive and annoying design.

Disadvantages of using a different type

Assuming we use a different type for context menus, this would mean:

• The endpoints need to be split apart into command and context menu endpoints
• Permissions would need to be defined for both concepts
• The documentation would have to be improved (this is generally true regardless imo)
• Currently the "use slash commands" permission applies to both context menus and slash commands, this could be split up or renamed to match the new abstracted definition (see below)

All of these problems can be solved by introducing a different abstracted definition like "application interaction elements" which are registered per guild/channel/user and similar scopes.

And of course the biggest disadvantage: this requires more work than simply adding a new sub-type for "commands".

[night]

We have no current plans to split out context menus to a separate model or endpoint. The data being configured largely overlaps and shares the same infrastructure and purpose, making it prime for the application command primitive model.

As of now, context menu "commands" are essentially just a single-argument slash commands which is a rather unfitting and underwhelming feature. All context menus could be replaced by slash commands that have a single argument such as "message" or "user", so really these context menus just run the commands when you click them instead of typing them out.

We wanted to get context menus out to users as a "quick actions" functionality to see what people would do with them. We do have further ideas that may enable additional functionality with them in the future.

Since slash commands are a text input in a text channel, it makes complete sense to reply to them with messages. This does not apply to context menus which should function regardless of the current open channels.

Similar to the above, our goal was to get something out quickly. We have plans for additional interaction response types, which would enable different types of replies, even for slash commands. If you'd like to see improvements there, my general recommendation would be to open a feature request or upvote existing feature requests for response types you'd like to see us work on.

Introducing a new sub-type for command interactions is a breaking change, as existing clients do not expect commands to have types and are not implemented to be type-aware.

If a bot has no context menu commands, nothing changes for them. Similar to past model changes, libraries should ignore data it doesn't know about. You can ignore any type field you may receive. You can also continue not to send type when creating or editing commands, but we may make type required in a future API version.

If a bot adds a context menu command, only then must it now be type-aware.

[MinnDevelopment]

our goal was to get something out quickly

Thank you for the honesty. I appreciate it.