Handle * for nickname in (in CAP ACK)

[KoraggKnightWolf]

The way the code is set up to blindly fire CAP REQ :echo-message and CAP END before NICK and USER, which can lead to * being used in the ACK response (or even NAK) which confuses jjc and leads it to hang. The lines responsible are: https://github.com/aaronNGi/jj/blob/master/jjc#L321-L322

It would be ideal to either do a proper CAP LS (302) negotiation and only request echo-message if it is listed, or at the very least, handle cases where the nickname can be a * . this might also happen if one uses a nickname which is already in use while connecting, amongst other possible cases.
The "hanging" behavior is especially noticeable on current UnrealIRCd (6) releases which all have echo-message available by default. If desired or necessary, I can gladly provide a link to my own Unreal 6 instance for testing purposes.

EDIT: It may also be that one's own (U)UID is used in place of a nickname (possibly at least), although untested if jjc handles cases where it is referred to as by a different "nickname" (like (U)UID, enforced nickname by the server) when said other nickname is not * .

[aaronNGi]

It would be ideal to either do a proper CAP LS (302) negotiation and only request echo-message if it is listed

I can certainly improve the capability negotiation to be more correct. I have to see when I can find time to work on it. It would also be interesting, to figure out why it's hanging.

this might also happen if one uses a nickname which is already in use while connecting, amongst other possible cases

That should be covered by https://github.com/aaronNGi/jj/blob/master/jjc#L1251-L1259, no? When we aren't fully connected (no 001 WELCOME received yet), a 443 NICKINUSE will cause jjc to try the same nick with a dash at the end.

If desired or necessary, I can gladly provide a link to my own Unreal 6 instance for testing purposes.

If there are public networks using that IRCd, there is no need. I can just test it there.

It may also be that one's own (U)UID is used in place of a nickname (possibly at least), although untested if jjc handles cases where it is referred to as by a different "nickname" (like (U)UID, enforced nickname by the server) when said other nickname is not * .

When would that be the case? I'm not an IRC protocol expert, that should only happen with certain IRCv3 features?

[aaronNGi]

As I told you in IRC, use the patch below, as a temporary fix, until I've figured out the real issue.

--- a/jjc  Fri Jul 30 15:20:51 2021
+++ b/jjc    Sat Sep 10 21:13:35 2022
@@ -319,8 +319,8 @@
 {
        if (pass != "") send("PASS " pass)
-       send("CAP REQ :echo-message")
-       send("CAP END")
        send("NICK " nick)
        send("USER " user " localhost * :" name)
+       send("CAP REQ :echo-message")
+       send("CAP END")
 }