MSC4139: Bot buttons & conversations

[turt2live]

Rendered

In line with matrix-org/matrix-spec#1700, the following disclosure applies:

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 as operator/developer at t2bot.io.

---

Fixes matrix-org/matrix-spec#232
See also matrix-org/matrix-spec#1651

[turt2live]

Implementation requirements:

• Client rendering prompts
• Bot sending prompts

Note that there is a prerequisite on Extensible Events which needs to be unpicked.

[TheArcaneBrony]

This seems to indicate that interactions are stateful?

I'd been thinking about a similar-ish system, but making the client just send a m.interaction event with a bot-defined content (possibly as a sub-key?)

eg. a bot would define something like

// other content stuffs ...
"interactions": [
  {
    "type": "command",
    "metadata": {
      "action": "roll",
      "dice_type": "1d6"
    }
]

When a user clicks this command button, the client sends an event:

{
  "type": "m.interaction",
  "content": {
     "metadata": {
        "action": "roll",
        "dice_type": "1d6"
     }, 
     // reply stuff
  }
}

I think, personally, I'd love to see a system that sticks more to existing interaction systems in order to avoid extra maintenance burden, and to make it easier to onboard clients.

[turt2live]

Bots can GET the previous event if they don't keep state themselves.

[Gnuxie]

not needed but it would be really nice to generalise this with a whisper MSC.

[turt2live]

The intent here is to very much ensure interactions are visible to the room. Bots looking to whisper the user can utilize DMs for now.

[Gnuxie]

What about if there was just a generic button type that if you clicked, would send an event?

Even better, why can't other things be clicked as a conversation reply (or an argument to a slash command), such as another user, or another event in the room timeline, or another button from another event in the timeline.

Being able to select another button in the timeline as a conversation reply or command argument would unlock a huge door, bots would be able to represent output as different button types. For example, Draupnir would be able to render each individual policy in the response to the equivalent of !rules matching @spam:example.com as a button, that could be selected as an argument in future commands or interactions.

[turt2live]

All of this sounds wonderful and very much needed indeed, though the scope for the MSC needs to end somewhere. Expansion is possible through other MSCs currently, and as this one progresses maybe it brings concepts into it.

[Gnuxie]

Well, it's my opinion that this would reduce the scope of this MSC and future ones by being able to express them using the "button type primitive" (alternatively presentation type). But I do understand how that can be seen differently.

[turt2live]

I'm not sure I'm following the suggestion in that case, sorry. I understood your comment to mean supporting different types of input, not reusing buttons for everything (which I'm not sure how that'd even work).