ircv3-specifications
ircv3-specifications copied to clipboard
Should server-time represent initial sent time of a message?
The server-time specification is unclear with regards to something like PRIVMSG as to whether the time should represent the time the local server sent the message to the receiving client or the time the initial user sent the message. The examples section seems to indicate the tag represents the time the user sent the message. https://github.com/ircv3/ircv3-specifications/blob/db57ff589ecf4a8715ffaf970eb8a6efeab9123f/extensions/server-time-3.2.md#L45
Can this be clarified further?
For something like PRIVMSG, I've always taken it to mean the time the original message was received by the server – there's been a lot of discussion in the channel about where this clarification would be most useful, the one of consideration here is around s2s and whether messages should have a consistent timestamp across the whole network (receiving server attaches timestamp, all other servers on network use that when sending) or it's not that important (all servers attach their own timestamp when receiving it via s2s). Where possible I reckon the first one is best, but it probably wouldn't cause (m)any dramas to do the second. This may not be something to clarify in the spec, but if we do it should be in a non-normative implementation considerations section.
The channel discussion went further into how clients should be acting in terms of reordering incoming messages or not based on server-time, and the issues that could be caused by actively reordering based on it (assuming that clocks between servers could shift a bit). Perhaps some advice like clients should only reorder messages based on their @time tag if they're contained within a chathistory batch would make sense somewhere, but I'm not sure how necessary advice like that is.
FWIW (since it was said enough times in the channel), reordering messages inside chathistory is just as broken as reordering them at any other time. It's not hard to sort the messages before returning them; if a server chooses not to do that, it's likely as not because doing so would be wrong.
As with the argument on IRC about non-chathistory messages: short of funneling everything through one place, you cannot send the same time to everyone and have the times reflect the order in which things really happened.