MSC4301: Event capability negotiation between clients #4301
Conversation
Johennes
changed the title
Signed-off-by: Johannes Marbach <[email protected]>
Johennes
force-pushed
the
johannes/event-capability-negotiation
branch
from
41b2f7d to
2654cf3
Compare
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Sending client
- Receiving client (with support)
- Receiving client (without support)
| Matrix allows clients to exchange both built-in and custom events with other clients in rooms. There | ||
| is, however, no way for a client to understand what types of events the other clients in a room are | ||
| able to understand. This is problematic as a compatibility mismatch means that the recipient user | ||
| might only be able to see a fallback representation of an event or, in the worst case, nothing at | ||
| all. At the same time, the sender is left wholly unaware of the recipient's experience. |
There was a problem hiding this comment.
This problem area is discussed a lot, usually in the context of extensible events. I'm concerned that this MSC opens up pandora's box again by trying to add a negotiation layer on top of a compatibility layer - this proposal needs a strong rationale for why extensible events is insufficient beyond "it can sometimes result in fallback", which is by design.
There was a problem hiding this comment.
this proposal needs a strong rationale for why extensible events is insufficient beyond "it can sometimes result in fallback", which is by design.
This is really it though.
We're using Matrix in the healthcare sector and in some cases it's simply not acceptable to rely on fallback representations. The events to be sent might contain complex medical data that cannot feasibly be condensed into a useful fallback and where the sender requires guarantees that the content will actually be understood because health depends on it.
There was a problem hiding this comment.
Imho a combination of extensible events and m.status.response would be sufficient. We could add an information like allow_fallback: Boolean or don't add a fallback at all in the extensible event. Then the receiver could answer with an m.status.response so the sender would get notified about displaying issues.
There was a problem hiding this comment.
For many cases a fallback would be sufficient. E. g. a DICOM event could have an image and file fallback, so the user would get a preview (image fallback) and could download the DICOM (file fallback) and open it in an external software.
There was a problem hiding this comment.
Those are good points. I suppose in essence the only thing this proposal adds over #4300 is the shortcut of figuring out if an event type will be understood before actually sending the event.
Not having to send the event if the recipient is known to not support it is probably only a meaningful benefit if you're sending extremely large data.
However, being able to downgrade to another event type that the recipient understands feels harder to do with just #4300. What I'm trying to hedge against are cases where there are multiple historic versions of an event type (similar to how some of the email message types here had several versions).
Rendered