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>richvdh-patch-1
parent
46ae23744e
commit
f6f3299b0d
@ -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.
|
Loading…
Reference in New Issue