MSC4391: Simplified in-room bot commands#4391
Conversation
Start off by incorporating MSC4332.
Not really needed when the command description state event is scoped by sender.
Even though the MSC is simpler, we're more ambitious and able to do more with it.
Gnuxie
changed the title
tulir
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Bot
There was a problem hiding this comment.
gomuks/gomuks#675 is mostly complete implementation of client and technically also bot, converted from MSC4332. It doesn't have full support for room/event IDs or unions yet, but mostly it should be there
It assumes most of my suggestions in other comments are applied. Specifically:
commandstring instead ofdesignatorarray"optional": trueinstead of"required": false- primitive schemas nested in an object with
"schema_type": "primitive" - arrays only at top level and unions only at top level or in arrays)
- optionally: list of
aliases,default_valuefor default values
There was a problem hiding this comment.
(all of these suggestions were up-streamed into the MSC)
There was a problem hiding this comment.
Proper bot implementation: maunium/meowlnir#50
Both meowlnir and parts of gomuks use logic from mautrix/go#446 (gomuks web has its own typescript implementation, gomuks terminal uses mautrix-go)
| "m.text": [{ "body": "Whether to apply this to the policy" }] | ||
| }, | ||
| // This argument is not required | ||
| "required": false |
There was a problem hiding this comment.
As an alternative/extension to optional parameters, a default value might be useful. The /raw command in gomuks has {} as the default value for event JSON for example
Also, "optional": true might be nicer than "required": false to allow treating undefined as false
There was a problem hiding this comment.
I didn't include defaults at this stage because they can also be provided by partial commands and interactive prompts ie the way suggestions work in draupnir. I guess it might be ok if it's treated like a literal default.
There was a problem hiding this comment.
I'm a little bit hesitant to do so right now and am thinking of making a JSON RPC style response follow up MSC that can explore the prompts and partial commands before settling on how to do defaults.
matrix-org#4391 (comment) Co-authored-by: Tulir Asokan <tulir@maunium.net>
matrix-org#4391 (comment) Co-authored-by: Tulir Asokan <tulir@maunium.net>
Enable ease of parsing matrix-org#4391 (comment) Co-authored-by: Tulir Asokan <tulir@maunium.net>
matrix-org#4391 (comment) Co-authored-by: Tulir Asokan <tulir@maunium.net>
matrix-org#4391 (comment) Co-authored-by: Tulir Asokan <tulir@maunium.net>
Co-authored-by: Tulir Asokan <tulir@maunium.net>
Co-authored-by: Tulir Asokan <tulir@maunium.net>
Co-authored-by: Tulir Asokan <tulir@maunium.net>
tulir
added
implementation-needs-checking
| - Using state events limits a bot's ability to advertise commands if it isn't | ||
| given power to do so. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
I'm in the process of adding a "response" mixin in a follow up MSC. It would be really useful to also be able to proxy the commands into a mutual room (like draupnir's command room). See the-draupnir-project/Draupnir#1041 (comment)
| - Some predefined validation on arguments, like a range for integers or | ||
| maximum/minimum length of strings. | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
When commands are available across an entire space it is a pita to have to resend the state events everywhere. So maybe it would be nice to be able to only specify the commands in a space or take inspiration from sticker pack MSCs if they haven't encountered the same problem.
3 participants
Rendered
Signed-off-by: Gnuxie Gnuxie@protonmail.com
This MSC incorporates work from MSC4332