#204 Control Ban Mask Type

[Kin Etix]

Well, I just had a small idea. I realized that when I ban
people, I have to edit their hostmasks myself. This
idea's not a big one, but it would be nice to see.

It'd be nice if there were an option to control how
ChanServ bans users from channels. (took this list from
mIRC)
0: *!user@host
1: *!*user@host
2: *!*@host
3: *!*user@*.host
4: *!*@*.host
5: nick!user@host
6: nick!*user@host
7: nick!*@host
8: nick!*user@*.host
9: nick!*@*.host

Like I said, it's not a big deal. But it's something I hope
to see. ;)

[Joe Hansche]

Logged In: YES
user_id=258370

As it is, unedited, you can use two different types of bans
with srvx (and it'd be possible to rebind NICKBAN to chanserv).

ChanServ.ban obviously bans as the #2 mask. OpServ's
NICKBAN will ban by method #1, if the user is authed and +x,
or method #3 if they are not +x.

The only problem with rebinding NICKBAN is that the command
does not use the parent bot as the actor. So if it were
bound to ChanServ.NICKBAN, doing !nickban would still make
OpServ set the ban, not ChanServ (could be fixed relatively
easily).

Overall, I would say that *!*@host will fix 90% of problems
in a channel, and with those few "other" cases, it really
isn't that big a deal to copy the rest of the hostmask. And
making the !*ban collection of commands take an optional
argument to indicate the banmask type would seem clumbsy,
and would often confuse most users (imagine a numeric
banmask indication like the mIRC examples above, and try
finding a foolproof way of implementing that with
!addtimedban, where it could take a numerical argumetn as
the number of seconds).

Another problem I could see with this, is when banning a +x,
authed user, with a #3 or 4 style as listed above. That
would include a much larger margin for inadvertently
matching bans, to include any "*.user.network" bans.
Obviously, NICKBAN has taken that into consideration by only
banning *!*user@host if they are +x, *!*user@*.host otherwise.