Okay, this is the same issue that we discussed before: every IRC network is using a different method/wording/format, that can change over time, for letting the client know that it has logged on with a registered nickname. This means that there is no way for a client to determine when this has actually happened, and this affects all subsequent actions, such as joining channels, that depend on the user being logged on to the network.
In the current implementation, mIRC waits at most 60 seconds for a notice from "nickserv" before continuing the logon process. mIRC assumes that the first "nickserv" notice it sees is a notification that the nickname logon process has completed. It doesn't check the language/wording/format of the notice because, as mentioned above, every network uses a different one, and it changes over time.
Yes - I fully understand just how difficult it is to handle this in a way that will work on all servers without a structured standard on how Nickservs report that you have authenticated.
...
For your current issue, you are also seeing a "You have 10 seconds to identify" notice in addition to the first notice. mIRC would have to ignore this notice but there is no simple way to do this without checking for that exact wording, which could change eg. "30 seconds" and mIRC would need to store and update this for every IRC network that uses a different phrase, different language, and so on.
This type of event really needs to be a numeric.
That said, how are you reproducing this? I have tried connecting to Libera.Chat many times with nickserv and have not seen this second notice.
It is a Nickserv setting - or possibly two, one to limit login time and another to reduce it from 30s to 10s.
As for your suggested solution: if I set my favorites dialog to join ten channels on connect, your suggestion would require mIRC to send, in a worst case scenario, 120 channel joins in the space of one minute, receiving 120 numeric 477 replies, etc. Even if you were only joining one channel, I would really not want to implement something like this because the client would essentially be ignoring a server error/warning and repeatedly trying to circumvent it.
Hmmm... I do get what you are saying here - this needs to be scalable. But here are a few suggestions to mitigate this...
a. You could collect the channels sending a 477 message into a list and only retry only one of them (perhaps in turn) until you get a trigger (see c.) which indicates that the user has been authenticated.
b. It is not perfect for the same anarchic reasons as above, but you could try to recognise the Nickserv "You are now identified" message as a trigger for knowing the user has been authenticated. There are probably a whole bunch of message types which would indicate a successful authentication - in the above list we have 2 Nickserv messages, an @account message, the 396 message, and of course a successful join to a previously 477 channel would also indicate the same.
c. If the primary strategy is to wait (as a user would) for an authentication trigger to happen before retrying the join, then a timer based strategy would be a backup and could have a longer delay and possibly a delay that increases each time (5s, 10s, 15s, 15s) until after all these attempts have not resulted in a successful join, the 60s timeout happens as currently and you do a final attempt to rejoin and stop handing 477s and show them, to the user.
So in your example, of 10 channels requiring you to be authenticated and no Nickserv trigger, and assuming that the authentication never happens, instead of 130 477s (12 gaps of 5s means 13 attempts) you would get only 24 (10 from initial attempt to join, 4 for the timed single retries, and then a final 10 at the end of 60s. This feels to me like a reasonable compromise and seems to mimic what a real user would do if they couldn't see whether they were authenticated or not).
Have you tried connecting with SASL? That resolves the issues with nickserv logons and autojoins as far as I can tell.
No. I could try it for this server and see if that is a workaround.
