Merge bbdf895a1c into d6edcbd946
Travis Ralston
4 weeks ago
committed by
GitHub
commit
f7be1ca547
@ -0,0 +1,177 @@
|
||||
# MSC3644: 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
|
||||
occur. 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.
|
||||
Loading…
Reference in New Issue