Message order in Matrix: right now, we are deliberately inconsistent
Message ordering in the decentralized Matrix chat protocol exposes a tension between distributed-systems realities and user expectations of a single, consistent conversation history. Commenters argue over whether all clients should eventually show the same linear timeline, how to handle late or backdated messages after network splits, and what guarantees are needed to avoid confusion or even “gaslighting” when histories differ. Proposed approaches range from server-imposed total ordering and Lamport clocks to CRDT-style partial ordering and richer UI indicators for reordered or retroactively inserted messages.
Overall tension: consistency vs. decentralization
- Many argue that all up‑to‑date clients (at least on the same homeserver) should show a single, stable message order. Different orderings across clients are seen as confusing and “gaslighting.”
- Others say a globally consistent linear timeline is impossible or undesirable in a fully decentralized, federated system that must keep working through netsplits.
- There’s disagreement whether eventual consistency of history is mandatory (same ordering after resync) or whether it’s acceptable for different homeservers to retain permanently different views.
User expectations and UX
- Several commenters insist users expect:
- Messages to appear in send order.
- All participants (or at least all devices for one user) to see the same order.
- History not to silently reshuffle after they’ve read it.
- Others accept that simultaneous or delayed messages can reasonably appear in different orders per client, comparing it to phone calls or snail mail.
- Reordering after the fact is seen by some as more confusing than per‑client differences; by others as essential for shared understanding and legal/audit use.
Failures, retries, edits, and “past” messages
- Strong disagreement on whether a client should send later messages if an earlier one is stuck:
- One camp: hold later messages until the earlier succeeds or is deleted, to preserve intended order.
- Another: each message is its own unit of communication; out‑of‑order due to failures is tolerable.
- Editing old messages is widely accepted if edits are visible and auditable; backdating new messages into old history is seen as dangerous.
- Concern about long‑delayed messages (e.g., hours later) suddenly appearing in the “past” and confusing meaning or moderation.
Technical approaches discussed
- Ideas raised: server‑assigned sequence IDs, server timestamps, Lamport clocks, vector clocks, CRDTs, Raft/Paxos‑like consensus.
- Pushback:
- True global total order is impossible without centralization or heavy consensus.
- Vector clocks give only partial order; UX for that is hard.
- CAP constraints mean Matrix must favor availability, making strict consistency tricky.
Matrix‑specific notes and proposals
- Matrix’s current APIs (/sync vs /messages) can yield different orderings; this is seen as a spec/implementation bug more than a deep necessity.
- Some homeservers already use a single internal order (arrival‑based) for everything and report that it simplifies implementation and UX.
- Proposed UX ideas: visual indicators for “retconned” or out‑of‑order messages, per‑message sent/received timestamps, “jump to next unread inserted‑in‑the‑past” controls, or even git‑graph‑style visualizations for netsplits.