From 4160b4bceb65eb3f25398541bf08f2e1764c12bd Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 5 Mar 2021 18:43:15 +0100 Subject: [PATCH] MSC0000: scalable relation format Signed-off-by: Nicolas Werner --- proposals/0000-scalable-relations.md | 114 +++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 proposals/0000-scalable-relations.md diff --git a/proposals/0000-scalable-relations.md b/proposals/0000-scalable-relations.md new file mode 100644 index 00000000000..cabe12bfd98 --- /dev/null +++ b/proposals/0000-scalable-relations.md @@ -0,0 +1,114 @@ +# MSC0000: Scalable relations + +Edits, reactions, replies, threads, message annotations and other MSCs have +shown, that relations between events are very powerful and useful. Currently the +format from [MSC2674](https://github.com/matrix-org/matrix-doc/pull/2674) is +used. That format however limits each event to exactly one relation. As a result +events rely on other ways to represent secondary relations. For example edits +keep the relation from the previous event. Their support to change or delete +that relation is limited. In theory you could pass that in `m.new_content`, but +clients don't seem to support that and the actual deletion of a relation is +unexplored as well. + +There are many cases where 2 or more relations on an event would be useful. This +MSC proposes a simple way to do that and replace the currently proposed format. + +## Proposal + +To support multiple relations per file this MSC proposes the following format: + +```json +{ + "content": { + "m.relations": [ + { + "event_id": "$some-other-event", + "rel_type": "m.in_reply_to" + }, + { + "event_id": "$some-third-event", + "rel_type": "m.replaces" + }, + { + "event_id": "$event-four", + "rel_type": "org.example.custom_relation", + "key": "some_aggregation_key" + } + ] + }, + "event_id": "$something", + "type": "m.room.message" +} +``` + +This has a few benefits: + +- You can relate to multiple events at the same time. (I.e. you have a + description for multiple files you sent.) +- You can have multiple different relation types at once. (I.e. an edit, that + is also a reply, or a reaction inside a thread.) +- You don't need to look up reply relations in multiple events for edits. The + edited event is canonical and can be used standalone, without having to look + up the original event to figure out, what was replied to. You can also remove + a relation with an edit now. (Useful if you replied to the wrong message or + didn't mean to reply to anyone.) +- This format is conceptually a lot simpler, if an event has multiple relations. + You don't run into issues with packing relations into `m.new_content`, + especially for encrypted events, etc. You just have a list of relations. + +If clients want to stay backwards compatible (for a while at least), in many +instances it is possible to generate an `m.relates_to` object from the relations +list. This can be done by picking a primary relation, i.e. the edit relation, +and then packaging up the remaining relations in `m.new_content` or simply +throwing them away. Since this proposal uses `m.relations`, this does not +conflict with the current relations from the other MSCs. One can also generate +the relations object from this MSC from the old relations, since the new +relations are a strict superset, which may be useful to make handling inside of +a client easier. + +## Potential issues + +### Ordering + +The list of relations is not hierarchical. As such there is no order like where +you have a top level relation and a lower level relation like an edit having +priority over a reply. + +I don't believe that is an issue in practice. If you edit a message with a +reply, there is a natural meaning to the combination of both relations. You can +even apply them in any order, imo. But there may be other relations, where this +causes more issues. An MSC introducing such a relation should specify how to +handle conflicts then. + +### Conflicting relations + +Some relation types should probably not be combined. For example you may +disallow editing a reaction, because clients probably won't be handling that +correctly. This MSC however does not disallow that. Relations should specify, +how clients should handle that and clients sending such combinations should be +aware, that those probably won't get handled. I don't think just allowing 1 +relation is the solution to handling such conflicts and I don't think they will +happen much in practice. + +## Alternatives + +- We could just stick with the existing proposal to only have 1 relation per + event. This is obviously limiting, but works well enough for a lot of + relation types. +- There are a few other ways to structure relations like using an object instead + of an array, etc. I believe this is the most usable one. + +## Security considerations + +Multiple releations may increase load on the server and the client and provide +more opportunities to introduce bad data. Servers and clients should take +additional care and validate accordingly. It should not be considerably worse +than single relations though and servers may limit relations to a reasonable +amount (like they do for devices already). + +## Unstable prefix + +Clients should use `im.nheko.relations.v1.relations` instead of `m.relations` +and `im.nheko.relations.v1.in_reply_t` as the relation type for replies in the +mean time. +