MSC3006: Bot Interactions #3006

MTRNord · 2021-02-13T12:40:49Z

This MSC is part 1 of 2 on Bot interactions. There is going to be a followup on this combining reactions and the interactions of this MSC for inline links/buttons/actions :)

Rendered

Signed-Off-By: Marcel Radzio support@nordgedanken.dev

~~Element-Web implementation: matrix-org/matrix-react-sdk#5842~~

TODOS (these came up while implementing)

State events with statekey need PL50 by default it seems (needs a change to the default PL event and probably by that a room version change)
Fallback Section was never written but should have been added

LorenDB

Just some grammar nitpicking. (Sorry!)

proposals/3006-bot-interactions.md

Co-authored-by: Loren Burkholder <55629213+LorenDB@users.noreply.github.com>

proposals/3006-bot-interactions.md

erkinalp · 2021-02-13T18:51:14Z

proposals/3006-bot-interactions.md

+
+## Potential issues
+
+* Priority of stages is not defined if 2 commands happen at the same time


define this as the timestamp order of the interaction targets' read receipts

Timestamps are difficult across federated systems. However this most likely is already solved by the relations. (Would love to have some more input on this assumption from some that understand relations better than I do)

Timestamps are difficult across federated systems.

Read receipts only advance forwards, hence that order is always well defined and the problem boils down to retrieving the read receipts from the bot's server. And relations would not be useful across multiple unrelated commands from different users.

penn5 · 2021-02-14T11:14:44Z

Why does there have to be a command prefix? Why does it have to be the same for all commands?

MTRNord · 2021-02-14T11:26:44Z

proposals/3006-bot-interactions.md

+{
+  "type": "m.bot.interactions",
+  "state_key": "@faq_bot:example.matrix",
+  "command_prefix": "!",


From @penn5 :

Why does there have to be a command prefix? Why does it have to be the same for all commands?

The reason for the command prefix is to have it backwards compatible for cunstruction of the legacy message. From all bots I have seen so far in the matrix network this prefix always was the same across all commands the bot had. That is why I made this a extra key instead of having that in every interaction. Also doing it in the interaction would have added an additional "command" key to each interaction to allow for backwards compatibility.

Surely the current way, the command text is required to be equal to the name? Doesn't that mean that for backwards compatibility the name can't be human readable (or any more than the bot command used to be)? Surely it makes more sense to add a text key to each interaction to store the message that should be sent? Then, the bot is able to customise the fallback message...

Hm yeah that also makes sense.

proposals/3006-bot-interactions.md

Co-authored-by: Erkin Alp Güney <erkinalp9035@gmail.com>

JoshuaDietz · 2021-05-01T01:18:08Z

I like the interactions. However I see some problems with the buttons and the stages (if I understood the proposal right): As far as I understood a bot is a totally normal user account in matrix. This means that everyone can act like a bot in a room (i.e. send the events proposed here) and every room can have multiple members. Since it's namespaced with the username I don't see a problem with the interactions. But for the buttons there is the opportunity to do all kinds of strange stuff. I.e. in a room with multiple members a bot could start a stage on user request. Then a completely other user can also send buttons. Now the client does not know which buttons to display. Even if this is circumvented, i.e. by the clients/server checking for which member/bot a command was intended and then allowing only this bot to show buttons is a problem because of the group nature of every room. I.e. imagine the following scenario:
You have a room with member A and B and bot C and D (all just users from a matrix standpoint).

Member A sends a command for bot C.
Bot C presents it's buttons (to all members of the room I guess?) and the user waits a few seconds to decide which button to click.
Meanwhile member B sends a command to bot D.
Bot D presents it's buttons.

Now member A does not see the buttons of bot C with which he interacted but instead the ones of bot D (or possibly both depending on implementation)

Maybe I got this completely wrong and you planned a way to start something like a session when A sends the first command to bot C and then only the client of A displays the buttons and ignores other buttons or something like this. But if not I see a few opportunities for this to confuse users.

Maybe an easier approach could be the following:

Allow <button> tags in messages with a button-data attribute.
When a button is clicked the user who sent the message containing the buttons (i.e. the bot) gets a message notifying him that the button with the value of button-data was clicked by the user with id xy.
To present the next stage the bot can simply edit the message to display other buttons or remove them altogether.

The advantage of this approach is that the buttons are always bound to a message and only the sender of the message can edit them. That way presents much less opportunities to yield to confusion of the user because it's unclear to which bot the buttons belong to.

erkinalp · 2021-05-01T07:56:29Z

Allow <button> tags in messages with a button-data attribute.
When a button is clicked the user who sent the message containing the buttons (i.e. the bot) gets a message notifying him that the button with the value of button-data was clicked by the user with id xy.
To present the next stage the bot can simply edit the message to display other buttons or remove them altogether.

That has already been discussed in matrix-spec room and there have been strong objections, such as:

Imo, and I think some portion of the SCT shares this (judging by the matrix live episodes I’ve watched yesterday), HTML is turning out to be not that ideal for a message format, and tulir’s JSON-based formatting MSC was mentioned multiple times

penn5 · 2021-05-01T13:32:35Z

Allow <button> tags in messages with a button-data attribute.
When a button is clicked the user who sent the message containing the buttons (i.e. the bot) gets a message notifying him that the button with the value of button-data was clicked by the user with id xy.
To present the next stage the bot can simply edit the message to display other buttons or remove them altogether.

That has already been discussed in matrix-spec room and there have been strong objections, such as:

Imo, and I think some portion of the SCT shares this (judging by the matrix live episodes I’ve watched yesterday), HTML is turning out to be not that ideal for a message format, and tulir’s JSON-based formatting MSC was mentioned multiple times

Then a Telegram-style approach, with buttons a part of the message in their own 2D array, could be more flexible. It would also remove the confusion that could occur, e.g., if a button appeared in the middle of a link

JoshuaDietz · 2021-05-01T14:07:18Z

Allow <button> tags in messages with a button-data attribute.
When a button is clicked the user who sent the message containing the buttons (i.e. the bot) gets a message notifying him that the button with the value of button-data was clicked by the user with id xy.
To present the next stage the bot can simply edit the message to display other buttons or remove them altogether.

That has already been discussed in matrix-spec room and there have been strong objections, such as:

Imo, and I think some portion of the SCT shares this (judging by the matrix live episodes I’ve watched yesterday), HTML is turning out to be not that ideal for a message format, and tulir’s JSON-based formatting MSC was mentioned multiple times

Thank you for the link. My main point was that buttons should be bound to a message. I agree that HTML is not ideal. I meant this to be more of a minimal example. The approach that every message can get a number of buttons in a special format sounds good to me.

MTRNord · 2021-05-02T19:28:53Z

proposals/3006-bot-interactions.md

@@ -0,0 +1,322 @@
+# MSC3006: Bot Interactions


Thank you for the link. My main point was that buttons should be bound to a message. I agree that HTML is not ideal. I meant this to be more of a minimal example. The approach that every message can get a number of buttons in a special format sounds good to me.

Moving from #3006 (comment) (cc @JoshuaDietz ) to a thread. (Next time please use thread to make the PR more readable please)

The goal of this MSC is actually to not do inline buttons. That would be a separate MSC and I do agree it should exist. This one is meant to be non message bound commands :) Thats why buttons are not bound to messages.

Yes I got that the goal of this MSC are not inline buttons. But as I described I don't really see how these keyboard buttons can work with matrix since every user can send them to every room as he wants (as long as there are no protections against that, i.e. a new permission). So if they are implemented in my opinion there needs to be a concept on how to avoid abuse of the feature (see the problems that I described in my previous comment)

Well a) as "m.bot.interactions" is an own event you could restrict it by powerlevels b) thats more an overall "issue" in matrix if you want to call it like that. Because bots are not separate from users. They are the same thing. So solving this is imho out of scope of this MSC. This is only possible to solve by separating users and bots as otherwise it is impossible to make restrictions that work for bots but restrict users :/

MTRNord · 2021-11-23T03:04:29Z

Dropping this for personal reasons

MTRNord · 2023-10-27T09:27:45Z

Reopening as I have some more capacity again for this

Add MSC3006

dc16f23

MTRNord changed the title ~~[MSC3006] Bot Interactions~~ MSC3006: Bot Interactions Feb 13, 2021

LorenDB reviewed Feb 13, 2021

View reviewed changes

MTRNord and others added 2 commits February 13, 2021 18:38

MSC3006: Apply suggestions from LorenDB

5120830

Co-authored-by: Loren Burkholder <55629213+LorenDB@users.noreply.github.com>

MSC3006: Apply suggestions from LorenDB

02ec11f

Co-authored-by: Loren Burkholder <55629213+LorenDB@users.noreply.github.com>

turt2live added kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal proposal-in-review labels Feb 13, 2021

erkinalp reviewed Feb 14, 2021

View reviewed changes

MTRNord commented Feb 14, 2021

View reviewed changes

rkfg reviewed Mar 3, 2021

View reviewed changes

proposals/3006-bot-interactions.md Outdated Show resolved Hide resolved

erkinalp suggested changes Mar 3, 2021

View reviewed changes

proposals/3006-bot-interactions.md Outdated Show resolved Hide resolved

Fix typo

a317bf3

Co-authored-by: Erkin Alp Güney <erkinalp9035@gmail.com>

erkinalp approved these changes Mar 3, 2021

View reviewed changes

[MSC3006] Fix json examples and add unstable prefix

bb666bb

MTRNord mentioned this pull request Apr 12, 2021

Draft: Initial implementation of MSC3006 matrix-org/matrix-react-sdk#5842

Closed

6 tasks

[MSC3006] Add Fallback section and mention required powerlevel changes

d4e67df

MTRNord commented May 2, 2021

View reviewed changes

Half-Shot mentioned this pull request May 24, 2021

Feature request: Fantasy commands (!op, !adminroom, etc.) matrix-org/matrix-appservice-irc#1328

Open

turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021

turt2live force-pushed the old_master branch from e895827 to dca99ee Compare August 30, 2021 22:34

MTRNord closed this Nov 23, 2021

turt2live added abandoned A proposal where the author/shepherd is not responsive and removed proposal-in-review labels Nov 23, 2021

This was referenced May 20, 2021

Ability to disable richer features per room or space. matrix-org/matrix-spec#836

Open

Deep Linking in messages matrix-org/matrix-spec#898

Open

pontaoski mentioned this pull request Sep 28, 2023

Richer bot interactions matrix-org/matrix-spec#1651

Open

MTRNord reopened this Oct 27, 2023

turt2live removed the abandoned A proposal where the author/shepherd is not responsive label Dec 13, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSC3006: Bot Interactions #3006

MSC3006: Bot Interactions #3006

MTRNord commented Feb 13, 2021 •

edited

Loading

LorenDB left a comment

erkinalp Feb 13, 2021

MTRNord Feb 19, 2021

erkinalp Feb 22, 2021

penn5 commented Feb 14, 2021

MTRNord Feb 14, 2021

penn5 Feb 15, 2021

MTRNord Feb 19, 2021

JoshuaDietz commented May 1, 2021

erkinalp commented May 1, 2021 •

edited

Loading

penn5 commented May 1, 2021

JoshuaDietz commented May 1, 2021

MTRNord May 2, 2021

JoshuaDietz May 3, 2021

MTRNord May 3, 2021

MTRNord commented Nov 23, 2021

MTRNord commented Oct 27, 2023


		## Potential issues

		* Priority of stages is not defined if 2 commands happen at the same time

MSC3006: Bot Interactions #3006

Are you sure you want to change the base?

MSC3006: Bot Interactions #3006

Conversation

MTRNord commented Feb 13, 2021 • edited Loading

TODOS (these came up while implementing)

LorenDB left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

penn5 commented Feb 14, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JoshuaDietz commented May 1, 2021

erkinalp commented May 1, 2021 • edited Loading

penn5 commented May 1, 2021

JoshuaDietz commented May 1, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MTRNord commented Nov 23, 2021

MTRNord commented Oct 27, 2023

MTRNord commented Feb 13, 2021 •

edited

Loading

erkinalp commented May 1, 2021 •

edited

Loading