From c011240daacee346fce3a181c51dff2eb42ec282 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 14 Jan 2025 17:37:24 -0700 Subject: [PATCH] MSC: Extensible Events modification: State event handling --- ...modify-extensible-events-state-handling.md | 45 +++++++++++++++++++ proposals/1767-extensible-events.md | 6 +-- 2 files changed, 48 insertions(+), 3 deletions(-) create mode 100644 proposals/0000-modify-extensible-events-state-handling.md diff --git a/proposals/0000-modify-extensible-events-state-handling.md b/proposals/0000-modify-extensible-events-state-handling.md new file mode 100644 index 00000000000..dc6816685bc --- /dev/null +++ b/proposals/0000-modify-extensible-events-state-handling.md @@ -0,0 +1,45 @@ +# MSC0000: Extensible Events modification: State event handling + +[MSC1767 (accepted; not merged)](https://github.com/matrix-org/matrix-spec-proposals/pull/1767) introduced +a concept of Extensible Events to Matrix, with a specific recommendation that state events *not* be +treated as extensible except on a case-by-case basis. During review of [MSC3765](https://github.com/matrix-org/matrix-spec-proposals/pull/3765), +it was thought that the recommendation may need to be changed - this MSC captures that thinking, which +is similarly captured in [this comment](https://github.com/matrix-org/matrix-spec-proposals/pull/3765#discussion_r1915778656) +on MSC3765. + +## Proposal + +MSC1767 is modified to permit clients to use content blocks to render unknown state event types in +rooms. Clients SHOULD render such events in a way where the user is not confused by the event being +rendered. An example approach may be to add a small decoration to say "this message may appear differently +to other users". + +## Potential issues + +Clients may render state events in a confusing way for users, allowing senders to 'trick' the user +into believing something was said. For example, sending `m.room.topic` state events with `m.text` of +`Alice has been promoted to Admin`. Per the proposal, clients should find a way to de-confuse the +user, or otherwise handle unknown (state) event types more safely. Or, render specified event types +and avoid the issue entirely 😇. + +## Alternatives + +The obvious one is the current text of MSC1767, as of writing: + +> Unknown state event types generally should not be parsed by clients. This is to prevent situations +> where the sender masks a state change as some other, non-state, event. For example, even if a state +> event has an `m.text` content block, it should not be treated as a room message. + +## Security considerations + +Implied by potential issues. + +## Unstable prefix + +While this proposal is not considered stable, clients should follow MSC1767's unstable prefix guidance. + +Clients are encouraged to experiment with UI/UX which de-confuses users. + +## Dependencies + +This MSC has no dependencies which aren't already accepted. diff --git a/proposals/1767-extensible-events.md b/proposals/1767-extensible-events.md index a4c2a9443bc..6db9415b59c 100644 --- a/proposals/1767-extensible-events.md +++ b/proposals/1767-extensible-events.md @@ -253,9 +253,9 @@ allowed to do this. Such examples include MSC3381 Polls and MSC3245 Voice Messag ### State events -Unknown state event types generally should not be parsed by clients. This is to prevent situations -where the sender masks a state change as some other, non-state, event. For example, even -if a state event has an `m.text` content block, it should not be treated as a room message. +Clients should handle unknown state event types with care, aiming to avoid confusing the user. For +example, if a state event has an `m.text` content block, it should be rendered either differently to +normal message events or with a decoration to indicate that other users may be seeing something else. Note that state events MUST still make use of content blocks in applicable room versions, and that any top-level key in `content` is defined as a content block under this proposal. As such, this