Strip ZNC Server when Resolving Nickname

[andymandias]

When connecting using a ZNC style 'username/server' username, no channels appear in the sidebar despite channels being configured both in Halloy and on the ZNC server. I believe this is because comparisons against the user's username are failing, since the servers connected via ZNC report just 'username'; e.g. if I'm connected to irc.libera.chat then my ZNC username is 'andymandias/libera', but JOIN reports 'andymandias' has joined a channel and is not recognized as mine.

This change is to strip the server portion of the username such that the failing checks correctly resolve as true, while not interfering with non-ZNC users nor with the ZNC login. Doing so when setting resolved_nick in the client was the best place I could find for that, and it has been working for me in testing so far (testing with a regular username as well as a 'username/server' username).

[tarkah]

Thanks for the PR! Can you please run with debug logging and share your log file? I'd like to see what is actually received over the wire.

You can run with RUST_LOG=debug env var and find the log file at ~/. local/share/halloy.log

[andymandias]

Certainly!
halloy.log is a log opening Halloy, changing channels a few times, then closing Halloy.

I think something may be misconfigured on my end though? I ran Halloy via RUST_LOG=debug cargo run in bash a few times (to see if there is any difference in the logs produced by main and those produced by znc_server_username_fix). Initially writing to ~/.local/share/halloy/halloy.log (where I got the above log), but at one point it stopped writing logs to disk and I can't get it to start again. I can always tee the tty debug output into a file, assuming that's the same debug information.

[tarkah]

Thanks! When running from CLI in debug mode (no --release) we only output logs to terminal :)

[tarkah]

@andymandias Apologies, we need RUST_LOG=trace log level to see the raw IRC messages

[andymandias]

No problem :) trace level log: halloy.log

[tarkah]

Thanks! Ok so based on the logs, there isn't a problem with ZNC or how it sends stuff / how we handle it. We receive a NICK command prior to the JOIN, so all should work.

12:10:30.760:TRACE -- Message received => Message { source: Some(Server("weber.oftc.net")), command: Numeric(RPL_WELCOME, ["andymandias/oftc", "Welcome to the OFTC Internet Relay Chat Network andymandias"]) }
12:10:30.761:TRACE -- Message received => Message { source: Some(Server("andymandias/[email protected]")), command: NICK("andymandias") }
12:10:30.762:TRACE -- Message received => Message { source: Some(User(User { nickname: "andymandias", username: Some("~andymandi"), hostname: Some("070-095-128-105.res.spectrum.com") })), command: MODE("andymandias", Some("+i"), []) }
12:10:30.762:TRACE -- Message received => Message { source: Some(User(User { nickname: "andymandias", username: Some("~andymandi"), hostname: Some("070-095-128-105.res.spectrum.com") })), command: JOIN("#asahi", None) }

This lead me to believe that andymandias/[email protected] isn't getting parsed properly and it in fact is not! My parsing implementation doesn't recognize this as a valid username source, so when the NICK comes across, it's not being used to update your nickname in the client. Hence it shows as Source::Server instead of Source::User {..}.

So the real fix here is correct username parsing to handle / character, then your patch won't be needed at all :D I'm glad we could uncover the true root cause via trace logs, thanks!

[andymandias]

Excellent! I believe / is not a valid IRC username character, but it is a valid ZNC username character. So it all makes perfect sense. Thank you for looking into this further. If there's any need for testing the real fix I will be happy to help.

[tarkah]

Excellent! I believe / is not a valid IRC username character, but it is a valid ZNC username character. So it all makes perfect sense. Thank you for looking into this further. If there's any need for testing the real fix I will be happy to help.

Thanks for diving into this! Can you please try #222? If fixed, we can close this. I've added you as co-author on that commit :)