MSC4033: Explicit ordering of events for receipts

[andybalaam]

Rendered

Points out ambiguities in the current spec about what a receipt means, because it is not clear on the order of events that means they are "before" or "after" a receipt. Proposes that events and receipts contain an order property that makes it explicit which receipt marks which event as read.

Fixes https://github.com/matrix-org/matrix-spec/issues/1167

[bradtgmurray]

Funnily enough we at Beeper have been using this exact approach (com.beeper.hs.order field in the unsigned portion) in our Synapse fork and I can say it's been useful for simplifying client development: https://github.com/beeper/synapse/pull/42

We were also planning on putting an order on read receipts as well, but haven't gotten to it yet.

Great minds and all that.

[andybalaam]

Funnily enough we at Beeper have been using this exact approach (com.beeper.hs.order field in the unsigned portion) in our Synapse fork and I can say it's been useful for simplifying client development: beeper/synapse#42

We were also planning on putting an order on read receipts as well, but haven't gotten to it yet.

Great minds and all that.

That is great news. We can use this as evidence of an implementation, which will help this MSC to progress smoothly.

[andybalaam]

@bradtgmurray is the client code open source?

[bradtgmurray]

@bradtgmurray is the client code open source?

Unfortunately no

[bnjbvr]

As a SDK implementer, I am super interested in this proposal, as it could be useful for other purposes too, in addition to making computing the unread badges very simple. For instance, I think this would allow figuring whether we have gaps when reconciling a local/cached timeline of events with the results of a /messages query.

edit (2024-02-13): turns out this is not sufficient to figure out gaps, because the ordering number space has to have holes, so the HS can "always" insert events coming late from a laggy federated server.