MSC2929: Interaction events

[erkinalp]

Extremely simplistic and primitive design of interaction events.
Rendered

[turt2live]

@erkinalp the MSC number is actually 2929 (please rename the file). We also need signoff before we can consider this MSC in a landable state, though it can enter review for now.

[erdnaxeli]

I found this MSC confusing, I don't really understand what it wants to solve. It looks likes it targets bots, but I don't think there is any needs for new event just to send commands to bots.

I think you should add some detailed use cases.

[erdnaxeli]

I think the presentation should be specified, so every client implements it in a common way. The users should be able to change their matrix client without having to learn new patterns.

[erkinalp]

How could I stipulate a common presentation when interaction types are implementation defined?

[erkinalp]

I have now added recommended response targets for interaction responses, which will enable clients to make reasonable presentation decisions. However, as interaction subtypes are left implementation defined, I cannot exhaustively define presentation behaviour for all possible types of interaction events.

[erdnaxeli]

I was thinking about how available interactions are presented to the user so it can use them, not about what they trigger.

[erdnaxeli]

How do the clients know available interactions? We need a way to declare them. Without that this MSC is pretty useless IMHO.

Are interactions specific to a room? or to a user account?

[erkinalp]

I am open to suggestion on how to specify those registration events. As I said, I started with a barebones proposal.

[erkinalp]

They are specific to a room and a user (the user responding to the interaction). Notification wording should have clarified that.

[erdnaxeli]

This MSC does not explains how the app reacting to the interaction should be notified. Should it listen to events in the room? So it should have an user that joins the room?

I think this miss a point of slack / discord / and others integrations: their simplicity. You can do an app for slack by just writing a web server that listen on a specific endpoint. Listening to a room's events is a lot more complex.

[erkinalp]

Should it listen to events in the room? So it should have an user that joins the room

Yes, it has to join the room and this is by design. Re. notification thing, I am going to address it by designing a notification system that will not require the bot to listen to all room events, but only to those interactions (bar E2EE rooms, where I deliberately omit that capability and require listening on all events). More on that soon.

[erdnaxeli]

Yes, it has to join the room and this is by design

So that means bots, and it excludes slash-like commands

[erkinalp]

So that means bots, and it excludes slash-like commands

In my proposal, you would send commands to bot's "profile room" to achieve slash-like commands.

[erdnaxeli]

Bots and slash command (like /giphy on slack) are two very different type of application. A bot need to have its own user and needs to join the room, while a slash command could be called from anywhere without knowing about where it is used.

I think the MSC should consider both cases. I even think the MSC should focus on slash commands and define a full protocol for them, while bots already work well (using text messages and command starting with a specific character, like "!dosomething").

[erkinalp]

Both problems are readily solvable by clever use of rooms. MSC1769 solves the publicly visible global command thing by enabling you to post to bot's room "wall". OTOH, private commands could be DMd to the bot.

[erdnaxeli]

But that means any command have to implement the matrix client-server protocol (managing access token, doing sync, …). I am sure not we need it.

[erkinalp]

I designed interaction events as extensible as possible. Lightweight authentication schemes you suggest will cause security nightmare with that broad capability I propose (mind you, those implementation-defined events will be allowed to target pretty much anything, response flows are also implementation defined). Therefore I cannot allow a shortcut authentication scheme like Slack apps and Discord webhooks use.

[jackmawer]

i'd like to signal some continued interest on my part with this MSC, as I think interactions brings a lot of power in terms of user interaction with bots.
could any maintainers point out what would be needed to actually move this msc forward? is it just a case of creating an implementation?

[turt2live]

This MSC is declared abandoned, so a new MSC would need to be started. For process questions it is generally best to visit #matrix-spec:matrix.org on Matrix rather than asking on MSCs directly (we tend to ignore comments on closed/merged MSCs)