Timestamps for queued messages should reflect when they were queued, not when they were sent.

[ara4n]

Your use case

What would you like to do?

When a message can't be sent, and it's magically queued by the app instead, the timestamp presented when the message finally sends is the origin_server_ts at the point the origin client manages to deliver it to the origin server.

This is very confusing UX-wise, as now the queue can flush in the background or on app FG without user interaction, it makes it look as if the user has consciously sent the msg at the point the queue flushes rather than when they sent the message, which can cause serious confusion.

I've had this twice now over the last few days:

^ This message was actually sent at 10pm the previous night during a server outage. However, it now looks like it's reporting issues at 5am the next day (whereas this is presumably when the msg queue was flushed)

^ and here's another one.

Why would you like to do it?

To stop confusing users; stale messages should be clearly marked as stale and show when the sender intended to send them - not when the app happened to flush its queue in the bg.

How would you like to achieve it?

Either:

• Add a new timestamp called origin_client_ts to distinguish the claimed time a msg was created v. when the origin server received it. Clients would then use origin_client_ts for the timestamps shown in the UI. (This was my original intention when proposing origin_server_ts as the longwinded explicit ts name in the first place back in 2014).
• Or one could allow users to massage their own timestamps, as if they were an application service: https://spec.matrix.org/unstable/application-service-api/#timestamp-massaging. This is horrid as it abuses origin_server_ts to mean origin_client_ts, and means we'd lose the actual origin_server_ts, which would then be subject to abuse by malicious clients or those with unsynced clocks.

Have you considered any alternatives?

Going back to 2014 and slapping myself for speccing origin_server_ts but not origin_client_ts. (The intention was also to have destination_server_ts and destination_client_ts for the full enchilada of the trapezium routing timings, although uses for those are less obvious)

Additional context

Filing this on meta given it affects all clients.