Events with massaged timestamps are ordered by time received

[samczsun]

I want to massage timestamps on m.room.message events so I can insert historical messages. These messages are ordered by time received instead of origin_server_ts, which makes it very hard to tell when a message was actually sent without mousing over each message and inspecting the timestamp.

I'm aware that timestamp massaging isn't officially in the spec yet, but hopefully this isn't too complex a bug to fix (or if you can point me in the right direction, I'm happy to give it a shot)

[t3chguy]

This isn't a riot issue. The matrix sync api returns them in the order the server received them (dag ordering)

[rubo77]

massage

Are you sure, you mean "massage"? No Typo?

What do you mean? do you want to select the events directly from the database ordered by events.received_ts?

if so, the structure might help you to create a mysql statement: https://github.com/matrix-org/synapse/issues/934

[samczsun]

@t3chguy, if Matrix returns an event with a specific timestamp then I'd expect that Riot, the frontend, would accurately represent that timestamp to the end user by inserting the event into the correct location instead of simply appending it in the chat window. I'm not sure how this isn't an issue in Riot, since the Matrix API can't really do much more beyond provide the correct information

@rubo77, I definitely meant massage, see here.

The behavior I'm trying to get is simple. If the current conversation looks like this:

[11/03/2019 10:03AM] alice: how's the weather
[11/03/2019 10:05AM] bob: great

And then my application service inserts a message from charlie and claims it was sent at 11/03/2019 09:38AM, then I want the conversation to look like this:

[11/03/2019 09:38AM] charlie: anyone got plans for today?
[11/03/2019 10:03AM] alice: how's the weather
[11/03/2019 10:05AM] bob: great

[ara4n]

riot currently displays messages as they are provided by the HS. for /sync this is the order they are received (not DAG ordering), for /messages this a linearised view of the DAG. timestamps cannot be trusted, and inserting messages from netsplits in ancient history is considered undesirable.

in either scenario, the timestamp claimed by the msg is ignored. the right solution is probably to change the ts massaging code (which has never been used in anger afaik) to insert events in a “right” place in the DAG, so /messages paginates them into the right place. as @t3chguy says, this is essentially a matrix api issue.

when are you adding the old msgs? when the room is created, or incrementally, or in a single batch at some point?

[Half-Shot]

@ara4n The Modular migrator service uses ts massaging to migrate old messages across so they show up with sane looking timestamps. It's a deprecated API that has been removed from the spec, but we still use it.

[ara4n]

i had no idea that modular used it...

[samczsun]

I'm writing a bridge where there might be a latency of seconds to minutes between the remote client sending a message and my service receiving that message.

One case I want to deal with is when: 1) Remote client sends message at ts 10 2) Matrix-native user sends message at ts 15 3) Service receives message at ts 20 Here, I would want the remote client's message to be displayed first in the chat history.

The second case I want to deal with is importing missed messages, in case my service ever goes offline and can't process messages. This is very much an edge case, but I don't want to focus my limited spare time on a self-imposed SLA instead of actually writing the code I need.

I don't have all the background here, but I don't understand why an option can't be added to Riot to trust the timestamps and order the messages accordingly. I have little experience with frontend work but my assumption is that all the events in a room are stored in a list before being rendered. If this is the case, then it should be simple to sort that list before rendering, right?

[t3chguy]

The nature of distributed systems is you can't trust the timestamp, I could very easily forge one to put words in your mouth (messages)

[samczsun]

Maybe I'm missing some context here, but why is the client trying to validate the data here? If the homeserver has accepted the event as valid despite having a modified timestamp, isn't that good enough?

Besides, I've seen other IM clients like Slack reorder messages at times of high network latency when the server corrects the client and says "no, this message actually came first". I'm not saying that this should be the default behavior in a federated system like Matrix, but making it user-configurable shouldn't be as controversial, right?

Also, if you're saying that this won't be implemented because it could be possible to abuse the client and insert arbitrary messages from me with an arbitrary timestamp, then that suggests that at the current moment, it's possible to insert arbitrary messages from me with the current timestamp. If that's the case, then I think there's a bigger problem here beyond Riot trusting timestamps or not

[t3chguy]

In a distributed system you either go by timestamp of receipt (what matrix and synapse are doing for ordering) or you trust the claimed timestamp of origin, which cannot be trusted as it comes from a third party which could very easily change it for their gain.

[t3chguy]

In a system like matrix with network delay effects it could be natural for a message to arrive late over federation, that message getting moved (and hidden) somewhere high up in the timeline because of latency is not desirable. The way riot shows it (the way synapse presents it) ensures no message is ever missed by the user if they're reading them sequentially

[samczsun]

which cannot be trusted as it comes from a third party which could very easily change it for their gain.

The "third party" that Riot is getting information from is a homeserver I've explicitly chosen to connect to. If I can't trust that the homeserver I connected to is providing accurate timestamps to me, then how can I trust anything? Again, my expectation is that Riot only presents the data given to it, not also validate it. Let me know if that's not the case.

that message getting moved (and hidden) somewhere high up in the timeline because of latency is not desirable

This seems like something that should be up to the user to decide, which is why I'm suggesting at the very least to make this an opt-in feature. Personally, I would rather my timeline of events actually reflect the timeline of events, even if it means I may miss a message that got randomly inserted 5 days ago (in which case, the person sending the message shouldn't have any reasonable expectation that anyone will see it). Besides, the predominant use case isn't for events which are so backdated that they'll get hidden. I care more about events that are backdated by a couple seconds to minutes, such that they'll definitely still be in view (assuming sane vertical dimensions) when the shuffle happens.

[t3chguy]

The "third party" that Riot is getting information from is a homeserver I've explicitly chosen to connect to.

No, origin_server_ts is from the origin server, as the name implies, which may be not the server you are connecting to.

[samczsun]

Fair enough, I had incorrectly been only considering my use case where I'm exclusively dealing with rooms on my local homeserver.

However, I still don't see the point of the client doing this validation. You say that it's undesirable for a client to reorder messages by claimed timestamp. Why is that? The argument that timestamps aren't trusted seems invalid because you're still rendering the body and sender as claimed, so unless you plan on somehow validating those as well then you just need to take the origin server's word for it. If that's the case, what's the worst that could happen from also trusting the timestamp?

It seems to me that the only thing you're preventing is a malicious user hiding messages in the past. That's a reasonable risk if for some reason you were chatting with people you didn't trust and needed the chat to be an append-only log of events. However, that's certain not everybody's use case, so at the very least making this an opt-in feature should be acceptable, right? It makes Riot behave like how people transitioning from other platforms like Slack expect.

[TheDiscordian]

I figured this issue lost steam, and I feel there's still some misunderstanding here:

Fair enough, I had incorrectly been only considering my use case where I'm exclusively dealing with rooms on my local homeserver.

On an unfederated server this is fine, but while federated the room isn't really on the homeserver, it's shared between the user's homeservers (is my simple understanding atm).

However, I still don't see the point of the client doing this validation.

I guess you could consider it less validation and more "chose the most sane value to trust". You can trust a time that came somewhere else (any server, really), or the time you received the message for ordering. The origin time is still displayed on the client.

You say that it's undesirable for a client to reorder messages by claimed timestamp. Why is that?

Consider this scenario:

User A (00:00): I think puppies are cuter than kittens, but mostly because I'm not sure what a kitten is. User B (00:10): I completely agree. I've never understood that at all.

Then User A pushes a message with something nefarious:

User A (00:05): User C is practically a complete scumbag.

It's the above scenario I think people are trying to avoid, because that's easily construed as "putting words in my mouth". Though I still see the argument for it being optional. Even optional though, I think there should be some sort of flag, indicating it got ordered.

The argument that timestamps aren't trusted seems invalid because you're still rendering the body and sender as claimed, so unless you plan on somehow validating those as well then you just need to take the origin server's word for it. If that's the case, what's the worst that could happen from also trusting the timestamp?

Are you implying someone could send something malicious this way? Currently if you pose as someone else, the client will expand their name, exposing the duplication.

Edit Currently I think it's best to sort the logs later if you want conversation properly ordered. For an IM context, it just makes a lot of sense to show messages as they're received IMHO.