Anope IRC Services

Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1]   Go Down

Author Topic: Ability to customize useable characters in vhosts  (Read 18437 times)

0 Members and 1 Guest are viewing this topic.

whotookspaz

  • Guest
Ability to customize useable characters in vhosts
« on: June 21, 2007, 02:00:30 AM »

Some ircd's such as Inspircd support host cloaking with some characters that aren't supported by HostServ atm (in Inspricd's case, you can supply custom characters). Because you can customize characters, I think that valid host characters that can be allowed should be specified in the conf file.
Logged

katsklaw

  • Guest
(No subject)
« Reply #1 on: June 21, 2007, 11:37:11 AM »

Just because 1 software package supports something unusual doesn't mean they all should. After all you can rob a bank with a gun, but that makes it neither legal nor a smart to do.

Hosts should follow the same protocol they are imitating, in this case, all hosts needs to be formatted in the same fashon as a FQD. This is not only for protocol compliance but to prevent confusion to clients as well as other daemons on the network. Some characters are disallowed on IRC, period. There are many reasons for this, some stop confusion between scripts and clients, other for daemons and even some are restricted to prevent confusion in the program langauge it's self.

In short, Inspircd isn't what dictates the IRC standard and if they choose to do something that breaks ANY related protocol including, IRC, identd, ntpd, TCP/IP or any of the numerous DNS, domain naming conventions/protocols then that's on them.

IRC depends on a very strict nick!user@host.tld format in which RFC1459 is VERY clear, altering that in any fashion is just asking for trouble. It's cool for a software package to try new things to become more popular, but not as the expense of established protocols or any of it's users.

[Edited on 21-6-2007 by katsklaw]
Logged

djGrrr

  • Anope User
  • Offline Offline
  • Posts: 51
    • http://www.p2p-network.net/
(No subject)
« Reply #2 on: June 22, 2007, 04:31:28 PM »

katsklaw, if people want to use vhost characters that aren't rfc compliant, thats their problem, many characters will not break rfc, anope's hostserv doesn't allow many vhosts that are rfc compliant, for example, all vhosts are required to have at least 1 dot in the host side; first of all, .'s should not be required, most if not all ircd's could care less if there is a dot, but not only that, the : character is a perfectly valid (like for ipv6) and its not even allowed in a vhost, that makes no sense.

have you ever seen the freenode ircd ? it has ='s in the username field, and /'s in the host field (like lu_zero!n=lu_zero@gentoo/developer/lu-zero), this doesn't break rfc or any clients. Just because you (one person) doesn't see a reason for it, doesn't mean that others don't. i would also like to see this feature.
Anyone who breaks things by using such a feature (like adding ! or @ to the char list) its their problem, not yours. you could even put a warning, use at your own risk in the example config file.
Logged
P2P-NET Network Staff

katsklaw

  • Guest
(No subject)
« Reply #3 on: June 22, 2007, 10:39:20 PM »

Quote
Originally posted by djGrrr
katsklaw, if people want to use vhost characters that aren't rfc compliant, thats their problem, many characters will not break rfc, anope's hostserv doesn't allow many vhosts that are rfc compliant, for example, all vhosts are required to have at least 1 dot in the host side; first of all, .'s should not be required, most if not all ircd's could care less if there is a dot, but not only that, the : character is a perfectly valid (like for ipv6) and its not even allowed in a vhost, that makes no sense.

have you ever seen the freenode ircd ? it has ='s in the username field, and /'s in the host field (like lu_zero!n=lu_zero@gentoo/developer/lu-zero), this doesn't break rfc or any clients. Just because you (one person) doesn't see a reason for it, doesn't mean that others don't. i would also like to see this feature.
Anyone who breaks things by using such a feature (like adding ! or @ to the char list) its their problem, not yours. you could even put a warning, use at your own risk in the example config file.


1> that was my "professional" opinion, not my personal opinion and I'd greatly appriciate if you would leave my personal opinions out of it, especially since you haven't the slightest clue as to what my personal opinions are! I could care less what any user does on their network. What I DO care about is the sanity of Anope CORE, that is what the FEATURE REQUESTS forum is all about .. the CORE.

2> That's VERY easy for you to say since you aren't the one sitting in #Anope day after day supporting Anope as I am or the rest of the dedicated regulars that tirelessly devote their time to helping the already confused userbase and to be frank I see no advantage to how having some/lame/ass/vhost/is/1337 is better/more secure .. etc .. than having a more compliant vhost of some.lame.ass.vhost.is.1337. This is noting more than an additional pain in th arse to support because someone that learned how to spell IRC this morning will come crying for support wondering why nick!user@host@that@they@want@to@use@cuz@djgrrr@sez@itz@k00l totally pissed off every client and server on the network.

3> If you want this so badly, write yourself since you seem to be a coder and submit it as a patch and perhaps it'll get added. The beautiful thing about GPL, open source code is you can always fix it yourself. Anope is a GPL project and anyone is welcome to submit patches, not just the devel team.

4> If I'm not mistaken many IRCds that Anope supports have vhosts in them already, I know unreal does.

5> We aren't trying to be like FreeNode, DALnet, UnderNet or XYZ net, just because you see it on some random network doesn't mean it's a good idea nor does it mean that Anope just HAS to do the same thing.

6> RFC1459 refers you to RFC 952 for hostname syntax and RFC952 only allows a period as a delimiter inside hostnames. Characters such as colons, commas and slashes are field delimiters nothing more.

[Edited on 23-6-2007 by katsklaw]
Logged

whotookspaz

  • Guest
(No subject)
« Reply #4 on: June 23, 2007, 09:29:49 PM »

I agree with djGrrr here, and anyways it can be made an option. If you don't like it, don't use it. And IMO, cloak/name is a lot neater than cloak.name, and is more readable.

Besides, anope already breaks the RFC's by supporting channel owner/protected modes. :P
Logged

katsklaw

  • Guest
(No subject)
« Reply #5 on: June 23, 2007, 09:52:54 PM »

Quote
Originally posted by whotookspaz
I agree with djGrrr here, and anyways it can be made an option. If you don't like it, don't use it. And IMO, cloak/name is a lot neater than cloak.name, and is more readable.

Besides, anope already breaks the RFC's by supporting channel owner/protected modes. :P


Not true, the RFC1459 does not mention modes +qa, therefore it's not a violation of RFC1459, unlike your suggestion that directly violates RFC1459 as it states that dots are the only acceptable hostname delimiter.

Secondly, as I stated, it's not just an issue of use, it's an issue of support .. be it a client, ircd, user or what have you. I refuse to condone a change to Anope that is simply for YOUR vanity and assigning insurmountable headaches to myself and the other Anope supporters just so you can be cool.
Logged

whotookspaz

  • Guest
(No subject)
« Reply #6 on: June 24, 2007, 07:10:09 PM »

Well, it's not about vanity, it's about the look of the hostmask. staff/network looks a lot better than staff.network, it's easier to read. Besides, I could already be vain with the current character set. And if people choose nonstandard characters in hostmasks, do what you do with /os raw and refuse support.

[Edited on 24-6-2007 by whotookspaz]
Logged

Jobe

  • Contributor
  • *
  • Offline Offline
  • Gender: Male
  • Posts: 1023
    • Anope IRC Services
(No subject)
« Reply #7 on: June 24, 2007, 08:05:23 PM »

Newsflash: How it looks = vanity

http://dictionary.reference.com/browse/vanity

Definition 1: excessive pride in one's appearance.......

[Edited on 24-6-2007 by Jobe1986]
Logged
Your IP: ()
My IRC Status:

Come along and visit http://www.anopequotes.org/

whotookspaz

  • Guest
(No subject)
« Reply #8 on: June 25, 2007, 01:41:59 AM »

All I asked for was a feature. This isn't about pride in my hostmask :(. In any case, I didn't ask about a specific character, I asked if it was possible to select what characters were allowed to begin with. Just chill out...

[Edited on 25-6-2007 by whotookspaz]

[Edited on 25-6-2007 by whotookspaz]
Logged

Starnestommy

  • Guest
Concerning vanity
« Reply #9 on: June 25, 2007, 01:47:06 AM »

Aren't nickname and channel registration vanity?  The only reasons nickname and channel registration services were made was to ensure that one could own nicknames and channels and so that nobody else could claim them.  Not allowing non-standard characters in hostmasks simply due to vanity is similar to abandoning NickServ and ChanServ.   Also, RFCs aren't meant to be a strict definition, they're meant to help standardize protocols.    Additionally, freenode uses non-standard hostmasks as cloaks, and most clients have no problem with those cloaks.
Logged

katsklaw

  • Guest
(No subject)
« Reply #10 on: June 25, 2007, 03:19:00 AM »

nicknames are about as vanity as your real name, the only difference is in real life you can have more than 1 Bob Smith. Names are labels, not vanity. Owning a channel is like owning a house, nothing vanity about them either unless you start bragging about how big or how your house is so much better than everyone elses, which is not what houses were designed for.

Second, the RFC's are rules, and you are wrong, they ARE meant to be strictly followed, they are not guidelines that you can choose to obey or ignore at a whim. It doesn't matter if FreeNode gives away free pie and chips, that's not the point. The point is that allowing non-standard characters as hostname delimiters serves no other purpose that to be cool, period .. full stop.

[Edited on 24-6-2007 by katsklaw]
Logged

whotookspaz

  • Guest
(No subject)
« Reply #11 on: June 25, 2007, 03:49:25 AM »

Dude, relax. This isn't something to get your shorts into a wad about.

BTW, RFC's are recommendations, not rules. They're not standards. Though not following them can cause problems, in this case it's no big deal, seeing as I've seen several networks that support this without thousands of clients going insane or servers blowing up. Most ircd's don't follow the RFC's for linking servers, and use different protocols altogether. Does this mean we should scrap them?

And another thing, what if I want to *limit* what characters can be used? Specifying what characters can be used in the conf file can not only be used to add, it can be used to restrict as well. For example, I could prevent all-caps hostmasks from being used (that is, if the allowed character list is case-sensitive).

[Edited on 25-6-2007 by whotookspaz]
Logged

Starnestommy

  • Guest
(No subject)
« Reply #12 on: June 25, 2007, 03:52:02 AM »

Also, standard hostmasks can also be used to look cool, just as non-standard ones can be used for reasons other than looking cool, such as showing status as a staff member or a project head.
Logged

Jobe

  • Contributor
  • *
  • Offline Offline
  • Gender: Male
  • Posts: 1023
    • Anope IRC Services
(No subject)
« Reply #13 on: June 25, 2007, 03:12:34 PM »

The idea beahing vHosts is to hide your real host, not to look "cool".

RFC 1459 specifically defins what hostsmasks are ALLOWED to contain and refers you to another RFC for that which rejects the use of /'s as at least one example.

If you want your /whois to look cool, look into using SWHOIS that some IRCd's support (including InspIRCd and UnrealIRCd) where you have no limit except in length as to what you ca have in your SWHOIS. Hosts are meant to be just that, hosts, whether false hosts or not, they are required (not advised) to be within the guidelines that specify their character sets.

RFC's were and are designed to be standards that should be followed, not reccomendations that are optional to follow. If everyone took the attitude "oh well theyre only reccomendations so we can implement such and such a protocol as we wish" things like HTTP, FTP, SMTP, POP3, IRC and various other protocols that we take for granted would not work globally.

If you want to end up running a network that no IRC client can connect to then fine go ahead, change the protocol, but bear in mind, going TOO far outside of the standard makes your creationg not even the protocol it claims to be.

The biggest problem with most clients and hosts using non-standard chars is that most clients expect the hosts to follow the rules layed out in the RFC's and as such can result in client crashes, client settings screwing up, client desynchs and just about any other error you can think of.

As for server to server protocol, that isnt strictly controlled by RFC1459 and as such is entirly up to IRCd writers to define themselves. Changing the sever to server protocol doesnt affect clients as long as the client protocol remains in tact. Most IRCd's translate server to server messages into client compatible messages.
Logged
Your IP: ()
My IRC Status:

Come along and visit http://www.anopequotes.org/

Trystan Scott Lee

  • Contributor
  • *
  • Offline Offline
  • Gender: Male
  • Posts: 343
(No subject)
« Reply #14 on: June 25, 2007, 07:55:34 PM »

Debating whether the RFC allow it or not will only turn you blue in the face. Consider reasonable solutions that puts the grenade back in the hand of the monkey end user

Since Anope's set code is modular the commands to check for valid hosts is in there - so end user can make their own module and avoid the host check altogether, or have it with its own valid host checks, so that what ever letters combinations you like are possible.  This means the end user can decide on their own.

So lets not debate whom is right and wrong but look at what is at hand and find things that work for both parties
Logged
my God my tourniquet, return to me salvation

djGrrr

  • Anope User
  • Offline Offline
  • Posts: 51
    • http://www.p2p-network.net/
(No subject)
« Reply #15 on: June 27, 2007, 10:51:54 PM »

Quote
Originally posted by katsklaw
Not true, the RFC1459 does not mention modes +qa, therefore it's not a violation of RFC1459, unlike your suggestion that directly violates RFC1459 as it states that dots are the only acceptable hostname delimiter.


what your saying is that ipv6 ips are invalid, according to your theory that rfcs are strict rules to follow, they are not, they are guidelines, which means if you don't follow them, there is a _risk_ that it MIGHT break some things.

a colon is a perfectly valid delimiter, and a delimiter is not even required (take localhost for example)

there is no reason not to have a feature like this, considering the fact that ircds that don't support these extra characters will most likely ignore vhosts with different characters
Logged
P2P-NET Network Staff

Midget

  • Anope User
  • Offline Offline
  • Posts: 1
(No subject)
« Reply #16 on: January 21, 2008, 02:55:55 AM »

8.1.1 Support of Unix sockets

   Given that Unix domain sockets allow listen/connect operations, the
   current implementation can be configured to listen and accept both
   client and server connections on a Unix domain socket.  These are
   recognized as sockets where the hostname starts with a '/'.

   When providing any information about the connections on a Unix domain
   socket, the server is required to supplant the actual hostname in
   place of the pathname unless the actual socket name is being asked
   for.


Seems the RFC does support use of / in hostnames to support unix sockets.

Otherwise there is no limitations on hosts except those set in RFC952 (which references RFC921) which if you are being strict to spec would make vhosts non RFC compliant for use on IRC networks because the RFC states any host is expected to translate down to its IP and vhosts do not. So either way youre not fitting the RFC952/921 specs which are a part of the spec for RFC1459.

We could argue this all day but pretty much no ircd or services follow the spec 100% as they are guidelines not strict rules. Also RFC1459 is defined as an experimental spec not an official spec anyways so it's not meant to be followed 100% in its current stat. It was meant to be commented on and updated to follow changes in the development of IRC. The fact it wasn't has no bearing on the fact IRC itself has in fact changed since its inception. It is still an experimental spec and therefore a guideline not an official set standard all irc has to follow 100%.
Logged
Pages: [1]   Go Up