From f6f3299b0d1685e3067f0538345545d6beef4c4f Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Sun, 5 Jun 2022 14:14:08 -0400 Subject: [PATCH] MSC3816: Clarify Thread Participation (#3816) * Clarify the current_user_participated flag from MSC3440. * Add a better link to the definition. * Clarifications from review. Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/3440-threading-via-relations.md | 6 +- .../3816-clarify-thread-participation.md | 73 +++++++++++++++++++ 2 files changed, 77 insertions(+), 2 deletions(-) create mode 100644 proposals/3816-clarify-thread-participation.md diff --git a/proposals/3440-threading-via-relations.md b/proposals/3440-threading-via-relations.md index 7692ee1d..af750ddf 100644 --- a/proposals/3440-threading-via-relations.md +++ b/proposals/3440-threading-via-relations.md @@ -57,8 +57,10 @@ would include additional information in the `unsigned` field: The latest event should be serialised in the same form as the event itself; this includes adding any bundled aggregations for the event (and applying edits).[^1] * `count`: An integer counting the number of `m.thread` events -* `current_user_participated`: A flag set to `true` if the current logged in user - has participated in the thread +* `current_user_participated`: A boolean flag, which is set to `true` if the + current logged in user has participated in the thread. The user has participated if: + * They created the current event. + * They created an event with a `m.thread` relation targeting the current event. #### Rich replies in a thread diff --git a/proposals/3816-clarify-thread-participation.md b/proposals/3816-clarify-thread-participation.md new file mode 100644 index 00000000..32de2565 --- /dev/null +++ b/proposals/3816-clarify-thread-participation.md @@ -0,0 +1,73 @@ +# MSC3816: Clarify Thread Participation + +[MSC3440](https://github.com/matrix-org/matrix-doc/pull/3440) defines the `m.thread` relation +type, and the format of the serverside aggregation for them. The definition of the aggregation includes a +`current_user_participated` flag, which is not fully defined: + +> A flag set to `true` if the current logged in user has participated in the thread + +In particular, it is unclear whether sending the initial event (i.e., the event which is the +target of the `m.thread` relation) counts as participating in the thread. + +Known implementations do *not* count the initial event in this way, and instead +implement this as: "has the current user sent an event with an `m.thread` relation +targeting the event", but this has found to give poor user experience in practice. + +For example, consider `A` as the root event in a thread from `@alice:example.com`, and `B` +as a threaded reply from `@bob:example.com`. The bundled aggregations for `A` +would include: + +| Requester | `current_user_participated` | +|----------------------|-----------------------------| +| `@alice:example.com` | `false` | +| `@bob:example.com` | `true` | + +If `@alice:example.com` sends reply `C`, this would change: + +| Requester | `current_user_participated` | +|----------------------|-----------------------------| +| `@alice:example.com` | `true` | +| `@bob:example.com` | `true` | + +The proposed clarification is that `@alice:example.com` should have always have +participated in the thread (i.e. both tables would be `true` in the example above). + +## Proposal + +The [definition of the `current_user_participated` flag](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/3440-threading-via-relations.md#event-format) +from the bundled aggregations for `m.thread` relations is updated: + +> A boolean flag, which is set to `true` if the current logged in user has +> participated in the thread. The user has participated if: +> +> * They created the current event. +> * They created an event with a `m.thread` relation targeting the current event. + +This better matches the intention of this flag, which is that a client is able to +visually separate threads which might be of interest. + +## Potential issues + +The current implementations will need to be updated to take into account the +sender of the current event when generating bundled aggregations. This should be +trivial since all of the needed information is directly available. + +MSC3440 proposes using [new `filter` parameters](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/3440-threading-via-relations.md#fetch-all-threads-in-a-room) +in order to list threads in a room that a user has participated in. There would +now be an inconsistency that threads where the current user sent the root event +but has not replied to the thread could not easily be fetched. A future MSC may +solve this problem. + +## Alternatives + +Do not clarify [MSC3440](https://github.com/matrix-org/matrix-spec-proposals/pull/3440) +and leave it up to implementations to define the behavior of the +`current_user_participated` flag. + +## Security considerations + +None + +## Unstable prefix + +None, the changes above shouldn't dramatically change behavior for clients.