Forums Developers IRCv3 echo-message, queries get separated

I am testing a little more, when reconnecting to the ZNC, the query buffer gets split in two tabs, one with the messages from the nick I was talking to and one with all my messages. I think I saw that before on other clients but it has been fixed. Not sure how to explain it better, I can provide a temporary ZNC if you want to test.

Is this the same issue as ZNC's self-message discussed here?

I'm trying to think but IIRC without the self-message script you don't see your nick at all, the buffer will only reopen the other user query as msgs to you and you won't see your nick.

Echo-message was made to fix that showing your nick, times and everything as well but for some reason it shows in two separate tabs, one with the user and one with your nick, I saw it before I just can't remember on which client.

In order to track this down, I would really need a step by step method to reproduce the issue.

For example, I would need to see something this:

1) Run mIRC.
2) In Status Window 1 - Connect to ZNC using /server zncaddress nick1:pass1 -i nick1
3) In Status Window 2 - Connect to same server using /server serveraddress -i nick2
4) In Status Window 1 - open a query window to nick2
5) In Status Window 2 - open a query window to nick1

And so on. Without a step by step method of reproducing an issue, I will simply be guessing what you are doing at every step.

A debug log for the client connecting to the ZNC would also help.

Those are actually the exact steps I was testing with.

Just in case you still need the znc debug log, how do I print it?

What happens after step 5?

Please describe each step and indicate the point at which the issue is reproduced.

You can enable debugging with "/debug @debug" and then copy the text from the debug window.

The issue is not present while you're still connected, everything is fine in real time, queries get sent and received normally, you see both nicks in the same window and you can just conversate.

When you close mIRC and reconnect to the ZNC, the buffer will load in 2 different windows, one with nick1 and one with nick2. < This is the issue, loading the query properly from the ZNC buffer.

Okay, I have tried the following:

1) Run mIRC.
2) In Status Window 1 - Connect to ZNC using /server zncaddress zncnick:zncpass -i nick
3) In Status Window 2 - Connect to same server using /server serveraddress -i nick
4) In Status Window 1 - open a query window 1 to nick
5) In Status Window 2 - open a query window 2 to zncnick
6) In Status Window 1 - disconnnect
7) In Status Window 1 - connect

When I follow the above steps exactly, the query window in Status Window 1 is renamed from "nick" to "zncnick". That is because, on connect, ZNC is sending a NICK change to set your zncnick:

<- @time=2022-05-05T07:41:42.826Z :nick!host@127.0.0.1 NICK :zncnick

And in mIRC's nick change handler, if it notices that a user has changed nicks, and you have a query window open with them, it changes the query window target to their new nick so that you can keep talking to them.

Is this the issue you are seeing?

This is what i see (znc.in/self-message script is disabled, only echo-message enabled).

<- @time=2022-05-05T18:11:08.887Z :znc.in BATCH -83dd4d95b9f42d9c44f500141edee67a
<- @time=2022-05-05T18:11:08.887Z :znc.in BATCH +b6a01e952006cea0db51db2fd0fa512c znc.in/playback normalnick
<- @batch=b6a01e952006cea0db51db2fd0fa512c;time=2022-05-05T18:10:12.071Z :zncnick!znc@IP PRIVMSG normalnick :dskjhjdf
<- @batch=b6a01e952006cea0db51db2fd0fa512c;time=2022-05-05T18:10:13.046Z :zncnick!znc@IP PRIVMSG normalnick :fdjhgdjfhgdf
<- @batch=b6a01e952006cea0db51db2fd0fa512c;time=2022-05-05T18:10:16.171Z :normalnick!hexip@unknownnetwork-a.clients.kiwiirc.com PRIVMSG zncnick :gflkjhgfk
<- @batch=b6a01e952006cea0db51db2fd0fa512c;time=2022-05-05T18:10:17.204Z :normalnick!hexip@unknownnetwork-a.clients.kiwiirc.com PRIVMSG zncnick :dfglkjdklgjfd
<- @batch=b6a01e952006cea0db51db2fd0fa512c;time=2022-05-05T18:10:18.151Z :zncnick!znc@IP PRIVMSG normalnick :dflkgjhdfkjg
<- @time=2022-05-05T18:11:08.887Z :znc.in BATCH -b6a01e952006cea0db51db2fd0fa512c

Still, echo-message was designed by the IRCv3 team as a replacement for znc.in/self message, there is absolutely no point to integrate it for everyone if they don't even use a ZNC + buffer. This is the one option that absolutely has to be optional with something like a box in the Server tab saying "Use echo-message when available." The delay is caused by the server response in ms, it may not be noticeable if the server is very close but there is a delay, in decades of IRC I never had to double check if a msg was delivered.

This is not a ZNC-specific feature. You can read about echo-message and its purpose here.

I was not able to reproduce the issue you described in your original post. This is the reason why I was asking for a step by step method to reproduce your issue. If you do not provide a numbered, step by step method, that you have tested and confirmed reproduces your issue, then it will be impossible for me to know what the issue is or how to reproduce it.

Based on the debug you provided in your post, it looks like you are reporting the same issue that was originally reported with self-message? ie. that incoming messages with source as your nickname and target as another nickname (which is not a normal or expected combination for an incoming message) are being displayed in a different window?

It's just a normal query, one is a znc and the other is normal (external client or same client not on the znc).

1) Open mIRC > connect to ZNC (zncnick)
2) Open KiwiIRC or any other client > normalnick
3) From KiwiIRC /query zncnick blahblah
4) From mIRC > /query normalnick blahblah2
5) Reply back and forth to leave some msgs for the ZNC buffer to load on restart.
6) Close mIRC
7) Open mIRC > connect to ZNC (zncnick)

The ZNC will load the channels in their tabs + ONE TAB for zncnick and ONE TAB for normalnick INSTEAD of ONE UNIQUE TAB for the normal query as it should be.

Right, so this is the same issue as self-message and not specific to echo-message.

This is still on my to-do list.

Ohh I see, thanks for checking.

I have been testing echo-message with the latest version of ZNC.

It appears that ZNC's echo-message implementation is not quite working correctly in the way it echoes some messages, such as CTCP messages. It seems to be filtering them out and not echoing them back to the sending client.

For example, if I use:

//raw PRIVMSG nick : $+ $chr(1) $+ hello $+ $chr(1)

ZNC seems to filter out the echoed PRIVMSG from the server.

If I test this with a non-CTCP-encapsulated message:

//raw PRIVMSG nick :hello

The expected echo does arrive.

If I test this by connecting directly to the server (in this case, the latest version of InspIRCd), both of the above are echoed back as expected.

This means that echo-message will not work as expected when connecting through ZNC at this time. mIRC would be waiting for an echo for the PRIVMSG/NOTICEs it has sent without receiving them, even though echo-message is enabled.

For the time being, I have stopped testing echo-message with ZNC because of the above issue.

Note: the next beta will fix a number of issues with echo-message, so it would be best to wait until that beta is released before testing echo-message further.

As discussed in my recent post, mIRC has previously only handled messages where the target is your nickname, or a channel that you are on, which are the expected source/target combinations from a server.

The latest beta should now handle ZNC-type non-standard messages with source/target combinations that are not normally sent by a server, ie. sent by you to another nickname or channel.

I tested these by using /parseline to simulate different combinations of source/target/message types, eg.:



Since these are non-standard messages, they should presumably not be processed in the same way as messages where you are the target, ie. normal messages have features like these applied to them: 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. In the latest beta, non-standard messages do not have any of these features applied to them.

In addition, in the latest beta, non-standard messages will trigger the on OPEN/TEXT/ACTION/NOTICE/SNOTICE/CTCP events, in the same way as previous versions, and will set $invalidmsg (perhaps someone can think of a better identifier name?) to $true. These events were intended to handle standard messages, so this is not ideal but seems to be the only practical option (other than, perhaps, triggering on RAW:PRIVMSG/NOTICE:* for non-standard messages).

Since my experience with ZNC is limited, any feedback from ZNC users on these changes would be appreciated.

$nonstdmsg

Thanks for checking and working on all this.