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.
