On Thu, May 13, 2010 at 2:29 PM, Moiz Ahmed <sunny@sunnyindustries.net> wrote:
[snip] I agree this is not a bug in ChanServ implementation. I think the functionality of channel bans or the functionality of AKICKs might have been misunderstood.
Perhaps this is really a documentation or helpfile bug, if the documentation is confusing, or allows you to believe that AKICK'ing a nickname will actually work and AKICK instantly on nick change, even if user is already joined to the channel. Actually, AKICK did not work that way, even for bans based on hostname, the user already present in channel stays there, and does not instantly get banned on addition of a matching AKICK, if already in the channel. Channel BANS or AKICKS do not prevent a user from utilizing a nickname. Banning/akicking nickname!*@* has not been documented as a way of preventing a nickname from being present in a channel. Not a feature of bans/akicks, and the value of such a feature is unclear. Nickname is not really a good way of singling out a user for a ban, since they can simply use another unwanted nickname; presumably there are not just a small number of nicknames you would not want used in your channel -- it would likely be impossible to anticipate every possible unwanted nickname, and would utilize signfiicant banlist resources to even try to make a list of unwanted nickname patterns. You can inform the user that a nickname is unacceptable, and ban that user by hostname, when they violate the rule, or use a client-side script to effectively implement an automatic ban on use of a verboten nickname. These should be adequate workarounds. Banning a nickmask is not that I know of, an officially supported method of preventing nickname used, and also happens to not work. Attempting to use a 'feature' that does not exist, or using a facility in an unsupported way, does not result in the software being buggy when it doesn't work like you would hope... 'banning' or akicking a nickname in that matter does not have the effect of preventing a nickname from being used. Banning or Akicking prevents users from JOINING a channel. They do not eject members already in the channel, who now suddenly match a ban entry or akick entry, due to changes that occured after they joined. Believe this is well-known behavior expected by most users.
2. You want chanserv to keep a check on nick change and Chanserv will verify if the changed nick is not in akick and if the nick is in akick it should kick? Solution: Not possible - Why? Because there are millions of channels and millions of users changing their nick every second. Imagine the traffic of check commands genetered in the Chanserv checking for nick changes. \
I firmly disagree with the suggestion that it is not possible. It might be more trouble than it's worth, or come with too much baggage or complexity (such as some CPU requirements and significant memory or storage requirements), but that's all. There are many ways to efficiently implement a facility that automatically kicks a user based on nick change (probably the best way would be to utilize forced /PARTs and off-load this work to IRCD, or build a large table of banned nick/channel combinations, in the form of a compiled nickname-matching table for each channel). However, the behavior might be unwanted, and also, the utility and overall worth of such a feature seems questionable, especially given how much development effort and continuing maintenance a complicated feature like that would require, and the futility of actually banning specific unwanted nicknames.... It might be something to consider, but I do not see that it should be given priority.... -- -J