Skip to content

MSC4332: In-room bot commands#4332

Open
turt2live wants to merge 5 commits into
mainfrom
travis/msc/in-room-bot-commands
Open

MSC4332: In-room bot commands#4332
turt2live wants to merge 5 commits into
mainfrom
travis/msc/in-room-bot-commands

Conversation

@turt2live

Copy link
Copy Markdown
Member

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.

@turt2live turt2live changed the title MSC: In-room bot commands MSC4332: In-room bot commands Aug 27, 2025
@turt2live turt2live added proposal A matrix spec change proposal. Process state. A-Client Server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Aug 27, 2025
@turt2live turt2live marked this pull request as ready for review August 27, 2025 16:54

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • Client
  • Bot

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gomuks/gomuks#655 is a very ugly client implementation, but I think in theory it might actually work

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread proposals/4332-in-room-bot-commands.md Outdated
Comment thread proposals/4332-in-room-bot-commands.md Outdated
Comment thread proposals/4332-in-room-bot-commands.md Outdated
Comment thread proposals/4332-in-room-bot-commands.md Outdated
@turt2live

Copy link
Copy Markdown
Member Author

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we using camel case for the argument names?

Even with, specifically roomId and userId are a bit opinionated.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #4338

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See also #4340

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@timedoutuk timedoutuk Dec 9, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"}]
}
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@slavb18

This comment was marked as resolved.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@slavb18 said outside of a thread:

Hi!

Is it possible to bridge buttons to telegram bot?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Client Server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal. Process state.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants