|
| 1 | +# MSCXXXX Loading Messages excluding Threads |
| 2 | + |
| 3 | +## Motivation |
| 4 | + |
| 5 | +In our beta deployment of threads, it's become a noticeable issue where a room may have activity in a long-running |
| 6 | +thread while the main timeline is inactive. If a user starts their client and tries to paginate through the main |
| 7 | +timeline, loading will feel sluggish, as lots of events have to be loaded that won’t be displayed. |
| 8 | + |
| 9 | +## Proposal |
| 10 | + |
| 11 | +### Allow filtering the /messages API to not include threaded messages |
| 12 | + |
| 13 | +This proposal recommends extending the existing [Event filters] are extended with a new filter, named |
| 14 | +`not_related_by_rel_types`, which acts exactly like the opposite of the existing `related_by_rel_types` filter. |
| 15 | + |
| 16 | +This means, if this filter is specified, only message which match none of the given relation types will be returned. |
| 17 | + |
| 18 | +``` |
| 19 | +GET /_matrix/client/v3/rooms/!room_id:domain/messages?filter=... |
| 20 | +``` |
| 21 | + |
| 22 | +The filter string includes the new fields, above. In this example, the URL encoded JSON is presented unencoded and |
| 23 | +formatted for legibility: |
| 24 | + |
| 25 | +```jsonc |
| 26 | +{ |
| 27 | + "types": ["m.room.message"], |
| 28 | + "not_related_by_rel_types": ["m.thread"] |
| 29 | +} |
| 30 | +``` |
| 31 | + |
| 32 | +Note that the newly added filtering parameters return events based on information in related events. Consider the |
| 33 | +following events in a room: |
| 34 | + |
| 35 | +* `A`: a `m.room.message` event sent by `alice` |
| 36 | +* `B`: a `m.room.message` event sent by `bob` |
| 37 | +* `C`: a `m.room.message` event sent by `charlie` which relates to `A` with type `m.thread` |
| 38 | + |
| 39 | +Using a filter of `"not_related_by_rel_types": ["m.thread"]` would return only event `B` as it has no event which |
| 40 | +relates to it via `m.thread`. |
| 41 | + |
| 42 | +### Server capabilities |
| 43 | + |
| 44 | +Threads might have sporadic support across servers, to simplify feature detections for clients, a homeserver must |
| 45 | +advertise unstable support for threads as part of the `/versions` API: |
| 46 | + |
| 47 | +```jsonc |
| 48 | +{ |
| 49 | + "unstable_features": { |
| 50 | + "org.matrix.mscXXXX": true, |
| 51 | + // ... |
| 52 | + } |
| 53 | +} |
| 54 | +``` |
| 55 | + |
| 56 | +## Potential issues |
| 57 | + |
| 58 | +This proposal moves the loading and processing of these hidden events onto the server. Depending on the server’s |
| 59 | +architecture, this may have a non-negligible performance impact. |
| 60 | + |
| 61 | +## Alternatives |
| 62 | + |
| 63 | +- A suitable workaround, depending on the ratio of thread-messages compared to main timeline messages in a room, may be |
| 64 | + an increase of the page size |
| 65 | + |
| 66 | +## Dependencies |
| 67 | + |
| 68 | +- [MSC2674](https://github.com/matrix-org/matrix-doc/pull/2674) |
| 69 | +- [MSC2675](https://github.com/matrix-org/matrix-doc/pull/2675) |
| 70 | +- [MSC3567](https://github.com/matrix-org/matrix-doc/pull/3567) |
| 71 | +- [MSC3676](https://github.com/matrix-org/matrix-doc/pull/3676) |
| 72 | +- [MSC3440](https://github.com/matrix-org/matrix-doc/pull/344ß) |
| 73 | + |
| 74 | +<!-- inline links --> |
| 75 | +[Event filters]: https://spec.matrix.org/v1.2/client-server-api/#filtering |
0 commit comments