Forums Bug Reports Autojoin of channels with +r

Perhaps we can add a 3 second delay to mIRC's auto join favorites.

This should resolve most considerations with NickServ Auth latency, Performs and other On Connect prep-work.

This same delay might also be added to mIRC's re-joining of channels on reconnect.

But it would be even better if mIRC watched for the Nickserv "identified" message

[quote]mIRC rejoins channels, and triggers the perform section, as well as initiating other features, only after it has received the MOTD. I could make mIRC wait for three seconds after the MOTD before doing this to get around the nickserv limitation but this would affect all users and all connections.

Nickname and Channel services are almost entirely a non-anti-unstandard in IRC, with the only exception being SASL auth, and pseudo-standard PASS auth, and defacto-standard /NICKSERV auth. You will never find an acceptable IsAuth solution until a standard is both proposed and adopted, which has not happened.

Tiago: Your first goal is to stop worrying about the Favorites auto-join option, since the same behavior considerations must also be made for [re]connect [re]joins, which supersedes Favorites autojoin. So we're not talking about Favorites anymore in this thread, we're talking about all connect/reconnect server-j_join/favjoin/rejoins. 100% detached from Favorites or any options toggled within Favorites.

Secondly, there are 4 or 5 or 6 different usermode +r alternatives, so $usermodes is a non-starter.

Nickname and Channel services are almost entirely a non-anti-unstandard in IRC, with the only exception being SASL auth, and pseudo-standard PASS auth, and defacto-standard /NICKSERV auth. You will never find an acceptable IsAuth solution until a standard is both proposed and adopted, which has not happened.


Khaled: I am personally fine with subjecting everybody to a 3 second delay in auto joining channels. There is scarcely a situation where sync time is terribly less then that anyway, and it may play out that all IRC channels benefit from a less aggressive connect_join time where users are experiencing crap-tastic connection drops, send_q flooding, or delayed oper k-lines and proxy detection bans. Less channel flooding as people join/quit/join/quit mere seconds apart. Certainly, we would see a drop in "Quit: Logged In" or "Quit: Changing Vhost" style [fake/virtual] quit messages from people authenticating late.

I would encourage all clients to add a 3 second delay between 001...005 or 376 and auto-[re]joins. (reset the 3 second timer for each matching numeric encountered)

I am personally fine with subjecting everybody to a 3 second delay in auto joining channels.

I have been looking into this on Freenode and the nickserv identification message takes about 6 seconds to arrive. So mIRC would need to wait at least 6 seconds - but ... identification could take 60 seconds for all we know.

I could make mIRC wait for a NOTICE from "NickServ" with the words "You are now identified for" - which would not be fine because this may not be standard across networks and uses English, which will not work on non-English networks.

It would not be enough to wait for just any NOTICE from NickServ. When I connect to Freenode, I almost always receive a "-NickServ- This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>" before I receive a second NOTICE "You are now identified". So mIRC would need to check the wording.

Why don't you do something more clever?

As most (about 90%) of services when you identify you get "+r" usermode, you can start auto-join if you receive that usermode flag instead of NOTICE from nickserv that if i use an other services language non-english it may be broken.