Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misc clarifications to threading MSCs #3899

Merged
merged 3 commits into from
Sep 27, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions proposals/3440-threading-via-relations.md
Original file line number Diff line number Diff line change
Expand Up @@ -51,12 +51,14 @@ would include additional information in the `unsigned` field:
}
```

* `latest_event`: The most recent event which relates to this event, with
`rel_type` of `m.thread`.
* `latest_event`: The most recent event (topologically) which relates to this event, with
`rel_type` of `m.thread`. Events sent by [ignored users](https://spec.matrix.org/v1.3/client-server-api/#ignoring-users)
are not considered for the latest event.
Comment on lines +54 to +56
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this over Matrix, it makes sense to make this explicit here, but it really is just following the guidance of MSC2675:

Information about relations sent from ignored users must never be sent to the client, either in aggregations or discrete relation events. This is to let you block someone from harassing you with emoji reactions (or using edits as a side-channel to harass you). Therefore, it is possible that different users will see different aggregations (a different last edit, or a different reaction count) on an event.


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
* `count`: An integer counting the number of `m.thread` events, excluding events sent
by [ignored users](https://spec.matrix.org/v1.3/client-server-api/#ignoring-users).
* `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.
Expand Down
2 changes: 1 addition & 1 deletion proposals/3715-relations-parity-messages.md
Original file line number Diff line number Diff line change
Expand Up @@ -75,7 +75,7 @@ previous calls (as well as `next_batch` values, as is currently specified). The
[definition of the `from` parameter](https://spec.matrix.org/unstable/client-server-api/#get_matrixclientv1roomsroomidrelationseventid)
is updated:

> Can be a `from_batch` token **or `next_batch`** token from a previous call, or a
> Can be a `next_batch` token **or `prev_batch`** token from a previous call, or a
> returned `start` token from `/messages`, or a `next_batch` token from `/sync`.

(Bold indicates new text.)
Expand Down
4 changes: 4 additions & 0 deletions proposals/3856-threads-list-api.md
Original file line number Diff line number Diff line change
Expand Up @@ -113,6 +113,10 @@ slightly. This has two situations:
non-ignored user; with the caveat that the ordering of the threads is not
re-arranged due to this replacement.

Like [`/messages`](https://spec.matrix.org/v1.3/client-server-api/#get_matrixclientv3roomsroomidmessages),
this returns a 403 `M_FORBIDDEN` error response if the caller isn't able to see the
room's history.

#### Example request:

```
Expand Down