Forums Feature Suggestions Support for echo-message and batch IRCv3 CAPs

I would like to request both IRCv3's echo-message and batch capabilities to be added, namely because of an issue we've been experiencing when using recent git checkouts of ZNC.

Since a specific commit they've started to time stamp *all* messages (the server-time CAP), while previously only the buffer playback was time stamped. This new behavior is leading to inconsistent times being shown to the user.
An example:

timetester is a remote user, and timewizard is the user connected to ZNC. This issue also happens for other events, such as quits, kicks, etc.
In the example the clock is behind by almost a full minute, but even a few seconds is an annoyance if you're active on IRC (chatting while others are also active).

It's been said that implementing echo-message can solve this problem.

Alternatively it's also been said that implementing batch support may also solve the problem, because then we could have a client-side script listen for the end of the batch and then send a "CAP REQ :-server-time" when we receive it, though I don't like this solution much since it is a workaround, it's better than nothing.

An issue about this was opened here but has been closed: https://github.com/znc/znc/issues/1144
Please read the full issue thread first before commenting here about fixing clocks and keeping them synced, as it's already been discussed over there and is not a foolproof solution.

From that thread it's clear that the ZNC devs have bought the IRCv3 ideas hook line and sinker and have no regard for the effect of ZNC's adoption of those ideas on IRC clients. It is not up to mIRC to avoid that the ZNC devs alienate their own userbase. Moreover, suggesting that a timestamping problem be fixed with echo-message is akin to trying to kill ants with a sledgehammer: it won't be fully effective(*), and you're going to cause a whole lot of damage in the process of trying.

I'm pretty sure it's possible to write a script that implements the necessary level of batch support already, but ultimately, this is ZNC trying to impose its own world view for no good reason, and it is important to realize that that is the core of the problem at hand. If anything, the takeaway is that mIRC should stop interpreting server timestamps, and instead leave it to scripts to do so if they choose. A step back in terms of "IRCv3", but if mIRC cannot rely on the other side behaving sanely, it has little choice.

(*) In summary: mIRC also has local output that may be timestamped, for example from local commands. This very simple fact breaks the fundamental server-time assumption that all timestamps come from the server. As such, the entire discussion about keeping clocks synced fully misses the point.

I can't say I agree with Sat on his reasoning, as IRCv3 is scheduled for the next standard, but I feel supporting every IRCv3 CAPability is more flavor than substance.

I helped push for the implementation of /parseline and on PARSELINE specifically so mIRC scripting can handle CAP-specific messages instead of mIRC having to support such natively. With said addition it wouldn't take too much code to support both echo-message and batch from mIRC's scripting engine so there is little need for native support.

This alone makes me wonder how mIRC's automatic parsing of remote timestamps could ever be effective. It would be extremely confusing if an unscripted line of text came in with timestamp X and then a local command echo'd data with a completely different timestamp Y. It would seem extremely jarring and buggy to any user, I would imagine:

(17:53) <nickname> hello world
(12:01) * database backup complete
(17:54) <nickname2> hey nick, how are you?

If this happened, you'd probably start seeing a lot more invalid bug reports being posted about mIRC improperly handling timestamps, not unlike this one, in fact. The problem is, it's not a bug, it's a complete misappropriation of timestamps.