4 ms·

> 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 re

by kiitos 2y ago

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

shawnz 2y ago
I'm not talking about message editing but rather posting new messages with a backdated time.
- kiitos 2y ago
  I suppose every message has a few timestamps, including - The timestamp that the user specified as part of the message - The timestamp of the server that the user submitted the message to, directly - The timestamp of the server that first received that message - Any additional timestamp(s) of additional server(s) that received that message The user can I guess backdate a time, but that would apply only to the first thing, and none of the others?
  - shawnz 2y ago
    The first one is the only one that can accurately describe where the user intended for the message to land in the conversation. All the others are subject to network delays, so if you order messages by anything other than the first one, you are going to get a bad experience if you try to participate in a busy conversation with a poor connection.
    - kiitos 2y ago
      The first one is entirely un-trustable, because the user-submitted timestamp can be at any arbitrary point in time, from t=0 to t=infinity. So the receiving system can use that timestamp as an important bit of signal, but it can't really treat it as strictly authoritative, at least not if it expects to maintain a coherent set of events overall.
      - shawnz 2y ago
        Exactly, that's why I'm saying it's a more challenging problem than it appears and there's no one solution that always gives the best experience in every case. I personally think a hybrid approach of allowing some limited discrepancy between user and server timestamps is probably the best you can do.

by kiitos 2y ago

shawnz 2y ago

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

kiitos 2y ago
I suppose every message has a few timestamps, including - The timestamp that the user specified as part of the message - The timestamp of the server that the user submitted the message to, directly - The timestamp of the server that first received that message - Any additional timestamp(s) of additional server(s) that received that message The user can I guess backdate a time, but that would apply only to the first thing, and none of the others?
- shawnz 2y ago
  The first one is the only one that can accurately describe where the user intended for the message to land in the conversation. All the others are subject to network delays, so if you order messages by anything other than the first one, you are going to get a bad experience if you try to participate in a busy conversation with a poor connection.
  - kiitos 2y ago
    The first one is entirely un-trustable, because the user-submitted timestamp can be at any arbitrary point in time, from t=0 to t=infinity. So the receiving system can use that timestamp as an important bit of signal, but it can't really treat it as strictly authoritative, at least not if it expects to maintain a coherent set of events overall.
    - shawnz 2y ago
      Exactly, that's why I'm saying it's a more challenging problem than it appears and there's no one solution that always gives the best experience in every case. I personally think a hybrid approach of allowing some limited discrepancy between user and server timestamps is probably the best you can do.