Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

artificialworlds.net

Post reply on HN
Print view View original

91–100 of 119 posts

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

#91

Post by Kwpolska »

kevincox wrote: post #63
deredede wrote: post #37

Earlier quoted context omitted.

> 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. That…

> I intuitively understand that if we both write messages at the same time, we will see them in different order. I think you are thinking like a distributed systems designer. I would assume that if you asked 10 "random Americans" 9 of them would assume that someone managed to send their message first and would be surprised if their phone and their friends phone showed them messages in different orders.

I would assume 9 of them would not care either way.

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

#92

Post by amstan »

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] https://uhoreg.gitlab.io/matrix-tutorial/sync.html#:~:text=w...

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

#93

Post by agos »

adastra22 wrote: post #12
winwang wrote: post #9

Earlier quoted context omitted.

I break up my messages, as do many people.

Do you do so with the expectation that they might arrive out of order, or one fails?

I do so with the expectation that they should arrive in order if no one fails, but apparently it is "debatable" if this is a reasonable expectation

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

#94

Post by agos »

throwaway14356 wrote: post #14

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 b…

I remember when iMessage/Apple Messages did this, back in its first days. Everybody hated it.

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

#95

Post by immibis »

kelnos wrote: post #83
lmm wrote: post #72

Earlier quoted context omitted.

> When IRC federation breaks, everyone can see it, except for the rare people who aren't in a shared channel with anyone on the other side of the break. Well sure, you could see that something was going on, if you were paying attention. But how does that solve the problem? Does your IRC client stop you from sending messages if it detects a netsplit?

I don't think IRC is a good analogy here because there's no "message resync" that happens when the netsplit is resolved. If there are two people on opposite sides of a split, and they both send messages to a channel while things are still split, they will not see the other's messages when the split is over. In the Matrix case, if a homeserver disappears for a while, it will sync any missed messages when it comes back…

Which is a design deficiency when those messages are 6 months old, and are spam, from people who got banned 5 months ago.

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

#96

Post by zarzavat »

deredede wrote: post #37
danpalmer wrote: post #3

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…

> 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. That…

You need to know what ordering the other user is seeing, otherwise dangerous misunderstandings could result, for example you reply "yes" but it's in reply to a different message than the other side is seeing.

If I see that another message has arrived and my message could be misunderstood, I can correct that by sending another message. But if I don't know what ordering the other side is seeing then I don't know if my message is ambiguous or not.

The only way achieve that is to show a consistent ordering to both participants (or to force every message to be in reply to another message but that's too nerdy)

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

#97

Post by rkangel »

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.

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

#98

Post by shawnz »

kiitos wrote: post #87
shawnz wrote: post #16

Earlier quoted context omitted.

How far back should you be able to amend history? What if a malicious client adds messages to a conversation that happened in the past? Imagine for example I'm at work and notice a critical mistake that I missed, and so I retroactively add messages to the old conversation to make it look like I'm not liable, should that be permitted by the protocol?

> How far back should you be able to amend history? If user U1 sends a message M1 at time T1, then U1 must be able to modify/delete that message M1, in some reasonable sense, at any conceivable time from T1 forwards. Any protocol that doesn't support some reasonable form of message modification/deletion in this sense, is a toy protocol, and will never be widely adopted.

I'm not talking about message editing but rather posting new messages with a backdated time.

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

#99

Post by shawnz »

kelnos wrote: post #82
shawnz wrote: post #16

Earlier quoted context omitted.

How far back should you be able to amend history? What if a malicious client adds messages to a conversation that happened in the past? Imagine for example I'm at work and notice a critical mistake that I missed, and so I retroactively add messages to the old conversation to make it look like I'm not liable, should that be permitted by the protocol?

This shouldn't be an issue for systems where a server mediates communication: the server should be timestamping messages, not the clients. This could indeed be a potential problem for a decentralized system, or one where the server for some reason cannot (or cannot be trusted to) timestamp messages. In that case, I think the best behavior for a client would be to always display messages in the order they've arrived,…

If you don't allow the client to specify the time they sent the messages, then anyone who has a poor connection is going to be subject to an annoying behaviour where their messages are constantly going out of the intended order during busy conversations.

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

#100

Post by dzaima »

rkangel wrote: post #97

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 continu…

That "presentation issue" is quite an issue though; how do you sanely present to a user the fact that there are new messages to read, but they're scattered throughout the history of the message log arbitrarily far back?

Granted, tacking them all at the end isn't necessarily good, but at least the user will see them, and timestamp indicators can help make sense of it.

And I don't even see how placing them chronologically would be particularly useful - given a netsplit there's not gonna be any relation between the previously-present and delayed-received messages at that time interval anyway, you're just interleaving two entirely different discussions for no reason. (ok maybe there can be some unidirectional delay where it could maybe be useful, idk)

Post reply on HN