Closed rafaelks closed 6 years ago
Just blindly accepting the timestamp property worries me. If we just accept any timestamp, we could end up allowing people to post in the "past" and then they would be able to insert data into the history that never actually happened back then. We need to accept only timestamps which are within a range from the time they hit the server.
@graywolf336 That's a great point! 👍
I too worry about the abuse potential and the loss of chat history integrity of the proposed change.
A longer term solution (proposed by a colleague) to improve disconnects or delays would be two timestamps, one generated on the client when they send and another on the server when it is received. Logic could be built to decide which is best to use if the delta is small. As a new feature though, this would allow a UI notification (highlight?) for "late" messages or messages sent while a client was in a "disconnected" state. Such late messages are often confusing for users and disrupt conversation flow.
Guys, you showed great points and I realised that we don't need this on the mobile apps, because if the message was "re-sent" (because of some networking failure or offline) it can have a new timestamp. Creating the message in the past will only cause confusion. I'm closing this one for now. 👍
I am migrating chats from an existing application to rocket chat. I was doing this using the REST API. But the timestamps are not preserved. Any idea on how to preserver the timestamps from the old application when migrating?
Description:
Refers to: https://github.com/RocketChat/Rocket.Chat.iOS/issues/1546