What about +d?

[HM2K]

I can honestly say that I think +d would be more useful than +e and +I put together, and I'm sure you could figure out why...

For those who don't know, +d bans the gecos/name in a channel, ie: "/mode #efnet.org +d gettiniton"

I know I can't get an official answer here, but I was wondering the kind of responce I would recieve on this...

[Jon]

I recall someone talking about +d would be better, not sure if it was in this forum or another (too lazy to check)

I actually forgot what +d does, and your definition wasn`t very clear... I`m not certain what a "name" is. Is that the "real name" that you see in a /whois ?

[lucy]

I actually forgot what +d does, and your definition wasn`t very clear... I`m not certain what a "name" is. Is that the "real name" that you see in a /whois ?

umm i thought it was just for the real name, or full name as its called in mIRC, but I just found this on the irchelp.org website.... so maybe its for more than just the real name field.

"New channelmode +d
This is an extended form of channel bans. These work on wildcarded strings, not hostmask. They will match anything in the users /whois , including servername, nickname, username, hostname, and realname. Example: /mode #channelname +d *John*Doe* . Prevents users with "John" and "Doe" anywhere in a whois field from joining #channelname. This is useful against certain types of clone attacks, as well as useful for denying access to a channel via a certian IRC server. Use this with care. Also not that it will not work completely unless all servers on the net are Hybrid 6."

[leeh]

umm i thought it was just for the real name, or full name as its called in mIRC, but I just found this on the irchelp.org website.... so maybe its for more than just the real name field.

The original hyb6 implementation (which was later removed) worked just on a clients gecos field. It is easy to extend to ban clients on a certain server as well however.

Personally, I dont think its worth it. Theres short term gain granted, in the long term you dont achieve much. A lot of drones have already adapted to bans on gecos fields done by servers - id expect them to do the same should channels get +d.

They might be useful if you had regexp support, but I doubt enough people would be able to use regexps to make it worthwhile. :)

[lucy]

They might be useful if you had regexp support, but I doubt enough people would be able to use regexps to make it worthwhile.

you should know someones gonna ask what regexp support is.... so go ahead and tell us and dont make me look it up

[munky]

regular expressions

^P[a-z]{2}[0-9]{3,4}$
would match strings that start with P, have 2 lower case letters, and end with 3-4 numbers

[Hwy]

But also remember the CPU load regular expressions would impart on a server. The original +d in Hybrid 6 used regular expressions (early betas) but it was changed to match() (wildcards * and ?).

What WOULD help and not cost much is an improved match(), like oomon's current implementation. You would have additional matching characters, such as # for a digit.

[Gozem]

But also remember the CPU load regular expressions would impart on a server. The original +d in Hybrid 6 used regular expressions (early betas) but it was changed to match() (wildcards * and ?).

What WOULD help and not cost much is an improved match(), like oomon's current implementation. You would have additional matching characters, such as # for a digit.

Saving CPU in all honor but really, the server today on EFnet uses sub 2-3% of the CPU in average.

[strikelight]

Man, I've been calling for the re-introduction of +d since it first was retired from EFNet after being 'unofficially' introduced.... Save your breath, if it hasn't happened since then, they obviously care not to bring it back.

[Hardy]

Man, I've been calling for the re-introduction of +d since it first was retired from EFNet after being 'unofficially' introduced.... Save your breath, if it hasn't happened since then, they obviously care not to bring it back.

Adding new features on EFnet is quite a job. First of all you need to get the coders of several ircd`s to code it (csircd, ratbox & hybrid ), and then also create patches for older versions of these ( hybrid7, hybrid6 ). Then every admin need to implement this and restart their ircd...

Efnet doesnt have one uniformed ircd, and doesnt require admins to upate to newest version of something.. if a admin wanted to run hybrid5 I doubt anyone could object if it had patched in TS5 support..

Changes are good, but we cant add a new mode every month. This time admins agreed on numbers of bans, +I and +e.. perhaps +d is inserted in the next vote which i hope it takes a looong time until is casted

[HM2K]

+I and +e seemed to go through fairly quickly, as soon as I hear about it, they are being implimented... I can't see that its that much of a problem to impliment +d, just more of an excuse not to... You say that coders would have to change their code, but as far as I know, it is/should already be implimented, it simply needs to be enabled in the config, but I don't know, i'm no expert.

I see why +I and +e have been introduced, since they are pretty much a standard these days, with even mIRC recognising that in its channel properties... but I feel that +d would come in handy, maybe only in the short term, but who really knows the long term effects? but to be honest, I really can't see +d causing any problems, it may even be part of the solution to a few things.

[munky]

Saving CPU in all honor but really, the server today on EFnet uses sub 2-3% of the CPU in average.

true enough, but depending on the implementation of regexp, it can be a huge hit. can you imagine what would happen on a server with 10000 users if every connect/join was passed through a perl mod? (don't get me wrong, perl regexps are great, but the script interpreter isn't always the quickest) especially if someone did crazy stuff or wasn't good at writing efficient regexps.

[Gozem]

Saving CPU in all honor but really, the server today on EFnet uses sub 2-3% of the CPU in average.

true enough, but depending on the implementation of regexp, it can be a huge hit. can you imagine what would happen on a server with 10000 users if every connect/join was passed through a perl mod? (don't get me wrong, perl regexps are great, but the script interpreter isn't always the quickest) especially if someone did crazy stuff or wasn't good at writing efficient regexps.

Of couse is the regexp-interpreter written in C-code.

[leeh]

+I and +e seemed to go through fairly quickly, as soon as I hear about it, they are being implimented... I can't see that its that much of a problem to impliment +d, just more of an excuse not to... You say that coders would have to change their code, but as far as I know, it is/should already be implimented, it simply needs to be enabled in the config, but I don't know, i'm no expert.

It was actually a couple of years for +e to get through efnet - itd been around since hyb6.0 which was eons ago. :)

[prefect]

I don't remember if +d had this functionality, but it would be very useful to have a channel mode to block out users on specific irc-servers. We've all experienced trojan/drone/proxy-kiddies taking advantage of servers with no active opers (no active opers there and then), and it would be cute to have the possibility to ban the whole server temporarly.

Or ircadmins could be better at adding eachother as tcmopers or whatever, not having active opers on a server that allows clients without ident and/or hostname is asking for trouble.

Edit: edited because it's early in the morning.