Forums Bug Reports 7.68.933 - "/cap req -echo-message" display bug.

This is the same issue :-) Please wait until the next beta before testing -echo-message further as it is not supported in the current beta.

The reason you are seeing different behaviours is that Libera.Chat only supports echo-message, while Snoonet supports echo-message and labeled-response. The parsing of their echoed messages will be different since, without labeled-response, there is no clear correlation between sent and echoed messages. I have described this issue in beta.txt.

In fact, it may even be the case that different ircds handle enabling/disabling echo-message differently, and there may be a timing issue since echoed messages will only be returned once a message has reached its destination. So, by mixing multiple enabled/disabled/send/receive without/without labeled-response, the results could be interesting.

This is why I may decide to not support echo-message without labeled-response in the final release. In that case, if a user decides to manually enable echo-message without labeled-response, they will then also need to write a script to handle echoed messages themselves.

Update: I tested your script on Libera.Chat. In some cases, it showed the expected result, in other cases, it showed your above result, with the following debug information:


Dissecting this: notice that even though we sent two CAP reqs, we did not receive confirmation from the server of the CAP req changes until after several PRIVMSGs were sent. From mIRC's viewpoint, the echo-message status only changes once it has received the CAP ACK confirmation from the server. So in the above series of events, there is a disconnect between what mIRC thinks should/should not be echoed and what the server thinks should/should not be echoed. When combined with the lack of labeled-response on Libera.Chat, and perhaps lag/timing, the result is not going to look pretty.

In the above case, mIRC sends the "CAP -req -echo-message" to disable echo-message, and then a few seconds later sends "3" "2" "1". The server treats "3" "2" "1" as not needing echoes because echo-message has been disabled but mIRC does not receive the "CAP ACK -echo-message", confirming that echo-message has been disabled (which the server could possibly decline with a NAK), until after these messages are sent, so as far as mIRC is concerned echo-message is still enabled for them, expects echoes for them, grays them out, etc.

I would say that, while it's great that you are testing this, echo-message is very likely meant to be either enabled or disabled :-)