If your server has been set to use nickserv with a password; and...

If you put a channel in your favourites and mark it as "Join on connect" and if the channel is mode +r (which means "you need to be identified with services" before joining) ...

Then mIRC attempts to join the channel before identification has succeeded.

You cannot tell in advance whether the channel is mode +r, so before autojoining any channel on connect, if the server is defined as using nickserv identify then mIRC needs to have sent the nickserv identify and either received a "-NickServ- You are now identified $me" notice or waited for a period of time to elapse (say 1s) before attempting to join the channel.

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.

A 3s delay (if the connection has nickserv authentication) is the simplest solution. (I agree that 3s is probably a better default than 1s - or it could be a setting.)

But it would be even better if mIRC watched for the Nickserv "identified" message in order not to wait until the 3s has elapsed - but in case it can't recognise the nickserv message, if it has received it in 3s then it should attempt a join anyway. (If we will react to nickserv's notice, perhaps the default timeout should be a little longer - say 5s instead.)

In my opinion there should be a setting or option if you can activate or deactivate, in the mIRC Favorites dialog, where autojoin is performed only just the confirmation msg that the nickname is identified in the services.

I try to avoid solutions that depend on wording. Not only do different networks use different wording but they can change the wording and format from ircd version to version. In addition, this assumes that the wording is in English, which it may not be. Unfortunately, I have been forced to check for specific phrases in English to parse some numerics due to different ircds using the same numerics for different features. It's not a pretty solution. In this case, looking for a message from nickserv to confirm that a user has been identified is not ideal. Such a reply should really have been a numeric to make it clear to the client what has happened.

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.

It would not be possible to make mIRC do this only if the connection has Nickserv set. Nickserv can identify your connection from an SSL certificate, two SASL formats, two Nickserv formats, and a password format specific to that server.

What about /who <self> %a if the IRCd supports WHOX?

Another alternative solution:

And you could not get around this situation using $usermodes? For example I connect to a network and having for example a check of the mIRC Favorites dialog activates mIRC only executing the autojoin -n command if the identifier $usermodes returns the mode +r. I think this mode is the most common in all networks and would not depend on nickserv.

I think it is a good alternative to get around this situation so there is no need to put a wait time for mIRC to enter the channels if we have an option that we can activate or deactivate in the favorite mIRC dialog for example:

(check) Only after identification

and with this active option, mIRC only entered the channels if it returned from the identifier $usermodes the mode +r that corresponds to the identification of the nickname.

1. On freenode I have a registered nick, but $usermode +r is not set. So I am not sure that this will work reliably.

2. For NICKSERV identification by mIRC as part of the server configuration (as opposed to using a script or perform to do it), then mIRC knows it has requested authentication by NICKSERV and all it needs to do is to wait for a NOTICE of any form from NICKSERV before attempting a join.

It does not need to worry about whether the authentication actually succeeded before attempting a join - if it failed and channel is +r then the join will fail because the authentication failed. If it succeeded then the join will work.

I cannot comment on other authentication methods such as SASL.

P.S. Just tested SASL and you get a 903 message for successful authentication. This is also quick - it comes before the MOTD.

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 agree that you cannot hope for mIRC to recognise every authentication method on every IRCD ever written.

My request is limited only to those authentication methods already recognised by mIRC by offering authentication in the server definition - and only to delaying autojoin to channels until it receives some response to the authentication request or a timeout expires. I think this is possible.

I do not think you need to talk to me like that, because I did not offend anyone by suggesting anything. I think this is a forum and we can all give suggestions whatever, even because with the same right that you think you have the right to call my attention, I could do the same with your conduct and how to talk to me, but I will not do it because I do not waste time with people with no education at all.

Sorry, it wasn't intended to be offensive, just matter of fact. Poorly worded. I should have said the 'first issue is' or such.

<--- This idiot relies on too many idioms.

I have been looking into this on Freenode. The nickserv identification message takes about 6 seconds to arrive after the end of the MOTD. So mIRC would need to wait at least 6 seconds - but probably more like 10 seconds to be safe. That said, it appears that servers queue the identification request in the background while processing other server messages for that user, so the amount of time it takes to identify a user seems to depend on how busy a server is - 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" - but this would not be ideal because this may not be standard across networks, and it 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.

@Khaled - I understand your logic here but having digested this I would suggest the following:

1. Ignore any Notice from NICKSERV which has "/msg NICKSERV" in it - this is unlikely to be different in different languages.

2. Assume that any Notice which doesn't have this is either an authorised / un-authorised message - and either way use this to trigger the autojoin attempt.

3. Bearing in mind that in normal operation you will get a 903 SASL response or NICKSERV Notice, it is very unlikely that the timeout will ever be triggered - it will only be if you have misconfigured an SASL/Nickserv for a server which doesn't support it or e.g. if the server's NICKSERV is down. On this basis a fixed timeout of 60s or 30s might well be acceptable - or we could allow the user to change it via another setting in the Edit Server pop-up.

P.S. Also, since SASL support is announced in a CAP before you send an SASL / NICKSERV password, how about a (default?) option which automatically decides whether to send an SASL or /msg NICKSERV password depending on whether the CAP SASL is sent to mIRC. :-)

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.

And even if you put mIRC checking the NickServ text in several languages, I think it would not be that bad and not impossible. For example in PTnet and PTirc where I am IRCop the NickServ call takes less than 3 seconds. So I think you should put the NickServ text in several languages in the mIRC database.

However, if you are looking for a simpler solution and I believe it is effective and that it minimizes this problem to all users on any network, then you have to create an option in the mIRC Favorites dialog that allows you to customize the time of entry into the channels when we do the network connection.

Excelent idea. I had already suggested that but they would not listen.

I don't think it is fair to suggest that Khaled has not been listening.

But the diversity of suggestions is great!!

This is something that I am completely against, for reasons that I have already explained in my previous posts. I will not make such a feature work based on checking for specific words in an event. Implementing a feature in this way is worse than using a server version number to decide whether to enable certain client features, which is what numeric 005 was meant to resolve.

The current issue is due to this feature being badly implemented on the server side. The server coders implementing this should have realized that clients need to have a clear way of detecting events like this, as opposed to requiring clients to implement hacks that can break across languages, ircds, ircd versions, and so on.

Raccoon pointed out that there are several different usermode +r alternatives, so mIRC would in that case have to cater for multiple different representations of usermode +r based on server version numbers.

I agree with Khaled about not coding something that has to detect different language strings or which uses e.g. modes which are not standardised.

But as posted in a comment above, I believe that this can be coded without either of these based only on:

1. User's mIRC Server settings for automated authentication;

2. Use of Nickserv response strings which are NOT language specific (like "/msg Nickserv" which are IRC commands and don't differ between languages) to identify Notices from Nickserv that should be ignored.

3. Assuming that user's mIRC server settings are correct and server is working correctly (which will be true 99.9% of the time) and so user will be authenticated ok and assuming that Nickserv notices not ignored by 2. are confirming authentication - but handling with a lengthy timeout the situation when this is not the case. (If Notice is a failed authentication, then we should still attempt a /join.)

With this approach you will not need to code for:

• Language strings
• User modes

So, the only method that will work for now, that is language-independent, seems to be:

1) After the MOTD is received, check incoming notices from "nickserv".
2) Ignore the notices if they contain "/msg" or "/nickserv".
3) Otherwise, assume it is a notice indicating success or failure of nickname identification, so trigger perform.
4) If no such notice is received after 60 seconds, trigger perform.

However, this will fail if an ircd changes the text in notices eg. there is no reason why a server could not say "visit this website" or "join this channel" to learn how to register/identify your nickname, instead of specifying /msg or /nickserv. This will also fail if nickserv sends any other notices eg. it could send notices informing users of other features or recent developments.

This change will be in the next beta.

IMO all of that would be a mistake. The suggestion of the three second delay should work fine.

Perform finishes > 3 second delay > Autojoin.

All of this other stuff of waiting for NickServ and +r mode is what scripts are for.

Just my 2 cents.

RoCk - in my experience (with 45+ years programming experience) any solution as simple as waiting for 3s will only work the majority of the time - maybe even most of the time.

But there is only one thing worse than something which doesn't work - and that is something that mostly works but sometimes doesn't. Intermittent problems are the worst type by far, because the cause can be incredibly difficult to work out.

And a simplistic solution that waits only 3s would have a significant number of intermittent failures. For example, I would think it highly likely to fail when a netsplit had occurred and hundreds of IRC clients were automatically logging in and authenticating at the same time.

To handle this, you have to increase the timeout substantially to cope with those (say) 10% of situations where it takes >3s, but that means all the automated joins have to wait for that period - and then the functionality becomes useless because people will turn it off.

So you need a deterministic solution which copes with hiccups but doesn't delay the autojoins - and the proposed solution is the simplest we have come up with so far which does that.

Khaled - I think you are being a little pessimistic here (though that is of course your job as designer/coder).

We are only talking about user settings for a server where they want mIRC to authenticate for them (as opposed to i.e. using perform or a script). You would only use this if the server supports /msg nickserv, /nickserv or SASL. (So e.g. Undernet X is NOT supported.)

It is possible that Nickserv may have been changed on a particular IRC network to do something non-standard, but that would be ... well, non-standard and so mIRC should not be expected to handle it.

So, providing that you only look at notices from nickserv (and not from any other services which might advertise before authentication), and providing that you check for "/msg nickserv" and / or "/nickserv" (which are what mIRC uses - so let's not check for anything wider), and providing that nickserv sends a notice for success or failure of authentication (i.e. doesn't not say anything), then this should work pretty reliably IMO.

I would also suggest that if 4. happens, then mIRC should put some sort of explanation up in the status window so as to prompt the user to fix the configuration (by e.g. switching to perform or a script).

P.S. My testing showed that SASL 903 response came much earlier in the connection than nickserv, but I am unclear whether that is because SASL is synchronous or just because it is significantly faster. If SASL is synchronous authentication (as opposed to nickserv which is asynchronous) then we don't need something similar to this proposal for SASL - but if SASL is asynchronous then we probably need the same sort of solution. The SASL specs should be able to clarify this.

However, if you are looking for a simpler solution and I believe it is effective and that it minimizes this problem to all users on any network, then you have to create an option in the mIRC Favorites dialog that allows you to customize the time of entry into the channels when we do the network connection.

You have missed the point of my previous email - if you work only on a timer there is NO single timer value that gives you a prompt autojoin and which works reliably when nickserv is running slowly. You need a deterministic solution.

He already stated that this issue is caused by the bad implementation of a feature on server side, should he add a workaround (hack) for every dumb little thing some server adds? The 3 second delay was workaround enough, make it 10 seconds if that's what it takes. If the delay solution is overly simple, then the other solutions mentioned before are way overly complicated.

A scripted solution is what's needed.

IRC is full of badly implemented features. That is real life.

But this is not (really) one of them - nickserv is asynchronous - which is a reasonable thing if you want people to be able to start off unauthorised and then authorise at a later date. (SASL by comparison assumes you authorise at connect time.)

When you have an async service, you need to have functionality that takes that into account.

Yes - we could have a fully scripted solution and not have mIRC provide any nickserv authentication functionality - and then expect every user to write the script necessary. But Khaled chose to provide nickserv asynchronous authentication , so this is fixing up an issue with it properly.

Or in other words, Khaled is going to create a proper solution not a Kludge which will fail intermittently and create a support headache.

It is called experience :-) As I mentioned, mIRC already needs to check for specific strings in certain numerics due to those numerics being used for different features on different ircds. These have had to be updated several times already. Unfortunately, it takes a long time for someone to notice that mIRC's behaviour has changed due to an ircd changing wording in a numeric - especially if the change in behaviour is subtle. In the meantime, mIRC would actually be doing the wrong thing in such a situation.

Depending on words in a server message along with the order of server events is not a reliable, long-term solution.

As I said, pessimism is part of the job - exactly for the reasons you describe.