Support for slash command shortcuts in content/embeds

[zikeji]

Description

Similar to the Discord tags, e.g. <@id>, it would be nice to be able to do slash command shortcuts. Such as </command.id> which would resolve to a clickable text and allow the user to "click" it to run that command (or prefill it?). And hovering would of course show them the command, bot, parameters, etc. It would of course ask for confirmation much to how outlinks work, and allow a user to "trust" this bot / user.

The shortcut could specify the parameters as well.

Example:

Say I have a command like /members role:<role> that shows members of that role. I also have a /member user:<user> command that shows specific information for that member. I could then add shortcuts to the output of /members to run /member user:<user>. Those shortcuts would look like </command.id:user=user.id> which would resolve into a hyperlink that when clicked, runs the /member command.

Why This is Needed

This would allow much more interactivity to commands, similar to the way reactions are used in text based command output. In lieu of GUIs / modals (which I believe planned at some point in the future) this should be fairly straightforward to implement and would be a massive improvement to usability.

Alternatives Considered

Not using webhooks to respond and instead using the normal endpoints and adding reactions and reaction collectors. I'll be using this approach, however the proposed approach is much more flexible.

Additional Details

Abuse?

The </command.id:{parameters}> tag could definitely be abused if users were allowed it. While it would be nice to allow users to use it so they could help other users (in their case since they can't get the command ID I could be </commandName:{parameters} or </bot:commandName:{parameters}>), it could also be abused. For my own purposes it wouldn't be necessary either.

Simply allowing the tag to only the bot itself would work, however it would be nice to have incoming webhooks on servers support it as well, so a server owner leveraging them for info pins and so forth could add shortcuts.

Buttons?

It would be nice to also get button support much like Slack. I realize this is also planned for GUIs/modals in the future though, but extending the tag with `primary:Label:/command.id:{parameters} or something similar that makes a basic button would be amazing.

Interaction updates

While the system could be leveraged to support embed updates fairly easily by using caching, it could also be made easier for developers by adding the original interaction token and the message id (if it's a followup interaction embed) to the interaction received object.

In the above example the /members role:<role> command could have a page parameter. And then it could have a shortcut in the embed that calls say /members role:<role> page:2 and the interaction handler would see it, but also see that it has the originalInteractionToken property and send an ackwithoutsource response and then send an update event using the originalInteractionToken and @original or the message id (if the property exists) to update the original embed. Thus allowing much more interactivity without requiring reactions.

[thetayloredman]

I really like this idea...

[Fish-o]

A slash command also have to give the bot it wants to use the command on, if there are any slash commands with the same name.

What if

1. Bots could only make shortcuts to their own slash commands
2. if users could make them, they need a special permission like menage messages or something entirely new

And then the slash command would look something like

[Click me]<botid/command:param=value>

And maybe the command id and the name are interchangeable

[zikeji]

A slash command also have to give the bot it wants to use the command on, if there are any slash commands with the same name.

What if

1. Bots could only make shortcuts to their own slash commands
2. if users could make them, they need a special permission like menage messages or something entirely new

And then the slash command would look something like

<botid/command:param=value>
And maybe the command id and the name are interchangeable

The bot would not have to provide the bot name / id (unless the author really wants to or needs to for a unique use case). Slash command IDs are unique, so the same slash command name doesn't matter - unless the bot author for whatever reason is programming his bot to use the slash command name instead of the ID, in which case he should just be able to use @me instead of his bot's user ID.

The syntax would be somewhat like animated emoji syntax - <a:name:id>.

<botid/commandname:param=value>,
<@me/commandname:param=value>,
or
</commandid:param=value>

The default button/link text could look something like " /command (parameters)" and then you should be able to override/replace that text markdown hyperlink style like [Next Page](</123456:user=123456;page=2>).

As parameters would be semicolon deliminated subcommands would be fine as well. A more complex example:

[View Member](<@me/member:view;user=123456>)
[Next Page](<@me/member:list;role=123456;page=2>)

Of course if a command/parameter/subcommand/etc. doesn't exist or doesn't pass validation it would have to be rendered as an invalid link / some sort of indicator so a bot author knows to fix it.

[msciotti]

Very cool idea. I think there's some obvious wins for things like buttons in the future--press this button to run this command--but the idea of a built-in markdown syntax to reference them anywhere is pretty neat

[xSke]

Buttons as another "interaction type" would absolutely be appreciated for me, but that sounds like a slightly-further-future thing. I was thinking about Markdown links but never managed to make an issue for it :)

My bot has a lot of "interconnected" prompts with occasionally opaque IDs that need to be copied/retyped in order to navigate. It's one of the absolute primary pain points for users of it, but so far there's been no clean way for me to improve it. Support for links or link groups, even if they're just plain text (eg. Prev | Next | Close | Etc) would be MUCH appreciated.

Bonus if it's possible to both have links that send a command directly with no user prompt, and one that pre-fills the text box for adding parameters. One for navigation, one for quick access.

[greysdawn]

Also +1-ing here, as this would help with accessibility/usability immensely for my bots. The main one I'd like to implement this for is a form bot that uses both reactions and text to complete actions- while this works fairly well, the footer is enormous and hard to read due to having to explain the emojis/keywords for each action. Being able to link to something to do that action or having a button explicitly for it would be amazing. Definitely hoping something like this will be implemented!

EDIT: Here's an example of how bad the footer can get. Moving it to a field, the description, or even the content above the embed wouldn't really help either as it'd only make it appear longer (bigger text + I'd probably use new lines for readability) and potentially make users sit through all that info before reading the question outright.

[p4-k4]

The ability to request user input over a series of requests/questions would be great.

Especially in the case of multiple questions that fetch multiple arguments to generate responses or results that are based on a set of conditions... or simply just to collect a group of multiple responses.

The common workaround is to request not-so-reliable user text input or make use of reactions to correspond to various options but it's super clunky. The user experience is also extremely poor when having to resort to methods such as these.

Slash-commands currently only allow a dedicated set of options/choices and I believe that serves a completely different purpose to what is being proposed.

If this request become a thing, I'd imagine a single slash-command could initiate a multi-question "session". The user's attention would be brought to the text channel where the bot presents the first user input request of that session.

[Fish-o]

Bit dumb but i might have found a way to sort of achieve this.
You can mention voice channel just like a text channel with <#id> but when you click on it you get automatically connected to that voice channel.
And the bot would be able to detect that

Few ways i thought this might be useful

1. give the bot a category that it can create voice channels in and then make the category only visible for people with a certain role.
   Then when a user calls a command the bot can create a channel called "yes" and "no" for example, link them in the message, and give the user the role to be able to view them

2. shortcuts, give the bot a category but now admins and the bot would be able to create channels in it, and then the channel names should be something like "/lockdown channel:", and then when people join the channel the bot could see it and run the command. The name could also be in another format like <a:name:id> but that wouldn't be a nice button

[TwilightZebby]

@Fish-o while interesting, Discord has already confirmed bot-made Buttons are going to be made as a new Interaction type. So, in theory these could be used instead

[p4-k4]

You can mention voice channel just like a text channel with <#id> but when you click on it you get automatically connected to that voice channel.

Buttons even in current experimental state give much needed flexibility. They're great by the looks of it.