Message order in Matrix: right now, we are deliberately inconsistent

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.