Forums Bug Reports [v7.68.1100] Batch or znc.in/playback

A note: it is necessary to unrequest the CAP near the initial negotiation in order for ZNC not to serve the messages, but mIRC still thinks the echo-message is negotiated (messages show as unsent in the UI). So it is also necessary to unrequest during the CONNECT event, then mIRC no longer shows messages as unsent.

Well, technically there was nothing to correct in this case, as the echo-message support in mIRC was behaving correctly.

However, I did add a hack/kludge, outside of the echo-message code, to handle ZNC's method of mirroring/relaying messages to a client that did not originate the sending of a message.

If you test this, does it look like the issue is resolved?


Yes. In previous versions of mIRC, non-standard messages received from ZNC were triggering events that, by design, were intended for messages addressed to you.

ZNC is sending messages to you that you have sent to other users, so these messages should presumably not be processed in the same way as messages where you are the target, eg. stripping control codes, ignoring messages, flood protection, replying to ctcps, replying to sound requests, applying the lock option that disables incoming messages, and so on, all of which are being applied before scripts events are triggered.

The on OPEN/TEXT/ACTION/NOTICE/SNOTICE/CTCP events, likewise, were intended for messages addressed to you, and that is likely how most scripts use them.

I could make it so that the above non-standard messages continue to trigger these events, however the onus would be on the script to check the source/target combinations. Or I could add a new identifier, such as $invalidmsg, so that a script knows exactly when mIRC is treating the message as non-standard.

To round things out, if mIRC receives a non-standard message with a source/target that are both other users, which again should normally never happen, it will display these in the status window, just in case.

I am posting the following mainly as documentation for future reference. I have been testing mIRC's echo-message support on the exemplar IRCv3 ircds, IRCCloud and InspIRCd-3, and it's looking good. My echo-message/labeled-response test script currently tests around fifty different combinations of CTCPS, messages, notices, source/target combinations, and so on.

However, there are still issues with some ircds/bouncers where their echo-message support does not quite match the IRCv3 echo-message spec. This is particularly an issue where labeled-response is not supported. Without labeled-response, echo-message handling requires more guesswork which leads to a lack of consistency/reliability.

Some of the issues I've noticed:

1) ZNC does not send echoes for CTCP messages. This breaks the IRCv3 spec that requires an echo for every PRIVMSG/NOTICE sent. This is probably due to the fact that if you send a CTCP to yourself, and this is relayed to a second client, the second client cannot tell if the relayed message is meant to be interpreted as outgoing or incoming. If it is incoming, mIRC needs to reply to it. If it is outgoing, mIRC needs to display it as a message that was sent. If ZNC adds support for labeled-response, that may help resolve this issue.

2) When you /notice a non-existent nick, some ircds reply with "no such nick", while other ircds do not reply at all. This is an issue because, when echo-message is enabled, a reply is needed to let the client know whether a PRIVMSG/NOTICE has or has not reached the server. The exemplar ircds for IRCv3 return "no such nick" for /notices. The Libera.Chat solanum ircd, which supports echo-message, does not send a "no such nick" for /notices, so echo-message cannot currently work reliably on this ircd.

For example, if a user sends a "/notice nick text", and nick does not exist, and the server does not send a "no such nick", mIRC will continue to wait for an echo for that sent notice. The displayed line will continue to remain in a gray state, which is fine. But if the user then sends "/privmsg nick text", and the server replies with "no such nick" because its a PRIVMSG, this reply will be used for the /notice that was waiting, and mIRC will now wait for a reply for the /privmsg. This would be resolved with labeled-response but, technically, mIRC would still be expecting a reply to the original /notice, so it would be better for an ircd to simply comply with echo-message requirements that every outgoing PRIVMSG/NOTICE receives an echo of some kind.

3) If you use /msg nick,nick to send to the same nick twice, some ircds will only send one message to nick, removing the duplicate nick, while other ircds will send to each nick regardless. So the number of echoed messages can differ depending on the ircd. Since the client needs to know when all messages have been echoed, eg. in the case of "/msg a,b,c text" where the displayed line is grayed and incoming echoes need to be counted off to know when the line can be ungrayed, mIRC has to remove duplicate targets from outgoing PRIVMSG/NOTICEs.

At this point, I am not convinced that echo-message will work reliably across ircds/bouncers due to incomplete/inconsistent implementations, edge cases, and a lack of labeled-response support. Because of this, echo-message will not be enabled by default in the next version. A user can still enable it manually with a /cap request when connected to a server, preferably with labeled-response as well. But there is no way to be sure that the ircd/bouncer supports echo-message properly without performing a wide range of tests. If a user does enable echo-message, mIRC will gray/ungray displayed outgoing lines as a visual indicator, so a user can tell if echo-message is working correctly on whichever ircd/bouncer they are using.

The echo-message option will no longer be enabled by default from the next beta.