From f34e69e8f9295aeee32b2eaeba604ae3c5e06af4 Mon Sep 17 00:00:00 2001 From: Germain Date: Wed, 31 May 2023 16:55:05 +0100 Subject: [PATCH 1/6] Create proposal for m.thread_id unsigned field --- proposals/4023-unsigned-thread-id.md | 60 ++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 proposals/4023-unsigned-thread-id.md diff --git a/proposals/4023-unsigned-thread-id.md b/proposals/4023-unsigned-thread-id.md new file mode 100644 index 00000000000..948638a6a19 --- /dev/null +++ b/proposals/4023-unsigned-thread-id.md @@ -0,0 +1,60 @@ +# MSC4023: Thread ID for 2nd order-relation + +[MSC3981](/~https://github.com/matrix-org/matrix-spec-proposals/pull/3981) defines +a way to recursively load relations in a thread context. However this does not +let clients determine with certainty in what timeline an event coming from a `/sync` +should end up in. + +If the related event is unknown to the client, the only way to partition things +correctly is to fetch the related event and confirm whether this event belongs to +a thread or not. + +This proposal wants to reduce the amount of work required for clients to partition +events with certainty in a time efficient manner. + +## Proposal + +All 2nd order-relation in a thread should add a `m.thread_id` property in their +`unsigned` field definition, referencing the thread root, as defined in MSC3440. + +```jsonc +{ + "m.thread_id": "$event_id" +} +``` + +Given the following diagram where `Reply1`, `Reply2` and `Reply3` are direct `m.thread` +relations. `Edit` and `Reaction` MUST include `m.thread_id` as defined in this +proposal. + +```mermaid +graph TD; + Edit-->Reply3 + Reaction-->Reply2 + Reply3-->Root + Reply2-->Root + Reply1-->Root +``` + +## Potential issues + +This could have performance implications on the server side, requiring more work +to be performed when fetching events in a room. + +## Alternatives + +If "[MSC3051: A scalable relation format](/~https://github.com/matrix-org/matrix-spec-proposals/pull/3051)" +was to be adopted, this MSC would be nulled. + +## Security considerations + +No security considerations + +## Unstable prefix + +While this MSC is not considered stable by the specification, implementations _must_ use +`org.matrix.msc4023.thread_id` in place of `m.thread_id`. + +## Dependencies + +This MSC does not have dependencies From d771c62d7257b9e76450d5961b34e8bbf7b7dd6c Mon Sep 17 00:00:00 2001 From: Germain Date: Fri, 2 Jun 2023 08:20:28 +0100 Subject: [PATCH 2/6] Update proposal wording Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/4023-unsigned-thread-id.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4023-unsigned-thread-id.md b/proposals/4023-unsigned-thread-id.md index 948638a6a19..5f9a91eaa57 100644 --- a/proposals/4023-unsigned-thread-id.md +++ b/proposals/4023-unsigned-thread-id.md @@ -14,7 +14,7 @@ events with certainty in a time efficient manner. ## Proposal -All 2nd order-relation in a thread should add a `m.thread_id` property in their +All 2nd order-relation events in a thread should add a `m.thread_id` property in their `unsigned` field definition, referencing the thread root, as defined in MSC3440. ```jsonc From 8699c341759a5585c7d77e3b733317bf0fba8d43 Mon Sep 17 00:00:00 2001 From: Germain Date: Fri, 2 Jun 2023 08:19:52 +0100 Subject: [PATCH 3/6] Rename 'm.thread_id' to 'thread_id' --- proposals/4023-unsigned-thread-id.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/4023-unsigned-thread-id.md b/proposals/4023-unsigned-thread-id.md index 5f9a91eaa57..7bb91d2a032 100644 --- a/proposals/4023-unsigned-thread-id.md +++ b/proposals/4023-unsigned-thread-id.md @@ -14,17 +14,17 @@ events with certainty in a time efficient manner. ## Proposal -All 2nd order-relation events in a thread should add a `m.thread_id` property in their +All 2nd order-relation events in a thread should add a `thread_id` property in their `unsigned` field definition, referencing the thread root, as defined in MSC3440. ```jsonc { - "m.thread_id": "$event_id" + "thread_id": "$event_id" } ``` Given the following diagram where `Reply1`, `Reply2` and `Reply3` are direct `m.thread` -relations. `Edit` and `Reaction` MUST include `m.thread_id` as defined in this +relations. `Edit` and `Reaction` MUST include `thread_id` as defined in this proposal. ```mermaid @@ -53,7 +53,7 @@ No security considerations ## Unstable prefix While this MSC is not considered stable by the specification, implementations _must_ use -`org.matrix.msc4023.thread_id` in place of `m.thread_id`. +`org.matrix.msc4023.thread_id` in place of `thread_id`. ## Dependencies From 036666c79178dae3d2d7b839ad7e0232a94102da Mon Sep 17 00:00:00 2001 From: Germain Date: Fri, 2 Jun 2023 08:30:22 +0100 Subject: [PATCH 4/6] Require all events to inform the unsigned thread_id property --- proposals/4023-unsigned-thread-id.md | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/proposals/4023-unsigned-thread-id.md b/proposals/4023-unsigned-thread-id.md index 7bb91d2a032..75422dd27a2 100644 --- a/proposals/4023-unsigned-thread-id.md +++ b/proposals/4023-unsigned-thread-id.md @@ -14,8 +14,9 @@ events with certainty in a time efficient manner. ## Proposal -All 2nd order-relation events in a thread should add a `thread_id` property in their -`unsigned` field definition, referencing the thread root, as defined in MSC3440. +All events in a thread and the 2nd order-relation events should add a `thread_id` +property in their `unsigned` field definition, referencing the thread root – as +defined in MSC3440. ```jsonc { @@ -23,18 +24,8 @@ All 2nd order-relation events in a thread should add a `thread_id` property in t } ``` -Given the following diagram where `Reply1`, `Reply2` and `Reply3` are direct `m.thread` -relations. `Edit` and `Reaction` MUST include `thread_id` as defined in this -proposal. - -```mermaid -graph TD; - Edit-->Reply3 - Reaction-->Reply2 - Reply3-->Root - Reply2-->Root - Reply1-->Root -``` +All events that are not part of a thread should fill the `thread_id` property with +the special value `main` – as defined in MSC3771. ## Potential issues From fc9a8c4cd9b6d6338e42a70b3d8c44ae20256e1b Mon Sep 17 00:00:00 2001 From: Germain Date: Fri, 2 Jun 2023 08:52:23 +0100 Subject: [PATCH 5/6] Document edge case with missing first-order relation --- proposals/4023-unsigned-thread-id.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/proposals/4023-unsigned-thread-id.md b/proposals/4023-unsigned-thread-id.md index 75422dd27a2..f0c539e238d 100644 --- a/proposals/4023-unsigned-thread-id.md +++ b/proposals/4023-unsigned-thread-id.md @@ -1,4 +1,4 @@ -# MSC4023: Thread ID for 2nd order-relation +# MSC4023: Thread ID for second-order relation [MSC3981](/~https://github.com/matrix-org/matrix-spec-proposals/pull/3981) defines a way to recursively load relations in a thread context. However this does not @@ -14,7 +14,7 @@ events with certainty in a time efficient manner. ## Proposal -All events in a thread and the 2nd order-relation events should add a `thread_id` +All events in a thread and the second-order relation events should add a `thread_id` property in their `unsigned` field definition, referencing the thread root – as defined in MSC3440. @@ -27,11 +27,24 @@ defined in MSC3440. All events that are not part of a thread should fill the `thread_id` property with the special value `main` – as defined in MSC3771. +If a server does not have the first-order event, the unsigned `thread_id` property +should be filled with a `null` value. When the server gets a hold of the first-order +event, it should retroactively update the `thread_id` property and communicate the +change to clients. + ## Potential issues +### Database query performances + This could have performance implications on the server side, requiring more work to be performed when fetching events in a room. +### Missing first-order relation + +It is possible that a server will have the second-order event, but not have the +first-order event (eg, it has received a reaction over federation, but has not +yet received the event being reacted to). + ## Alternatives If "[MSC3051: A scalable relation format](/~https://github.com/matrix-org/matrix-spec-proposals/pull/3051)" From 541f210b352c03d87f8dd33e4da998c338d8193a Mon Sep 17 00:00:00 2001 From: David Baker Date: Wed, 6 Dec 2023 15:05:42 +0000 Subject: [PATCH 6/6] Rewrite some parts of this MSC for clarity and address feedback. --- proposals/4023-unsigned-thread-id.md | 37 +++++++++++++++------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/proposals/4023-unsigned-thread-id.md b/proposals/4023-unsigned-thread-id.md index f0c539e238d..336010bcf7d 100644 --- a/proposals/4023-unsigned-thread-id.md +++ b/proposals/4023-unsigned-thread-id.md @@ -1,26 +1,29 @@ # MSC4023: Thread ID for second-order relation -[MSC3981](/~https://github.com/matrix-org/matrix-spec-proposals/pull/3981) defines -a way to recursively load relations in a thread context. However this does not -let clients determine with certainty in what timeline an event coming from a `/sync` -should end up in. - -If the related event is unknown to the client, the only way to partition things -correctly is to fetch the related event and confirm whether this event belongs to -a thread or not. +Events that have a non-thread relation to other events (eg. reactions) are +considered to be in the thread that their parent event is in. +[MSC3981](/~https://github.com/matrix-org/matrix-spec-proposals/pull/3981) +defines a way to recursively load such relations with the `/relations` API +but for such events, it is impossible for a client to know what thread the +event is in when it arrives from `/sync` unless it already has, or fetches, +the parent event. This means performing another client-server API request to +fetch the parent event which is inefficient. This proposal wants to reduce the amount of work required for clients to partition -events with certainty in a time efficient manner. +events with certainty. ## Proposal -All events in a thread and the second-order relation events should add a `thread_id` -property in their `unsigned` field definition, referencing the thread root – as -defined in MSC3440. +Whenever a server returns events in the client-server API, it adds a `thread_id` +property to the `unsigned` field of the event with the ID of the event's thread root +as defined in MSC3440. This applies to any endpoint that returns events including +`/sync` and `/messages`. ```jsonc { - "thread_id": "$event_id" + "unsigned": { + "thread_id": "$event_id" + } } ``` @@ -28,9 +31,7 @@ All events that are not part of a thread should fill the `thread_id` property wi the special value `main` – as defined in MSC3771. If a server does not have the first-order event, the unsigned `thread_id` property -should be filled with a `null` value. When the server gets a hold of the first-order -event, it should retroactively update the `thread_id` property and communicate the -change to clients. +should be filled with a `null` value. ## Potential issues @@ -48,7 +49,9 @@ yet received the event being reacted to). ## Alternatives If "[MSC3051: A scalable relation format](/~https://github.com/matrix-org/matrix-spec-proposals/pull/3051)" -was to be adopted, this MSC would be nulled. +were to be adopted, second-order relations could specify their thread directly as one of the relationships, +in which case this MSC would become unnecessary. However, that MSC is a longer term evolution of the protocol +and will take time for the ecosystem to adopt. This MSC is intended as a much shorter term fix. ## Security considerations