Interactions #8
Interactions #8
Conversation
| Context menu commands are actions you can invoke on any message or user from the context menu | ||
| (right click or click and hold on mobile), these allow users to run actions on a message or user. | ||
|
|
||
| member context menu commands are not attached to any specific channel and are invoked at a server level, |
There was a problem hiding this comment.
would it be possible to allow channels to be included in this type of interaction regardless? i think it could be useful, especially for bots that deal with permissions management.
There was a problem hiding this comment.
I cant see how that would work, you are not always in one channel or even the same channel, what if i tried to go through this when in settings, or i clicked a member which is in a voice channel? should it go off the channel im viewing or the voice channel they are in?
There was a problem hiding this comment.
maybe it could just be an optional parameter?
or maybe there could even be some kind of "context" parameter, which lists exactly what menu or channel you're calling the command from. (although admittedly i cant see how this would be any more useful lmao. just spitballing)
|
|
||
| ## Responding To Interactions | ||
|
|
||
| After receiving an interaction the bot has 3 seconds to respond to the interaction with a reponse, this |
There was a problem hiding this comment.
could this be bumped up to at least 5 seconds? i'd be worried that response times could occasionally exceed this limit.
additionally, shouldn't there be a way to defer responses for operations that can possibly take a full minute or longer to complete?
There was a problem hiding this comment.
Bumping it a couple seconds should be fine, i don't like deferring as it doesn't give much feedback to the user, i could possible add it but it needs to be clear that there is still another response coming, this could be done via just editing the response but i cant think of a good way to handle this at the moment.
There was a problem hiding this comment.
We dont need defers since we can post a pending message like "A response is incoming" by the bot itself and edit the message once the command is done, but if the defers are to implemented, could we possibly get a custom message for it?
There was a problem hiding this comment.
I think having a message or an option to mark as "not finished" or "loading" would be the best solution as it makes it clear to the user that something is coming rather.
I will update the RFC soon to reflect my idea.
There was a problem hiding this comment.
Bumping it a couple seconds should be fine, i don't like deferring as it doesn't give much feedback to the user, i could possible add it but it needs to be clear that there is still another response coming, this could be done via just editing the response but i cant think of a good way to handle this at the moment.
Why not have a similar aproach to discord where a placeholder text a la " is thinking..." is given?
A defer has its benefits here imo
Co-authored-by: Sairam Kumar <61322406+sairam4123@users.noreply.github.com>
| min_size: Option<u64>, | ||
| max_size: Option<u64>, | ||
| }, | ||
| VarArgs { |
There was a problem hiding this comment.
I assume this would be a variadic arg of any of the other types?
| ## Slash Command Management | ||
|
|
||
| These routes are for managing slash commands on the bot | ||
|
|
||
| ```http | ||
| GET /interactions/slash_commands - Get interactions | ||
| PUT - /interactions/slash_commands - Sync interaction | ||
| ``` | ||
|
|
||
| ## Config Panel | ||
|
|
||
|
|
||
| These routes are the server and channel bot config panels | ||
|
|
||
| ```http | ||
| GET /interactions/config_panel - Get server/channel config - spawns interactions | ||
| PATCH /interactions/config_panel - Update server/channel config | ||
| PATCH /interactions/config_panel/invoke - Set server/channel config options - spawns interactions | ||
| ``` | ||
|
|
||
| ## Responding To Interactions |
There was a problem hiding this comment.
Not sure if these headers are intentional, but shouldn't they be h3?
Given the text descriptions below them and the empty ## Routes header I believe they should be part of said header and therefore be h3.
|
There are some questions I have with this idea that should be discussed imo:
|
Zomatree
added
New RFC
|
|
||
| # Drawbacks | ||
|
|
||
| todo |
There was a problem hiding this comment.
Personally speaking, I believe one drawback could be that when multiple bots share the same command name (i.e. /help) that it could be a bit more tedious to find the command of the right bot, and much easier to missclick and select the wrong command from the wrong bot.
There was a problem hiding this comment.
Personally speaking, I believe one drawback could be that when multiple bots share the same command name (i.e.
/help) that it could be a bit more tedious to find the command of the right bot, and much easier to missclick and select the wrong command from the wrong bot.
We can just show the avatar of the bot, maybe we can let the user select the bot itself? Like @bot ban @user1.
One way to prevent dangerous command (due to missclick) is to confirm the user about their action, we can let the developer decide whether a command is dangerous or not. Let's say /ban @user1 @user2, and we have two different bots implementing same command. We just confirm whether he is aware of the consequences. I don't know how feasible this will be!
There was a problem hiding this comment.
A general confirmation for possibly dangerous commands would indeed be good.
But maybe instead of having the dev tell the API whether this command is dangerous, it should be determined by something like permissions required to use the command (Assuming permissions for command usage will be a thing).
If the command required Ban permission, then you could safely assume it's a dangerous one and send the command confirmation to the user.
Also, my point wasn't really in regards to dangerous commands, but just general misclicks one could make when typing the commands.
There was a problem hiding this comment.
A general confirmation for possibly dangerous commands would indeed be good.
But maybe instead of having the dev tell the API whether this command is dangerous, it should be determined by something like permissions required to use the command (Assuming permissions for command usage will be a thing).
If the command requiredBanpermission, then you could safely assume it's a dangerous one and send the command confirmation to the user.
Yes, but my idea could be really helpful for managing external resources which are cud (created, updated, deleted) outside of Revolt. Hence a combination of both permission based inference and bot dev telling us to ask for confirmation is the best of both worlds if you ask me.
Also, my point wasn't really in regards to dangerous commands, but just general misclicks one could make when typing the commands.
Sorry I misunderstood you, we can avoid misclicks by letting the user select the bot, but it could be a problem since if the user does not know which bot to use (this is really rare since the users who use commands are mostly mods who add the bots). Either way, I think letting the user select the bot before showing commands could be an alternative.
5 participants
This RFC is for interactions for better integration with bots.