Forums Bug Reports Dont join in +#chan shown in whois

There is no solution to this that I can see. The numeric 005 and CAP settings tell a client how to behave and how to parse messages. If the settings are invalid or create a conflict, there is little the IRC client can do.

In this case, the network is using the same prefix for both channel and nickname modes. Networks return whois replies that contain channel names with the nickname mode prefix (or none at all or in some cases multiple prefixes) that a user has on that channel.

If the network says + is both a channel and nickname mode prefix, and a user has + mode on channel +test, and the /whois reply returns ++test, then ++test could be either nickname mode prefix "+" channel prefix "+" and name "test", or it could be channel prefix "+" and name "+test" (since + is allowed in a channel name). That said, on IRCnet, +channels do not support modes, so a client could hard-code behaviour that says if a network supports a "+" channel prefix, assume that it is modeless and can never have a mode prefix. So "+test" and "++test" would both need to be parsed as full channel names on IRCnet, even if "+" is listed as a nickname mode prefix. But this would only apply to networks where +channels are modeless, which may not be the case on all networks. Currently, CHANTYPES does not support a method of identifying modeless channel prefixes that require special parsing.

On IRCNet, where allowed channel prefixes are CHANTYPES=#&!+ this also means that "+#test" could either be channel name "+#test" or nickname mode prefix "+" and channel name "#test". IRCnet seems to be aware of this issue and blocks you from creating channel name "+#test". IRCnet also blocks you from creating "+!test" (since ! is a channel prefix) but... it allows you to create channel "+&test". Hmmm. So, on IRCnet, a client would need to parse channel names and prefixes in at least three different ways, depending on the mode prefix, the channel prefix, and the context.

One solution to this could be to extend CHANTYPES to CHANTYPES=#&!+:+ where characters listed after the colon are modeless. But this still wouldn't solve the way the "&" channel prefix is handled on IRCnet. We would need to further extend CHANTYPES to CHANTYPES=#&!+:+:& where the first set lists allowed channel prefixes (all of them for backward compatibility), the second set lists modeless channel prefixes, and the third set indicates prefixes whose behaviours are in a state of indeterminate quantum superposition and are generally beyond human comprehension.

Seriously, there are probably good reasons why these prefixes behave the way they do on IRCnet. The IRC protocol has changed in so many ways since IRCnet was created. Unfortunately, the issue of conflicting prefixes is there. Numeric 005 and CAP were intended to resolve issues like this by defining a consistent set of behaviours across IRC networks for basic features, so that IRC clients and servers could communicate more effectively. In this case, CHANTYPES is not sufficiently detailed to handle the ways in which the IRCnet ircd treats different combinations of prefixes.

Update: On second thought, extending CHANTYPES would not be backward compatible at all because most clients probably don't check for a : colon as a separator in this token, so this change would break all existing clients. A new 005 token would need to be created that describes all of the different ways that prefixes might be parsed.