keepnick: change nicks in +N channels #511

New Issue

2026-10-05T04:26:09+02:00

adam commented

2026-10-05 04:26:09 +02:00

Problem

I've encountered a problem that keepnick will just blindly keep trying to get the nick it's supposed to even if the server replies to all such requests with information that the user is in a channel which disallows nick changes. It's a particularly inconvenient thing when joined into many channels which do that.

Proposed solution

What keepnick could do is listen out for such failed nickchange replies and temporarily part from the channels in question. Then do the nickchange and rejoin. What should be, however, also accounted for is if how will ZNC be able to rejoin the channel (passworded/invite-only channels). It might not be particularly elegant so maybe keepnick should have an option whether do be this agressive or not.

Details

The types of reply vary per IRCd making this harder to nicely implement.
Reply on UnrealIRCd: (only sent for one channel when in multiple channels with +N)
:server 447 nick1 :Can not change nickname while on #chan (+N)
Reply on Freenode: (doesn't even have +N but has same kind of block possible)
:server 435 nick1 nick2 ##chan :Cannot change nickname while banned on channel
There might be more different ways for other IRCd-s.

#### Problem I've encountered a problem that keepnick will just blindly keep trying to get the nick it's supposed to even if the server replies to all such requests with information that the user is in a channel which disallows nick changes. It's a particularly inconvenient thing when joined into many channels which do that. #### Proposed solution What keepnick could do is listen out for such failed nickchange replies and temporarily part from the channels in question. Then do the nickchange and rejoin. What should be, however, also accounted for is if how will ZNC be able to rejoin the channel (passworded/invite-only channels). It might not be particularly elegant so maybe keepnick should have an option whether do be this agressive or not. #### Details The types of reply vary per IRCd making this harder to nicely implement. Reply on **UnrealIRCd**: (only sent for one channel when in multiple channels with +N) `:server 447 nick1 :Can not change nickname while on #chan (+N)` Reply on **Freenode**: (doesn't even have +N but has same kind of block possible) `:server 435 nick1 nick2 ##chan :Cannot change nickname while banned on channel` There might be more different ways for other IRCd-s.

adam closed this issue

2026-10-05 04:26:09 +02:00

adam commented

2026-10-05 04:26:10 +02:00

If the user was banned and the user parts the channel, they would not be able to re-enter the channel. (Regarding the Freenode reply).

If the user was banned and the user parts the channel, they would not be able to re-enter the channel. (Regarding the Freenode reply).

adam commented

2026-10-05 04:26:11 +02:00

The Freenode reply is misleading in its wording, it doesn't mean the user is banned, it means changing nick is banned. But the actual +b case is also be handled specially for this to not cause any havoc. If there is such situation the nick change could be cancelled with respective user message saying nick change by cycle isn't possible either.

The Freenode reply is misleading in its wording, it doesn't mean the user is banned, it means changing nick is banned. But the actual +b case is also be handled specially for this to not cause any havoc. If there is such situation the nick change could be cancelled with respective user message saying nick change by cycle isn't possible either.

adam commented

2026-10-05 04:26:12 +02:00

Oh, that makes more sense. I like the idea of this concept though. Although I would suggest it would be a toggle preference within the keepnick settings?

Oh, that makes more sense. I like the idea of this concept though. Although I would suggest it would be a toggle preference within the keepnick settings?

adam commented

2026-10-05 04:26:12 +02:00

A setting would be quite appropriate because many users might not want ZNC to take such aggressive action.

A setting would be quite appropriate because many users might not want ZNC to take such aggressive action.

adam commented

2026-10-05 04:26:13 +02:00

Hi, is there a workaround for this, other than disconnect/reconnect znc to the IRC server?

Hi, is there a workaround for this, other than disconnect/reconnect znc to the IRC server?

adam commented

2026-10-05 04:26:13 +02:00

could it be because of freenodes +r? or maybe +q $~a?
r (block unidentified) This mode prevents users who are not identified to NickServ from joining the channel. Users will receive a server notice explaining this if they try to join. /mode #channel +q $~a can be used to prevent unregistered users from speaking in channel while allowing them to join.

anyway its irrelevant. this would be very useful for freenode as it seems that whenever my znc is forced to reconnect, it ends up in all channels with my altNick and then several channels prevent it from changing nicks back to my main nick, preventing me from identifying (could possibly be solved my grouping altnick in nickserv). then i have to find and part each chan one by one so i can change my nick, identify, then rejoin them.

could it be because of freenodes `+r`? or maybe `+q $~a`? `r (block unidentified) This mode prevents users who are not identified to NickServ from joining the channel. Users will receive a server notice explaining this if they try to join. /mode #channel +q $~a can be used to prevent unregistered users from speaking in channel while allowing them to join.` anyway its irrelevant. this would be very useful for freenode as it seems that whenever my znc is forced to reconnect, it ends up in all channels with my altNick and then several channels prevent it from changing nicks back to my main nick, preventing me from identifying (could possibly be solved my grouping altnick in nickserv). then i have to find and part each chan one by one so i can change my nick, identify, then rejoin them.

adam commented

2026-10-05 04:26:14 +02:00

Well, I was identified because all the nicks I use are registered. So I doubt it's either of those.

Well, I was identified because all the nicks I use are registered. So I doubt it's either of those.

adam commented

2026-10-05 04:26:15 +02:00

this would be very useful for freenode as it seems that whenever my znc is forced to reconnect, it ends up in all channels with my altNick and then several channels prevent it from changing nicks back to my main nick, preventing me from identifying (could possibly be solved my grouping altnick in nickserv). then i have to find and part each chan one by one so i can change my nick, identify, then rejoin them.

http://wiki.znc.in/FAQ#Why_does_ZNC_connect_with_my_altnick.3F

> this would be very useful for freenode as it seems that whenever my znc is forced to reconnect, it ends up in all channels with my altNick and then several channels prevent it from changing nicks back to my main nick, preventing me from identifying (could possibly be solved my grouping altnick in nickserv). then i have to find and part each chan one by one so i can change my nick, identify, then rejoin them. http://wiki.znc.in/FAQ#Why_does_ZNC_connect_with_my_altnick.3F

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#511