MSC4282: Interactive /rooms/ROOM_ID/messages (Client-Server API) #4282
Conversation
bnjbvr
changed the title
bnjbvr
force-pushed
the
bnjbvr/interactive-roommessag
branch
from
81bad95 to
eaf7052
Compare
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
turt2live
added
kind:maintenance
|
Added a note that the hint may be ignored in a specific case to avoid wasting CPU and bandwidth resources, after a discussion with @deepbluev7 (thanks!). |
| ## Proposal | ||
|
|
||
| It is proposed that the `/rooms/{room_id}/messages` endpoint be modified to allow clients to | ||
| specify a new boolean query parameter `interactive`, which indicates that the client is interested |
There was a problem hiding this comment.
I think you also need to define the unstable prefix to use by implementations while this MSC has not been accepted. It's typically done in a section at the very end of the proposal.
| Instead of an additional query parameter, this MSC could mandate that this becomes the expected | ||
| behavior of all the implementations. This would be an implicit breaking change, and it may inhibit | ||
| use cases where clients might prefer a perfectly backfilled room over a quick response time. |
There was a problem hiding this comment.
Related MSC for indicating gaps in the timeline: MSC3871
If we indicated gaps in the /messages, we could respond quickly always as a default and clients can handle displaying and filling in the gaps as necessary.
There was a problem hiding this comment.
This was explored further during the recent Element Hackathon ("How Hard Could It Be?") with an initial implementation in Synapse -> element-hq/synapse#18873
For the hack day, I'll be tackling the backfill problem with this strategy:
- Default to fast responses with gaps: As a default, we can always respond quickly and indicate gaps (MSC3871) for clients to paginate at their leisure.
- Fast back-pagination: Clients back-paginate with
/messages?dir=b&backfill=false, and Synapse skips backfilling entirely, returning only local history with gaps as necessary.- Explicit gap filling: To fill in gaps, clients use
/messages?dir=b&backfill=truewhich works just like today to do a best effort backfill.This allows the client to back-paginate the history we already have without delay. And can fill in the gaps as they see fit.
Gaps can be represented in the UI with a message like "We failed to get some messages in this gap, try again 🗘.", giving users clear feedback. Regardless of clients trying to fill in gaps automatically, I would still suggest to display gaps so people can tell what's happening.
This is basically a simplified version of MSC4282 leveraging MSC3871: Gappy timelines to get proper client feedback to indicate where the gaps are so we can skip backfill without worrying. For reference, skipping backfill without letting clients know where the gaps are just means they won't ever know that they are missing messages.
-- @MadLittleMods, https://github.com/element-hq/how-hard-can-it-be-2025/issues/47#issuecomment-3234339497
github-project-automation
bot
moved this to Tracking for review
in Spec Core Team Workflow
turt2live
moved this from Tracking for review
to Ready for general review
in Spec Core Team Workflow
turt2live
moved this from Ready for general review
to Ready for FCP ticks
in Spec Core Team Workflow
| the back-pagination request later. | ||
| - otherwise, the server shall immediately return events it had in its local state, and if needed it | ||
| shall start a backfill request in the background (so the next request has chances to complete | ||
| quickly, be it interactive or not). |
There was a problem hiding this comment.
The problem is that there might be gaps, and we currently have no way of telling clients that there might be a gap (nor then allowing the client to request the server fetch messages in the gap).
We could have a flag where we immediately stop if there is a gap, which could speed up the /messages done after a SSS initial room, but I don't think would help in the general case of backpagination.
There was a problem hiding this comment.
msc3871 is the msc for relaying gaps to clients
turt2live
moved this from Ready for FCP ticks
to Proposed for FCP readiness
in Spec Core Team Workflow
To try out the flow:
- **Default to fast responses with gaps**: As a default, we can always
respond quickly and indicate gaps ([MSC3871]
(matrix-org/matrix-spec-proposals#3871)) for
clients to paginate at their leisure.
- **Fast back-pagination**: Clients back-paginate with
`/messages?dir=b&backfill=false`, and Synapse skips backfilling
entirely, returning only local history with gaps as necessary.
- **Explicit gap filling**: To fill in gaps, clients use
`/messages?dir=b&backfill=true` which works just like today to do a best
effort backfill.
This allows the client to back-paginate the history we already have without
delay. And can fill in the gaps as they see fit.
This is basically a simplified version of [MSC4282]
(matrix-org/matrix-spec-proposals#4282).
7 participants
Rendered.
TL;DR: in the client-server API,
/rooms/ROOM_ID/messagescan be slow, and clients need a way to express that they want a quick response for an interactive user session.Kudos to @kegsay for the original idea.
Disclosure: I am a Matrix community member, and also employed by Element to work on the Matrix Rust SDK. This proposal is written and published as an Element employee.