MSC4332: In-room bot commands#4332
Conversation
There was a problem hiding this comment.
Implementation requirements:
- Client
- Bot
There was a problem hiding this comment.
the-draupnir-project/Draupnir#944 is an incomplete bot implementation. It would still need to react properly to the mixin/mention, and ideally not be hardcoded.
There was a problem hiding this comment.
gomuks/gomuks#655 is a very ugly client implementation, but I think in theory it might actually work
There was a problem hiding this comment.
The gomuks implementation technically also includes a "bot" now, because the backend will intercept commands sent by the frontend targeted at @gomuks https://github.com/gomuks/gomuks/blob/429e014eb28e99291a27a676e0a4ca64ac79b710/pkg/hicli/send.go#L87-L89 (there was no command system in the past, so this new system is used for both built-in and external bot commands)
There was a problem hiding this comment.
My bot sensebot-go (@sensebot:synapse.nexy7574.co.uk) has been updated to use MSC4332 commands, with a UX that looks like below:
2025-12-09_00-56-36.mp4
Built using mautrix-go, like Gomuks does above. It supports registering commands (only manually for now) and receiving them, differentiating between non-fallback and fallback parsing. Pretty sure this meets the requirements for the bot checkbox, and Gomuks Web should be able to check the client checkbox.
Also, call variables "arguments" instead, given the higher semantic meaning.
|
For the overall changelog: this had a bunch of discussion amongst T&S developers from the community, resulting in the above changes. Namely: variables are now called arguments. Arguments have types now. Variadic arguments are possible. |
| // becomes `!botname` upon sending. | ||
| "commands": [ | ||
| { | ||
| "syntax": "botname {action} {roomId} {timeoutSeconds} {applyToPolicy} {userId...}", // `{words}` are positional arguments. |
There was a problem hiding this comment.
why are we using camel case for the argument names?
Even with, specifically roomId and userId are a bit opinionated.
There was a problem hiding this comment.
this is just the example - I prefer that format, but ultimately it's just a string.
| ```jsonc | ||
| { | ||
| // These fields would be replaced by MSC1767 Extensible Events in future. | ||
| "body": "!botname ban_and_suspend !room:example.org 42 true @alice:example.org @bob:example.org", // note that the syntax template is populated |
There was a problem hiding this comment.
I think we are over estimating the value in body as a fallback for bots that haven't adapted their command parsers to MSC4332 yet. And we risk restricting the benefit we will get from client support for commands by allowing too much freedom here for the purpose of backwards compatibility with existing bots. Additionally the MSC already imposes decisions on how bots have to parse commands in the body representation that is incompatible with existing bots that already have complex command parsing.
There was a problem hiding this comment.
I suspect that bots with suitably complex commands will need to update their parsers at the same time they advertise support for the MSC. Simple bots (gif searching, TWIM, etc) may be able to avoid it.
There was a problem hiding this comment.
I couldn't find a relevant part to comment on, but does this MSC consider accessibility (ie. screen readers) for clients that implement in-composer templating UI? Discord has this problem where slash commands aren't available at all if you enable the accessible text input under Accessibility settings.
| and [come up occasionally](https://github.com/matrix-org/matrix-spec/issues/2170) - finding a way to | ||
| populate this feature with bot-specific details is beneficial. | ||
|
|
||
| This proposal suggests that bots maintain a state event in the rooms it joins to advertise available |
There was a problem hiding this comment.
I don't have a solution to this, but it's worth noting down that this requires room admin intervention since your typical user won't be able to grant bots the power level required to send this state event, and setting the event's power level to world accessible opens the door to abuse. The MSC does elaborate on this but doesn't seem to highlight the severity of this issue, or at least I don't feel it does.
Perhaps stuffing the command registration into memberships retains the exclusivity, but doesn't require a power level modification?
|
|
||
| ```jsonc | ||
| { | ||
| "sigil": "!", // Defaults to `!` if not specified. Clients can use this to show the user a consistent |
There was a problem hiding this comment.
nitpicking, prefix might be better that sigil - it's not uncommon for a multi-character prefix, and !botname itself might even be considered the prefix with the word after it being the command to invoke (e.g. !botname help instead of ! botname help)
| // We also use m.text here for the same reason as the argument descriptions above. | ||
| "m.text": [{"body": "An example command with arguments"}] | ||
| } | ||
| } |
There was a problem hiding this comment.
The ability to register aliases or shortcuts without having to define them as their own separate commands (which itself will then inherently clog up the command list displayed to users) would be nice
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
@slavb18 said outside of a thread:
Hi!
Is it possible to bridge buttons to telegram bot?
There was a problem hiding this comment.
This MSC (and the newer replacement #4391) are only for commands, not buttons. A future MSC could build buttons in a similar way, but it's out of scope here.
(also, all comments on MSCs must be in threads so they can be appropriately replied to and resolved)
Rendered
Disclosure: I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published in my capacity as Tech Lead for T&S, though does not achieve any particular T&S project/goal.