> Problem: > *!*@* masks strongly mess up channels when used in kick/ban > > Example: > - Get level 100 in a channel (so you can ban)
The very fact that this requires level 100 on a channel means that it is not IMO a coding issue. It is the responsibility of the 400+ users, and thus ultimately of the channel manager, to exercise care in the selection of ops. It is similar to the case where a person on an unregistered channel ops another person, who proceeds to mass-deop the channel, leaving themselves as the only op - it is not the coders' fault for allowing it, but the fault of the person who gave the abuser ops. > Result: > Flood away, coz noone can op himself since he is no longer allowed to be op > (*!*@* matches all users and equals NOOP that way with the difference that > every 100+ can do that without needing permission from a 450+) 1. If a chanop abuses the channel they are opped on this way, by flooding or permitting others to flood the channel in this manner, a 400+ op can and should put an end to this by removing the offender's access. 2. If the channel manager fails to take action against this (by either removing the offender's access or having a 400+ do so) then the channel is abusing Cservice and should be dealt with accordingly. > Solution: > Finally get rid of *!*@* usage !, its only abused by a lot of users (Greg, > perhaps you want to start logging the *!*@* usage to get some stats > yourself) to create massjoinfloods, disrupt the channel activity and in that > way be able to put load on the servers. *!*@* bans are NOT NEEDED TO BE USED > by clients, perhaps in kick if they want to clean up the idlers, but then I > suggest to limit the usage of kicks on *!*@* to 450, perhaps split the > command apart and make a /msg X kickall <channel> <reason> instead This involves extra string comparisons, which are not cheap in terms of processing time in C. Remember that X is a very heavily used service, and like ircu itself, any change that results in increased processing time for a commonly used command is likely to result in significant lag. > Another funny issue you haven't thought about is the fact that unban is also > affected by this issue, imagine having like 20 bans on a channel's banlist > in X, someone adding a ban on *!*@*, now do the math and make an estimation > what you need to do to remove this single ban without harming the other bans > in the list. This could be dealt with by adding a switch to the UNBAN command, for instance -exact, where if used only a ban that matches the specified mask -exactly- would be removed. This seems like a better and less expensive method. -- Aurorian
