Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3006: Bot Interactions #3006

Open
wants to merge 6 commits into
base: old_master
Choose a base branch
from
Open

Conversation

MTRNord
Copy link
Contributor

@MTRNord MTRNord commented Feb 13, 2021

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

@MTRNord MTRNord changed the title [MSC3006] Bot Interactions MSC3006: Bot Interactions Feb 13, 2021
Copy link

@LorenDB LorenDB left a comment

Choose a reason for hiding this comment

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

Just some grammar nitpicking. (Sorry!)

proposals/3006-bot-interactions.md Outdated Show resolved Hide resolved
proposals/3006-bot-interactions.md Outdated Show resolved Hide resolved
proposals/3006-bot-interactions.md Outdated Show resolved Hide resolved
proposals/3006-bot-interactions.md Outdated Show resolved Hide resolved
proposals/3006-bot-interactions.md Outdated Show resolved Hide resolved
proposals/3006-bot-interactions.md Outdated Show resolved Hide resolved
MTRNord and others added 2 commits February 13, 2021 18:38
Co-authored-by: Loren Burkholder <55629213+LorenDB@users.noreply.github.com>
Co-authored-by: Loren Burkholder <55629213+LorenDB@users.noreply.github.com>
@turt2live 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
proposals/3006-bot-interactions.md Show resolved Hide resolved

## Potential issues

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

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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)

Choose a reason for hiding this comment

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

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
Copy link
Contributor

penn5 commented Feb 14, 2021

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

{
"type": "m.bot.interactions",
"state_key": "@faq_bot:example.matrix",
"command_prefix": "!",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm yeah that also makes sense.

proposals/3006-bot-interactions.md Outdated Show resolved Hide resolved
Co-authored-by: Erkin Alp Güney <erkinalp9035@gmail.com>
@JoshuaDietz
Copy link

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).

  1. Member A sends a command for bot C.
  2. 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.
  3. Meanwhile member B sends a command to bot D.
  4. 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:

  1. Allow <button> tags in messages with a button-data attribute.
  2. 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.
  3. 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
Copy link

erkinalp commented May 1, 2021

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
Copy link
Contributor

penn5 commented May 1, 2021

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
Copy link

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.

@@ -0,0 +1,322 @@
# MSC3006: Bot Interactions
Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

Choose a reason for hiding this comment

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

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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 :/

@turt2live 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
@MTRNord
Copy link
Contributor Author

MTRNord commented Nov 23, 2021

Dropping this for personal reasons

@MTRNord MTRNord closed this Nov 23, 2021
@turt2live turt2live added abandoned A proposal where the author/shepherd is not responsive and removed proposal-in-review labels Nov 23, 2021
@MTRNord
Copy link
Contributor Author

MTRNord commented Oct 27, 2023

Reopening as I have some more capacity again for this

@MTRNord MTRNord reopened this Oct 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abandoned A proposal where the author/shepherd is not responsive 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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants