Quote
For example, would it be possible to allow unlimited characters, but if the user has used more than 10 characters then to watch for the error message that happens if the server doesn't support this and provide additional error message text advising that the probable cause is that the server only allows 10-characters?

I looked into this many years ago. There is a commented out section in the ERROR handling code that processes the "Closing Link" disconnect message from a server and tries to connect to the server again with a generic "user" userid. It does this if it sees an error message that matches "bad user info", "bad username", "invalid username", "not authorized", and "banned", which presumably were some of the errors returned by servers for invalid userids at the time this was tested. I am guessing I decided against using this method.

I just performed a quick test and saw the following for invalid userids:

Most networks disconnect you with an "ERROR Closing Link" message with "invalid username" as the error.

Some networks reply with "USER :Your username is not valid", giving the client a chance to send "USER" again to continue the logon.

Some networks chop userids and remove/replace invalid characters automatically allowing the logon to succeed.

Some networks handle invalid userids in USER and in identd differently/separately, ie. some networks will disconnect you if your identd userid is invalid, most will simply fix it. But most networks will disconnect you if your USER userid is invalid, and some will simply fix it.

If this change is made:

If a user uses a userid considered invalid by a network, the odds are that they will be disconnected. mIRC will then have to check the ERROR reply to see if it matches words related to invalid userids and then try to reconnect with a fixed userid. For these users, mIRC will have to connect to a server at least twice, in addition to the usual connection issues.

As every network has its own interpretation of what an invalid userid is, your userid may be different on every network. It's difficult to know whether this matters. The method mIRC has used for a long time means that users have had a consistent userid across all of the networks they use.

If a user currently has any scripts, settings, logon/connect/auth details, etc. that depend on their userid, they will be affected. If other users that you chat with in private, on channels, etc. have stored your address for use in different features, eg. highlight, op/ignore/voice/protect, notify, other types of authentication, etc., they will be affected.

mIRC will have to depend on seeing a specific combination of words in a specific language in the ERROR message to handle this, something that, as many of you know, I have been trying to avoid.

An IRCv3 CAP token could help, eg."username=options", where options describes maximum username length, the set of allowed characters, etc. or perhaps something even simpler, such as "username=safe" which means the server will accept any username format and will automatically fix it, so the client doesn't have to fix it itself. If a server doesn't list the token, the client will use a maximum length of 10 characters and a-zA-Z0-9._- which are acceptable on all networks.

If IRC servers simply replied with the USER error, that would resolve the USER invalid username issue.

However, neither of the above solutions will help if an identd request is sent before a client logs on (as some networks disconnect you for invalid identd userids).