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

136 点作者 whereistimbo5 个月前

11 条评论

I'm the author of the spec issue this blog post is based on: <a href="https://github.com/matrix-org/matrix-spec/issues/852">https://github.com/matrix-org/matrix-spec/issues/852</a>In my implementation for the Conduit Matrix server, the /sync order is used for everything. The timeline is just one list that grows on one end for incoming events and on the other end for backfilled events.I think it's important that the message order does not change, because that's very difficult to communicate to the user.

评论 #42340620 未加载

评论 #42325836 未加载

danpalmer5 个月前

This is something that many chat apps get wrong and I'm not sure this article is moving in the right direction. The UX is fairly clear in my mind:1. All up-to-date clients should be displaying the same message order. 2. A single client should not send messages in the wrong order.Yes a client may be out of date and therefore show something different, but once it becomes up to date it should be showing the same state even if that means amending history. Why? Because the humans reading it will be confused otherwise! An app getting more data is something we intuitively understand, but if my client shows something and yours shows something else, we will conclude different meanings from it.Additionally there are some clients that treat each message input by the user as a retriable thing in isolation, which is also clearly incorrect. If I send two messages and the first fails to go through, I almost certainly don't want to retry the second until the first has gone through, otherwise my client has literally sent out of order messages! I use Beeper for chat and this is one of the most frustrating things it does.

评论 #42335067 未加载

评论 #42325584 未加载

评论 #42329237 未加载

评论 #42324955 未加载

评论 #42325002 未加载

Vanit5 个月前

I'm throwing some shade here, but this reeks of backend engineers not caring about UX.

评论 #42325748 未加载

thomastay5 个月前

Having dealt with this problem at work for several years now, I feel the pain of keeping different clients in sync - it's extremely difficult. Not sure if it's possible in Matrix, but consider having a message ID that increments by one on every message in a room. That lets the client know pretty quickly if there's a gap or a misordering.Not really getting this point though:<pre><code> The /sync API returns events in an order "according to the arrival time of the event on the homeserver". The spec for /messages says it returns events "in chronological order. (The exact definition of chronological is dependent on the server implementation.)". </code></pre> Why would those two return different results? When does the chronological order of two messages differ from the arrival time of the event on the homeserver?

评论 #42324919 未加载

评论 #42324970 未加载

评论 #42324911 未加载

评论 #42324899 未加载

lmm5 个月前

In general we certainly want to be able to change things "in the past". When there is unpleasant spam in a groupchat, you want a moderator to be able to remove or at least hide it, in a way that means people scrolling up won't be exposed to it unless they explicitly want to. (You could argue for having the client deal with all of that, but I don't think there's much benefit).And if, as in the example at the end, clients on different homeservers will inevitably see different views, then I don't think always showing the same history to the same client, or clients on the same server, solves the "gaslighting" problem - if anything it could make it worse. Maybe clients should make it obvious when messages have been "retconned" into the scrollback, and maybe servers should have certain features to support that. But the idea of having a consistent linear timeline is one of those answers that's clear, simple, and wrong.

rkangel5 个月前

This article makes a logical step that I think is incorrect - that message order from the server is the order that a client then displays them in.Surely that's a presentation issue - you should display messages chronologically, regardless of what order you got them from the server? The author does touch on this a little bit, I don't see how that isn't the "obviously" correct approach?:> An alternative is to continue providing events in any order, but add some kind of order number that allows clients to sort events into /sync order. MSC4033 proposes this.

评论 #42338913 未加载

Saris5 个月前

That's something that Telegram always seems to get right, I've never seen messages out of order in different clients, and if I do something like upload a video then immediately send more text messages before it's done, it will shove the video in between the messages where it should be when the upload is done.I know it's a much harder problem without a central server managing things. But consistency is very important for messages, out of order they could have a very different meaning and be very confusing.

评论 #42334426 未加载

throwaway143565 个月前

i had a hilarious argument with the significant other when my messages appeared a very lame response to messages i didn't receive.i think the mental model should be what is most useful in court. if a netsplit occurs the state of the room doesn't exist anymore, conversation can continue but it should be a different room populated with working available clients. The main room can be restored and the missed convo can be a 3rd room

评论 #42337939 未加载

Terr_5 个月前

My preference would be to avoid even attempting to force all into a single chronology. Instead, imagine something like the output of `git log --graph`, where the network split/rejoin moments are also displayed by lines. It would allow people to tell that two independent conversations were going on, and that certain messages were written while another was not known.

shepherdjerred5 个月前

This sounds like a pretty good use case for a consensus algorithm like Paxos or Raft

评论 #42325600 未加载

评论 #42325598 未加载

amstan5 个月前

It's infuriating how the client must be stateful and have local storage, for both the access_token and the last message recieved. That's right you must remember as the client where the last events [1] you've seen (even if you already told the server to mark it as read) was or else the server will happily send you the same messages over and over again across restarts of your client. I kind of miss making IRC bots where things were much simpler and ... quicker honestly (latency wise).[1] <a href="https://uhoreg.gitlab.io/matrix-tutorial/sync.html#:~:text=w" rel="nofollow">https://uhoreg.gitlab.io/matrix-tutorial/sync.html#:~:text=w</a>...