From b340dccb7388c4e3aa3e54ac8e1667087932ded8 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Thu, 13 Jan 2022 22:00:19 -0700 Subject: [PATCH] Extensible Events: Edits and replies --- proposals/3643-extensible-replies-edits.md | 177 +++++++++++++++++++++ 1 file changed, 177 insertions(+) create mode 100644 proposals/3643-extensible-replies-edits.md diff --git a/proposals/3643-extensible-replies-edits.md b/proposals/3643-extensible-replies-edits.md new file mode 100644 index 000000000..bf812a739 --- /dev/null +++ b/proposals/3643-extensible-replies-edits.md @@ -0,0 +1,177 @@ +# MSC3643: Extensible Events: Edits and replies + +[Extensible Events (MSC1767)](https://github.com/matrix-org/matrix-doc/pull/1767) are a new way of +representing renderable events in clients, with a focus on providing fallbacks for rendering unknown +event types. + +[Replies](https://spec.matrix.org/v1.1/client-server-api/#rich-replies) are a specified feature which +allows a user to incorporate the context of a previous message in their own, forming a sort of +"reply chain". Note that this is different from a concept of "threads" which typically have more +powerful UI on top of them. + +[Edits (MSC2676)](https://github.com/matrix-org/matrix-doc/pull/2676) are simply a way to "replace" +the `content` of an event with new contents, allowing users to fix typos and such on their messages. + +Both replies and edits have a built-in fallback system and aren't completely compatible with the +way extensible events are intended to operate. Building off of [MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781), +this proposal aims to describe the additional subtle differences for how edits and replies work +on fully extensible events. + +**Note**: [MSC1767](https://github.com/matrix-org/matrix-doc/pull/1767) defines a transitional format +for room messages. As far as this proposal is concerned, those transitional events are left untouched +for backwards compatibility. This proposal only affects the after-transition events (or any other event +types which happen to use extensible events from the start, like [Polls (MSC3381)](https://github.com/matrix-org/matrix-doc/pull/3381))). + +## Dependencies + +This MSC requires the following to pass (or likely pass) FCP before being able to be FCP'd itself: + +* [MSC1767: Extensible events](https://github.com/matrix-org/matrix-doc/pull/1767) +* [MSC2676: Edits](https://github.com/matrix-org/matrix-doc/pull/2676) +* [MSC2781: Remove edit & reply fallbacks](https://github.com/matrix-org/matrix-doc/pull/2781) + +## Proposal + +As described by [MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781), replies will have already +lost their fallback representation. This means they will look something like this on a legacy event: + +```json5 +{ + "type": "m.room.message", + "content": { + "m.relates_to": { + "m.in_reply_to": { + "event_id": "$context" + } + }, + "msgtype": "m.text", + "body": "That looks like a great idea!" + } +} +``` + +Quite simply, extensible events use the same format: + +```json5 +{ + "type": "m.message", + "content": { + "m.relates_to": { + "m.in_reply_to": { + "event_id": "$context" + } + }, + "m.text": "That looks like a great idea!" + } +} +``` + +Edits are a bit more complicated, however. [MSC2676](https://github.com/matrix-org/matrix-doc/pull/2676) +defines edits which have a `rel_type` of `m.replace` and `m.new_content` in `content`. Extensible +events simply drop the fallback and move `m.new_content` up a level. + +An edited message would look similar to: + +```json5 +{ + "type": "m.message", + "content": { + "m.relates_to": { + "rel_type": "m.replace", + "event_id": "$original" + }, + "m.text": "That looks like a great idea!" + } +} +``` + +As mentioned, the fallback text (asterisk-prefixed message from MSC2676) is not present. This is to +follow the spirit of [MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781). + +For clarity, edits in this structure replace the entire event. This can technically mean that events +are able to change type, though this shouldn't have too many unintended side effects for rendering +in clients. For example, a message being replaced with a poll feels entirely valid (even if complicated +to represent in a client's UX). Going from a poll to a question is possible, though unlikely. + +In cases where the client wants to append/alter a reply to a message, it'd simply include both relation +types. Because they are non-conflicting by nature, this allows for a reply to be added, removed, or +changed. For example: + +```json5 +{ + "type": "m.message", + "content": { + "m.relates_to": { + "rel_type": "m.replace", + "event_id": "$original", + "m.in_reply_to": { + "event_id": "$context" + } + }, + "m.text": "That looks like a great idea!" + } +} +``` + +A downside of this system is that relation-requiring events, such as poll responses and reactions, +are not editable because the relation will be overridden. Other proposals, like +[MSC3051](https://github.com/matrix-org/matrix-doc/pull/3051), aim to change the relation structure +wholesale to account for these cases. For the purposes of extensible events, and this proposal, the +intention is that these relation-requiring events describe overload mechanics on their own. For +example, polls only take into consideration the most recent event while reactions effectively rely +upon redact & re-send approaches. + +## Potential issues + +As described, not being able to edit relation-requiring events is a bit unfortunate though managed +external to this proposal. + +Also as described, events can effectively change type under this system. This could have consequences +on systems like the [key verification framework](https://spec.matrix.org/v1.1/client-server-api/#key-verification-framework), +though those systems are typically built to be resilient against malicious attack. For example, key +verification will have already completed or could fail due to edits - clients will still need to +determine if the change is malicious, or if it is even valid, to potentially warn the user of bad +behaviour from their verification partner. A future MSC will aim to solve the key verification +framework for an extensible events world specifically. + +Lack of fallbacks could be concerning to some readers, particularly for edits, however given the +unique position of extensible events causing an ecosystem-wide change the risk is relatively minor. +Clients which don't implement `m.message` and similar event types will be left behind when the +ecosystem moves ahead with sending them after the transition period, which also means fallbacks +won't help them all that much. Clients which do support the new primary event types will potentially +have to do a bit of additional work to support replies and edits. + +To reiterate, this proposal affects new primary event types under the extensible events structure. +That includes `m.message`, but also affects extensible-first features like polls. Similar to the +argument that clients will be left behind for not implementing `m.message` and friends, clients +which are implementing extensible-first features should be expected to handle replies and edits as +per this proposal, though unstable implementations should note the details in the unstable prefix +section later on in this proposal. + +## Alternatives + +Edits could remain unchanged, however given a general desire to remove fallbacks from events and a +complete ecosystem change on events this feels like a great opportunity to take advantage of. Other +aspects of events that were previously thought to be unfixable might additionally be able to take a +similar approach. + +We could also introduce an `m.edit` or `m.reply` primary type, however this feels overly complicated +to implement given the relation type would be pulled away from the referenced event ID. Instead, we +risk allowing clients to change event types for generally improved event shape. + +## Security considerations + +Changing event types is potentially dangerous. Aside from the key verification framework, which is +planned to be looked at by a future MSC, the author is not aware of any likely conflicts that could +ocurr. All other event-based systems appear to be "fine" with being removed/replaced by completely +different event types, and the consequences for doing so are clear. For example, a poll being replaced +with a plain message means the poll results are lost. + +## Unstable prefix + +Unstable implementations of this MSC and extensible events in general should be wary that some clients +will not be completely aware of the new edits structure. Therefore, while unstable, those implementations +should treat `m.new_content` with higher priority if present on the replacement event. The semantics are +otherwise the same. + +This MSC otherwise does not introduce any functionality which requires a specific unstable namespace.