You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec-proposals/proposals/3567-optional-from-on-messa...

2.6 KiB

MSC3567: Allow requesting events from the start/end of the room history

It can be useful to request the latest events in a room directly without calling /_matrix/client/v3/sync first to fetch the room state. Some use-cases include:

  • Requesting events using a different filter after receiving a /sync response.
  • A client which does not need to fully sync an account, but wishes to inspect a specific room's history (perhaps for exporting or auditing).

Proposal

The from field on the /_matrix/client/v3/rooms/{roomId}/messages becomes optional. If it is not provided, the homeserver shall return a list of messages from the first or last (per the value of the dir parameter) visible event in the room history for the requesting user.

Note that Synapse already implements this, but it is not spec-compliant. It is known to be used by Element Android 1 and Element Web, and there are other use-cases involving threads 2, which shows real-world usage that this would be valuable.

Ideally this would not be necessary and the prev_batch token received from calling /sync could be provided as the pagination token to /messages, but this will not work if you /sync with a filter that excludes a given class of event (such as threaded replies), and all the events taking place in a room are of that class. This will result in your /sync not returning an update for that room, which means that your most recent prev_batch token precedes all the excluded events. Trying to back-paginate from prev_batch using /messages will not result in seeing the excluded events.

Potential issues

None.

Alternatives

The alternative is today's status quo: a client must first make a request to /_matrix/client/v3/sync and then follow-up that request with queries to /_matrix/client/v3/rooms/{roomId}/messages. This is clunky if the client is going to throw away most of the information received from the /sync request.

The behavior also seems undefined if a different filter parameter is provided for the call to /sync compared to the one used for /messages.

Security considerations

None.

Unstable prefix

Since this is modifying the endpoint to support not including a field, no unstable prefix is necessary.

Dependencies

N/A


  1. https://github.com/matrix-org/synapse/issues/5538 ↩︎

  2. In order to list all threads in a room without pulling the history locally it uses /messages to push the filtering onto the homeserver. See https://github.com/matrix-org/matrix-js-sdk/pull/2065 ↩︎