MSC4332: In-room bot commands #4332
Conversation
turt2live
added
proposal
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)
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.
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.