DCC2 Protocol for IRC file transfers

Joe_Hypnol writes "I just noticed this bit of news over at IRC Junkie. Looks like a bunch of irc client authors (and even more) are putting their heads together to come up with DCC2, a replacement for the the poorly designed DCC IRC file transfer specification. The old protocol was basically based on a usenet post, but this new one is looking like it'll be a full-blown standard. It's currently an IETF internet working draft. Read the press release at DCC2.org."

Comments

Where's IRC2?

[Anonymous Coward]

To replace the poorly designed IRC protocol?

Re:Where's IRC2?

[TheDisturbedOne]

Actually that would make more sence...

Re:Where's IRC2?

[hey]

Its called Jabber.
By the way, its too bad DCC2 isn't XML.

Re:Where's IRC2?

[MoFoQ]

yea...just like there's an Internet2.

Sadly, not all "sequels" are good. Take Batman 3 and 4 or Bush 2. Matrix 2 (Matrix Reloaded; Seeing keanu's butt scarred me for life).

And somethings don't need sequels, like p0rn. There will be no such thing is p0rn2 or p0rn3 as p0rn is more than good enough.

Re:Where's IRC2?

[Anonymous Coward]

IRC2 is dead. As is IRC3.
The proposals were once listed at the-project.org,
which is only available through the wayback machine
Both were afaik never implemented. ircd developers are resistant to changes.

Unfortunately Timo Sirainen never implemented his irc+ proposal which looks promising.

Well... somehow i guess we won't have to wait much longer for a nice proposal on how to _migrate_ away from IRC without having to use some oh-it-is-not-xml-we-have-to-reinvent-it protocol.

Re:Where's IRC2?

[pomac]

Cough, Isn't irc2 what we use today?

Why is the ircii client called ircii?

Why does the ircd's version number start at 2?

Re:Where's IRC2?

[Evil Adrian]

I think we need SMTP2 before we worry about IRC2...

Re:Where's IRC2?

[ikkonoishi]

XML isn't a protocol its a file format.

XML is horrible for anything you want to send files with at any decent speed.

The only thing good for it is that due to the text encoding it can go through most firewalls.

Re:Where's IRC2?

[Minwee]

Shouldn't we have slashdot2 first?

Re:Where's IRC2?

[ion_]

To replace the poorly designed IRC protocol?

It's here.

Re:Where's IRC2?

[VGPowerlord]

IRC2 is the protocol that's been in use for use.

How about an IRC3 protocol?

Re:Where's IRC2?

[VGPowerlord]

use for years, that is. My kingdom for an edit button!

Re:Where's IRC2?

[Trejkaz]

I think it's called MUC.

What's the best way to organize?

[turnstyle]

Just curious: when a bunch of smart authors get together to hammer out a new protocol, what's the best way to come to a consensus? Mailing lists? Blog? Wiki?

Re:What's the best way to organize?

[Anonymous Coward]

Just curious: when a bunch of smart authors get together to hammer out a new protocol, what's the best way to come to a consensus? Mailing lists? Blog? Wiki?

Water gun combat. Unless you want to resort to staplers.

Re:What's the best way to organize?

[Lennie]

Mailinglist with a wiki, who needs anything else ?

Reminds me, we need at work.

Re:What's the best way to organize?

[turnstyle]

Aren't mailing lists increasingly getting spam-filtered? And don't wikis have a tendency to get whacky?

Re:What's the best way to organize?

[Anonymous Coward]

Unless you want to resort to staplers
I get the red one

Re:What's the best way to organize?

[semafour]

Just curious: when a bunch of smart authors get together to hammer out a new protocol, what's the best way to come to a consensus? Mailing lists? Blog? Wiki?

We use a mailing list for most of our communication. That way people can read and reply whenever they want, and there is a public archive available.

Re:What's the best way to organize?

[Wog]

I've always been tempted to grab a stapler, open it like I'm stappling something the wall, and swing it as hard as I can at my roommate.

Would that make me a bad person?

This is good

[Anonymous Coward]

With all the attacks on p2p networks, DCC may be more needed than ever.

Re:This is good

[npoole]

Agreed, DCC is a method which brings little worry with what you're getting, who you're getting it from, and who exactly is watching you get it.

But you know, I'm inclined to think they'll naturally overdo it and then IRC will become prone to more investigation and threats.

IRC may be broken--but it always works, and any difficulty using it with splits and such, may weed out some of the lusers ;)

What's the difference?

[Anonymous Coward]

Can someone with insight please tell me what makes dcc2 better than traditional dcc?

Re:What's the difference?

[Kiriwas]

Right now? Considering there is no dcc2 and its still in the works... the same thing that makes Duke Nukem Forever better than original Duke Nukem.

Re:What's the difference?

[hey]

RTFA...

The current DCC protocol does not address IPv4 vs. IPv6 issues, SSL/
TLS encryption negotiation, NAT and Firewall traversal, or multiple
file/directory file transfers....

I got another idea

[slash-tard]

How about an IETF standard for warez serving bots. I hate learning the different commands for the different bots.

Re:I got another idea

[Anonymous Coward]

while not a ietf standard, the majority I find seem to be using xdcc ......

IRC, duh

[Anonymous Coward]

Everyone just joins #consensus.

Re:IRC, duh

[turnstyle]

Chat seems too dependent on everybody being available at the same time, and not so good for larger, more complicated ideas (as compared to conversational ones).

IRC file trading

[mrcutrer]

The only time I recall using IRC to get files is when looking for *cough*DVDrips*cough*

With the recent news of the governments attack on the piracy industry, and it is an industry. Would they go as far as to interfere with newly designed p2p protocols to stop piracy. The DeCSS case is kinda interesting in that respect.

Re:IRC file trading

[Anonymous Coward]

With the recent news of the governments attack on the piracy industry, and it is an industry.

You try telling that to the commitees responsible for issuing industrial grants. Trust me, you're going to have to provide a better argument that just "it is".

Re:IRC file trading

[mubar]

Just because you haven't used IRC and DCC for anything else, doesn't mean people wouldn't have legitimate and productive uses for it. The way DCC file transfer is designed to use is individual users sending an occasional file or two to each other. No different than the file transfer features more or less standard with any of today's IM clients.

This is totally unlike than p2p networks which we all know are designed for mass sharing. On IRC, it's only these xdcc bots and fileservs with all the kids "downloading moviez from mIRC" giving bad name for a good thing. And even with those, there certainly are more sensible ways to go than trying to forbid the development of an efficient protocol. Just take a look at twentysomething biggest irc nets: one or two are just for warez, some have rampant filesharing with many channels, but i'd say many, if not most, have only little or none of this stuff around. They simply don't allow channels advertising and serving any illegal files, thus minimizing the problem inside the network. And if two regular clients who know each other happen to exchange some files over irc, well they could've done it on ICQ too, no?

DCC2

[Tiberius_Fel]

Well, I for one think this will be quite good. It's very frustrating to try to DCC a document to somebody only to have it fail for a variety of reasons. I look forward to improving this standard. :-)

On the other hand, this does improve the IRC-for-filesharing thing that I've seen... way back in the day before Kazaa, my friends used to pick up their movies etc. from IRC channels... so this will facilitate that, I suppose... possibly not what the authors have in mind.

Re:DCC2

[Anonymous Coward]

IRC is still, along with Usenet, the intermediary distribution method between the core scene and the masses of people on P2P.

Re:DCC2

[Anonymous Coward]

On the other hand, this does improve the IRC-for-filesharing thing that I've seen... way back in the day before Kazaa, my friends used to pick up their movies etc. from IRC channels... so this will facilitate that, I suppose... possibly not what the authors have in mind

Most of the stuff on P2P networks originates from groups that release on IRC. So, it's probably exactly what the authors have in mind (not to say that they're encouraging it, but that they know who will benefit most from it.)

I've got an idea

[ThisIsFred]

Let's dump DCC (which isn't that bad, except for the TCP ports) and FTP, and come up with a decent transfer file replacement One that doesn't need 10,000 free ports, special firewall tuning, works through a layer of encryption without problems, but still doesn't generate a lot of overhead.

Re:I've got an idea

[Simon (S2)]

Let's dump DCC (which isn't that bad, except for the TCP ports) and FTP, and come up with a decent transfer file replacement One that doesn't need 10,000 free ports, special firewall tuning, works through a layer of encryption without problems, but still doesn't generate a lot of overhead.

hey! you are talking about ssh - sftp!

Re:I've got an idea

[warrax_666]

No, he isn't. To be able to use ssh/sftp all users need to have a shell account on the server(*). Thus, ssh/sftp cannot replace anonymous FTP.

(*) Though, I suppose one could have a "guest/guest" account which could not execute any commands. Still seems a bit dangerous to me if you only ever want to serve files anonymously.

Re:I've got an idea

[AllNicksWereTaken]

Look at WASTE.

Re:I've got an idea

[Simon (S2)]

No, he isn't. To be able to use ssh/sftp all users need to have a shell account on the server(*). Thus, ssh/sftp cannot replace anonymous FTP.

yes, he is. the openssh source is available under the gpl. how difficult can it be to get it, and integrate it into an irc client for file sharing?

Re:I've got an idea

[Hatta]

That's what rssh is for.

Re:I've got an idea

[undertow3886]

You can get a program called scponly (works with sftp too) and set that as your guest user's shell. It makes it so they can use sftp, but not log on with plain ssh and get a console. It works great for me.

Re:I've got an idea

[Anonymous Coward]

No. sftp is horrible slow so no thank you....

Re:I've got an idea

[Anonymous Coward]

Most irc clients let you set the port manually in the config, so you dont need all those ports.. For me only 2 ports is enough, cause i never need to dcc more than 2 files at the same time.

Re:I've got an idea

[jdowland]

Hmm, sounds very similar to /bin/false, with some bells and whistles..

Re:I've got an idea

[flatface]

Most IRC clients? Nosir. x-chat needs some special half-assed plugin. And others, like KVirc and irssi don't allow for it at all. Most of the time, you can get your IP address from the server, and it'll fix any problems with your sends. And that's also assuming you're not using ZoneAlarm or some other stupidly over-restrictive firewall.

Re:I've got an idea

[Anonymous Coward]

I've got /set dcc_port in my irssi.

Re:I've got an idea

[juhaz]

As the AC stated, Irssi does have dcc port setting.

I guess this brings is to the biggest problem with it, lousy documentation. Python scripting module would also rock.

Re:I've got an idea

[rcw-home]

One that doesn't need 10,000 free ports

HTTP requires one free port.

special firewall tuning

HTTP is extremely easy to pass through a firewall.

works through a layer of encryption without problems

HTTP over SSL is very commonly used.

but still doesn't generate a lot of overhead.

HTTP only adds perhaps a kilobyte to the transfer and requires very little CPU overhead.

In addition to this, HTTP supports resuming, content types, proxies, and is not tied to any particular authentication scheme.

Perhaps most importantly, HTTP is very widespread, widely understood, and proven.

Re:I've got an idea

[jo42]

WASTE is a software product and protocol that enables secure distributed communication for small (on the order of 10-50 nodes) trusted groups of users.

Seems kinda limited, no?

There must be some mistake

[PetoskeyGuy]

They revamped the whole protocol but Ratios weren't mentioned even once. Are they sure this is for IRC?

Re:There must be some mistake

[Anonymous Coward]

hmm i have yet to see a ratio fserve (thats what i assume you are refering to)
either way. if something had a ratio. i doubt it would be popular, move on to the next one.

because for a lot of people, bandwidth is free(/next to free).

Re:There must be some mistake

[N1KO]

I have seen ratio fserves. Btw, if the bandwidth thing were true you wouldn't see giant queues on fserves either.

PIrates rejoice

[toupsie]

Is DCC used by anyone else but file pirates and music traders? I mean really. Come on. Don't lie. Oh sure, you know a guy who has a cousin with a good friend that has a girlfriend whose brother distributes his folk music on IRC but besides that, anyone else using DCC for legit transfers?

Re:PIrates rejoice

[Tiberius_Fel]

I seriously use DCC for things other than pirating. DCC is commonly used by my particular group to pass along logs, interesting documents, proposals & updates, et cetera. In a sense you might say it's like P2P - it's used by a lot of filesharers / pirates - but it's not the exclusive domain of those types.

Re:PIrates rejoice

[lokedhs]

I can testify to using DCC for legit reasons. It's a very useful tool when you want to send a file to someone you are talking to.

Maybe you should try to use your computer for something else apart from sending pirated music to your friends and you'll realise that there are other uses for file transfer?

Re:PIrates rejoice

[DJayC]

Um, yeah. Just about any time I need to send a file to a friend on IRC I would use DCC. For example, "Hey take a look at this logo", or "You need help? Send me your .cc file".

It seems like you have only been exposed to bots using DCC to send you files. You are talking about someone who distributes music on IRC or whatever, when in reality DCC is more than a means for bots to offer files. Normal users send files too... it's just like sending an email attachment.. you use those don't you?

Re:PIrates rejoice

[notamac]

Sure people do... it goes something like this:
boy: hi
girl: hi
boy: asl?
girl: 19/f/someplace
boy: pic? :)
girl: [dcc send]

Of course feel free to replace girl with [boy pretending to be girl]

Re:PIrates rejoice

[Fnkmaster]

Sure it is. I recently got all kinds of goodies on #asterisk for my Cisco 7960 IP phone and my Asterisk box - config files for *, phone config files, firmware updates and older firmware versions for the Cisco phone that Cisco tries to completely screw you by limiting download to registerd Cisco service contract holders (the latter items may be technically illegal to redistribute, but Cisco makes you wait up to two to three weeks to get a service contract and get access to them and provides no means for online or direct purchase, forcing you to go through a reseller - in short, they just don't want to bother with you, so there's not much of an option besides IRC).

Anyway, I don't remember the last time I used IRC for music or warez. The real question is who the hell uses IRC for music or warez these days?

Re:PIrates rejoice

[Felinoid]

Reminds me of..
Boy Pretending To Be Girl: Wana see my pussy?
Felinoid: No
BPTBG: Come on..
Felinoid: No
BPTBG: Here it comes
{DCC request rejected)
Felinoid: I said NO!!!

In case your wondering BPTBG was a known and we'd just had a heated debate. This was going to be a grose picture or a hack attempt.

Re:PIrates rejoice

[toupsie]

It seems like you have only been exposed to bots using DCC to send you files. You are talking about someone who distributes music on IRC or whatever, when in reality DCC is more than a means for bots to offer files. Normal users send files too... it's just like sending an email attachment.. you use those don't you?

If I want to send a file, I am going to use a better method than DCC. Once again, we have the 1% trying to parade around as the majority. Don't insult our intelligence here, a vast majority of the files transfered by DCC are pirated. You log files aren't the size of DVD rips unless you don't know how to get things working.

Re:PIrates rejoice

[damiangerous]

People running FServes aren't, no. But DCC transfers are used regularly by the casual IRCer. Any time you want to send a file to someone you're talking to on IRC you just DCC it.

Re:PIrates rejoice

[gnu-generation-one]

"Is DCC used by anyone else but file pirates and music traders?"

Of course. It's used for sending pictures, so people can see who they're chatting with.

It's used to send drafts of collaborative documents.

It's used for anything that you'd use email attachments for (when the file is too big to send by email, and you don't want to wait for a carrier-pidgeon or setup an FTP server)

It's used by terrorists to DCC blocks of semtex to each other without having to meet

[[ Please do not feed the trolls ]] -- sorry, did I miss that sign earlier?

IRC is a chat protocol by default, not a file-share protocol. Use GNUNet or BitTorrent or Konspire2B if you want to distribute music efficiently

Re:PIrates rejoice

[gmhowell]

I use it for text file eBooks, which are the only ones my blind wife can read on her computer.

(FWIW, I already own about 99.44% of the books I've gotten this way. Call it format shifting.)

Re:PIrates rejoice

[fr0dicus]

If I want a config file from someone in a project discussion room I'd only ever use DCC, unless they could post an URL to somewhere I could download it; nothing is more anonymous. Too many people log channels for it to be safe to wantonly pass e-mail addresses about on IRC.

Re:PIrates rejoice

[Kjella]

If I want to send a file, I am going to use a better method than DCC. Once again, we have the 1% trying to parade around as the majority. Don't insult our intelligence here, a vast majority of the files transfered by DCC are pirated.

And what "better method" of sending files would you suggest, that is not used by pirates? FTP? HTTP? IM? E-mail? Newsgroups? P2P networks? SSH? Bullshit. They're all used for piracy. And the $100,000 dollar question, if it's that much better, why aren't the pirates using it as well?

I think that if you made a survey, you would find that a damn large part of Internet traffic is caused by piracy. Should we just disband the Internet then, all lines, all protocols, because if we help it evolve we help piracy? Give me a break. Don't insult our intelligence by pretending that improving DCC in any way makes you responible for piracy. Go sue the US DoD for creating the Internet if you do.

Kjella

Re:PIrates rejoice

[Anonymous Coward]

Amen!

Re:PIrates rejoice

[pomac]

Is there any filetransfer protocol around that ISN'T used for sending just about anything?

Otoh, dcc isn't as efficent as some, it has size limits which some doesn't have. IMHO if someone wants to download shitloads of things they either
a, use a efficent protocol for it
b, go where there are alot of users

Irc fullfills b.

But irc isn't Direct-Connect. It's not p2p either.

Re:PIrates rejoice

[Anonymous Coward]

None of your post makes sense. Are you speaking for the Slashdot collective? File size shouldn't even come into the question. It happens. Just accept the fact that people sometimes do use DCC legitimately.

Re:PIrates rejoice

[liquidsin]

Well obviously, if you want to send a file, you'll use a better method than DCC because you're much better than the rest of us. Some of us don't want to fuck around finding the most 1337 way to send a file. If I'm already on irc and I need to send a file to someone else on irc, dcc is the obvious first choice. *THEN*, when it fucks up, I'll email it or post it on my website or icq it or something else. But take your head out of your ass and realize that some of us need these tools, even if the "bad guys" will have access to them too.

Re:PIrates rejoice

[Anonymous Coward]

Obviously you are lying, because everyone knows the proper extension for a C++ file is .cpp

Re:PIrates rejoice

[Quattro Vezina]

If I want to send a file, I am going to use a better method than DCC.

Maybe the average Slashdotter will use something better, but the average non-techie will just hit mIRC's ``send file'' button.

Back when I was really into IRC, DCC was used all the time.

``Hey, I wasn't here last night...anthing happen?''
``Here, let me send you my log''

``Whoa, I just found this really cool pic''
``Hey, can you send it to me?''

Now, yeah, most of the fserves/bots are distributing pirated stuff (and even there, it's not all piracy). But there's just as much one-on-one DCC out there that's used for perfectly legit purposes.

And DCC's not just a file transfer protocol--it's also a chat protocol, for private conversations not connected to the IRC network. If I want to chat with someone, and I want the chat to last longer than the IRC connection, I'll just start a DCC chat with them.

Re:PIrates rejoice

[teklob]

I use DCC to send files to users who are too inept to set up their firewall because in a DCC transfer, the reciever makes a connection to the sender. I wonder if this practice will be continued in DCC2?

Re:PIrates rejoice

[Ziviyr]

I'm part of one percent then.

Ironically a few days ago I had log files taking up over 4 Gs of my system too. I wish I were making it up...

Re:PIrates rejoice

[xenocide2]

Nobody said that there was a majority share of DCC transfers happening legally. But its a far cry from "come on, execpt for one guy who maybe shares his folk music online, nobody uses it for anything but warez." I've recieved several high quality mods for halflife over DCC, and sent just as many. I've also used DCC as a convinent way of sending someone source code or an executable. Maybe all you use IRC for is music acquisition, but it certainly does have other users, which shouldn't be ignored. Just because there's a criminal majority, doesn't mean there's a need to spite legitimate use.

And its not like DCC is the only protocol involved in massive copyright infringement. Just like FTP, HTTP, KaZaa, Samba and bittorrent, DCC is a medium of transport, a method of transferring files. What files you choose to transfer is a human matter, not a technical one.

Re:PIrates rejoice

[Punto]

Actually, most "pitates" (especially the anime fansubs, wich seem the produce the bigger ammount of data every week) switched from DCC to bittorrent a couple of years ago..

This announcement looks interesting since dcc was never intended as a pirate protocol, but it became the default for several years.. Now that it's obsolete again, they announce a new version.. Of course, it wouldn't make sense to just build a bittorrent client/tracker on the irc clients and call it 'dcc2'.. DCC is mostly used to send files to your buddies, or pictures for "cybersex", so bittorrent would be too much overkill for that.. It sounds like they're just trying to fix the NAT problems, encryption, etc.

Not that I'm trying to "defend DSS's good name"; I used to get all my pirated anime and other goods using dcc, and I'm very grateful for all the years of copyright infringement it gave me.

Re:PIrates rejoice

[p00p at instable.net]

I dunno about all that but I sure am glad they're working on this just in time for Operation Fastlink! :)

Re:PIrates rejoice

[UpnAtom]

Not sure if this is the same thing, but this SpamPal plugin uses a "DCC" network to check how many other people have received a similar email.

Re:PIrates rejoice

[p24t]

People don't use DCC much cause IT SUCKS. When someone wants to send me a copy of the new web layout, or an audio clip they made, or even just do a DCC chat, 9 times out of 10 it doesn't work. Unless I'm not behind a firewall, they're not behind a firewall, ports have been opened, or for whatever reason, DCC just decides to work.

If DCC2 is available, and it actually works, then people will start to use it more often. I sure as hell will.

Re:PIrates rejoice

[Anonymous Coward]

It's used by terrorists to DCC blocks of semtex to each other without having to meet

The IRC community tended to take themselves way too seriously back then. The term "terrorism" was in common use as referring to people launching DOS attacks on other IRC users (DOS in those days referred to a another shitty operating system from Redmond). It looks pretty silly in retrospect. Hell, it would have looked pretty silly at the time to anybody outside that community.

Re:PIrates rejoice

[Lord_Dweomer]

What a troll. First off, it doesn't matter what the majority of the traffic is used for. If even one person uses it for transferring a file legally, it has a legit use. Period.

Also, you seem to be ignoring the MASSIVE anime community presence on IRC. If anything rivals the porn and warez traders, its the anime traders, and I've got news for ya, if its not licensed in the US, its alright to trade it.

I only use IRC for anime currently, so there's your legit use for it troll.

Re:PIrates rejoice

[CTachyon]

Don't insult our intelligence here, a vast majority of the files transfered by DCC are pirated.

A vast majority of files transferred by Internet are pirated. A friend (who just left the movie scene) and I (a neutral observer) once computed that high-level piracy (raced FTP sites and the like, mostly sitting on fat telecom links "borrowed" by otherwise legit admins -- the sort of piracy that the FBI didn't know existed until recently) consumes about 50-75% of all bandwidth on the Internet. When a single download thread for a single person can transfer a 3 SVCD movie in about 2 minutes, and there's other people doing the same thing on the same site, and there's dozens of sites out there, you know that there's some serious bandwidth utilization going on.

Sooo....

[PhrostyMcByte]

does this mean i'll be able to get warez even faster?

Hmm...

[Dark Lord Seth]

Why not kick in some p2p as well? If you're going to download a x00 mb file, then you might as well be a good neighbor and share some of that upstream bandwidth you've got there. And if p2p is not an option, why not just take a random OS FTP server, stuff it in an IRC client, let the initial connection go through the server and let browsing & data-transfer go through a direct connection.

Seems to me that writing a file transfer protocol ( Where have I heard that before? ) would be like reinventing the wheel. I mean, it's useful, sure. It's also been around for ages, as well.

Re:Hmm...

[AllNicksWereTaken]

Then it wouldn't be DCC anymore. DCC is for direct connections.

Re:Hmm...

[Anonymous Coward]

DCC is for direct connections.

P-P is also for Direct Connections, meaning that the server is bypassed.

Although I'm not so sure I want to include P-P with DCC2 - leave the P-P up to P-P networks and leave DCC as it is - with only 1 other host to transfer files with. Changing the protocol to distribute distribution across multiple hosts will only (1) become lame (2) be a pain in the ass to implement and (3) make IRC no better than other P-P networks.

Insightful AC post, film at 11

[metamatic]

Yeah, that was my thought too. It's very much a case of rearranging the deck chairs on the Titanic.

The IRC protocol is flawed. Not just superficially broken, but horribly, fundamentally broken in numerous ways. As a result it's unreliable (prone to network splits), puts massively unnecessary load on servers, has problems with contention for nicknames, and so on. It really needs complete replacement.

Mind you, now that we have XMPP, there's a strong case for just letting IRC slowly die and having XMPP chat rooms take over.

Re:Insightful AC post, film at 11

[Anonymous Coward]

mh... you miss one point. Jabber is Instant Messaging Technology, IRC is multicast technology.

Jabbers groupchat implementation is far less scalable than IRC. Ever seen a jabber chatroom with > 2000 People?

Re:Insightful AC post, film at 11

[hitmark]

the only way to get around network splits are by redundant links and high capasity servers and links, not by a redsign of the server. say a router goes down between 2 irc servers, most links will at best slow down as packages gets redirected to backup links but some may go down as the new route cant handle the amount of traffic.

unessesary load on servers? please enlighten me as i belive i have seen atleast one irc server written in perl so it cant be that heavy on load. sure the amount of traffic going over it and the fact that every channels traffic will be mirrored on every server can add a bit of extra load but as it all text you will only notice that "problem" on large network. and large networks should be run on industrial class servers and connections anyways, not you home pc.

as for the nickname problem, the only real solution there is temporary or permanent unique ids independent of nicks. temporary may be the best way with a option for permanent if you register a login account. and all this could be layerd on top of the existing protocol i belive, no need for a total rewrite. and personaly i down frown when i cant get the nick i want, sometimes 1337speak have its uses:)

xmpp? hmm, i dont know that protocol but given its name i have a feel that it have something to do with xml...

Re:Insightful AC post, film at 11

[dougmc]

please enlighten me as i belive i have seen atleast one irc server written in perl so it cant be that heavy on load.

Just because you can write an implementation in perl, that doesn't mean that it's not `heavy on load'. Whatever that means.

One guy even wrote an irc server in ircII script, just to show that it could be done.

Re:Insightful AC post, film at 11

[hitmark]

i was just trying to point out that its not the server or protocol that generate load but the amount of traffic going tru it...

Re:Insightful AC post, film at 11

[ikkonoishi]

I once found an irc server written in mIRC script.

Worked on version 5.92 I think.

Wait no here it is.

Works on 5.8 not 5.92

5.92 was what I had it running on though.

Re:Insightful AC post, film at 11

[epiphani]

Accually, I'd disagree.

While the protocol itself is in massive need of optimization and cleanup, it is essentially *extremely* efficient and effective.

Coming up with a system to maintain a state such as IRC is very hard to do in the methods you describe. Avoid netsplits? How? The internet is not reliable. Thus, IRC is not reliable. You talk about this as though you know something about it, but you cannot "fix" the problems you are talking about and have the result still being IRC.

Please, do explain your ideas - We're always interested in hearing them.

Re:Insightful AC post, film at 11

[Anonymous Coward]

XMPP has all the problems of IRC (or would have -- if it was scaled up to it), plus is much more complex and harder to write clients for.

Re:Insightful AC post, film at 11

[infiniti99]

Jabbers groupchat implementation is far less scalable than IRC. Ever seen a jabber chatroom with > 2000 People?

This is because no one uses XMPP/Jabber, not because of any sort of protocol deficiency.

The main difference between Jabber and IRC architecture-wise is that Jabber does not split a room across servers. However, with the way Jabber is designed, you have a lot more servers. IRC has segregated network clusters, while Jabber simply operates by domain over the open internet. With IRC, you have 10000 rooms hosted over 20 servers. With Jabber, you have 1000 Jabber servers, each with 10 rooms. This is a lot more scalable. In addition, "channel takeovers" are less effective under this model, as the rooms are centrally managed at the given domain. An admin could simply shutdown the room until a problem is remedied.

Not to mention that Jabber is also a more advanced system in general. There is no need for a DCC2, as the Jabber file transfer is already very good. There is no need to change your nickname to "Foobar|Away", as in Jabber there is actually an away status. What a concept!

That said, most implementations of XMPP/Jabber are not as mature as existing IRC implementations, so we're a ways off from world domination.

Re:Insightful AC post, film at 11

[Anonymous Coward]

> The main difference between Jabber and IRC
> architecture-wise is that Jabber does not split
> a room across servers.
No. In jabber, a group of people is not an fundamental concept. In IRC it is.

> This is a lot more scalable.
Distributing is the key to scalability. But jabber is centralizing the message distribution for groups.

Imagine the following situation:
3000 users from 3 different jabber servers in a chat room. As far as I interpret muc's conference_room.c (line 1385++) (i may be wrong... but dont want to give up relative anonymity and ask peregrine ;)
a message from a person would generate 3000 messages from the conference component to the three servers.
From there, each message goes to the client, resulting in 6000 * (sizeof message) * (xml-bloat factor) bytes being sent.
Maybe there is even a noticable amount of time between there first person receiving the message and the last one (the reason for such a high number of members ;)

Consider the same situation for IRC:
clients sends message to room.
room knows 'i have users from servers 1, 2, 3'
room relays message to servers 1, 2, 3 (three messages)
1, 2, 3 relay message to their client (3000 messages)
Resulting traffic: 3000 * sizeof(message)
Let alone those servers could redistribute the message, splitting the load even more.

Do you see what I mean? The IRC strategy is imho unapplicable to Jabber as a server is not required to redistribute for a group.

> There is no need to change your nickname to
> "Foobar|Away", as in Jabber there is actually an
> away status. What a concept!
Well... you're just pushing the AWAY to the client. IRC does not... unfortunately people are really abusing NICK for that.

Re:Insightful AC post, film at 11

[Anonymous Coward]

And SMTP is perfect?

Off-topic, i know, i know. But think about it: if there is *anything* that needs a complete replacement, it has GOT to be email, right?

Re:Insightful AC post, film at 11

[Bert64]

IRC already has an away status too, hence the /away command, unfortunately many clients and many servers don't implement it properly. mirc for instance shows you the away message every time you send a message to an away user (irritating), bitchx only shows it once.. Also the ircnet ircd atleast, only shows the away message when you do a /whois request if your on the same server, it used to show it regardless of what server you were on.. this is very annoying

Re:Insightful AC post, film at 11

[metamatic]

Consider the same situation for IRC: clients sends message to room. room knows 'i have users from servers 1, 2, 3' room relays message to servers 1, 2, 3 (three messages) 1, 2, 3 relay message to their client (3000 messages) Resulting traffic: 3000 * sizeof(message)

Except (a) IRC doesn't do that, servers have to carry traffic even for groups that none of their users are in; and (b) there's nothing stopping you doing that in a later revision of XMPP by allowing group-addressed messages to be sent once to a server.

Re:Insightful AC post, film at 11

[Anonymous Coward]

> IRC doesn't do that, servers have to carry traffic
> even for groups that none of their users are in
Implementation issue.

> there's nothing stopping you doing that in a later
> revision of XMPP by allowing group-addressed
> messages to be sent once to a server.
how do you make sure the other server does support that extension?

Re:Insightful AC post, film at 11

[metamatic]

OK, based on my own experience having used IRC for ten years for both work and play, here are 10 ideas to massively improve it:

1. Nicknames need to be per channel. Users should be able to specify a list of preferred nicknames, and the system would then deal with contention by scanning down the list for one not in use on the channel, or as a last resort by appending numbers or underscores or whatever.

2. There needs to be a persistent identifier for users, so I can tell that the person who was madpope yesterday is freshgoat today. The user@host worked back in 1988 when everyone was using shared UNIX boxes to IRC, but now most users are on random dialup or dynamic DNS addresses it's useless.

3. There needs to be smart routing. If #warez_jp is only used by people on two servers in Asia, the network needs not to send the traffic everywhere else.

4. There needs to be rate limiting on the server to prevent abuse and stupidity. Not just bandwidth rate limiting, but limits to stop bots that spam by changing the topic every 0.1 seconds, auto-rejoiners, and annoying trolls who type one word per line.

5. There needs to be a way to indicate when users are busy typing, so people aren't tempted to break up a single sentence into lots of annoying tiny bits. Either that, or the client software needs to be able to reassemble the pieces on the fly if no other user has made an intervening comment.

6. Actions, file transfer, user info query, idle time/away, busy flags, font styles, and colors need to be part of the core standard, as well as user icons for graphical clients.

7. The server network needs to be a mesh, not a two-headed tree, so there's no single point of failure.

8. There needs to be permission-based message approval, like in Jabber, to prevent spambots. For person-to-person, a "do you accept?" and for channels, a way to require (optionally of course) that at least one person on the channel agrees to let the person in. Yes, you can do the latter via +v or channel keys, but it's a pain and users don't understand it because the entire protocol is visible to them rather than being handled automatically.

9. Once you have persistent identifiers (see above), there needs to be an ACL mechanism for channels.

10. Ideally channel nicknames would be locally assigned. When I find a channel I like and join it based on the description, I should be the one to pick the #whatever alias. (Of course, the channel operators could suggest one, like with user nicknames.) This would prevent channel wars caused by people wanting the same convenient channel nicknames, and stupid bots that exist only to stop people using a channel name and advertise some other channel.

If anyone actually doing development on IRC-like chat systems wants to talk to me about the above, I'd be happy to provide more detail, thoughts on how to implement, and so on, when I have time. meta@pobox.com

They really should fix IRC instead

[lokedhs]

Anyone who ever implemented the IRC procotol knows just how crappy it is. Here's a few reasons:

Nicknames use SW-ASCII, yes that's right, the swedish variant of 7-bit ascii. That's the reason [ and { are equivalent, as is | and \.

There are no standard encoding. Most people use 8859-1, other languages use, well, whatever they happen to agree on. A number of other channels use UTF-8 which is the best solution (supports all languages) but is not supported by mirc.

Takeovers, splits, need I say more?

Server desync

I don't think DCC is a problem at all. It's all the other crap that needs to be fixed. Once you do, I'm pretty sure implementing good file transfers will be quite simple.

Re:They really should fix IRC instead

[Anonymous Coward]

pff.

You will continue to welcome your swedish masters!

Re:They really should fix IRC instead

[lokedhs]

I happen to be swedish. :-) Still hate the damn protocol though.

Re:They really should fix IRC instead

[Saiai Hakutyoutani]

SW-ASCII? Dude, thanks for the info, that really is interesting :) I wonder if I can use ö in my nick then.

I agree on the UTF-8. I'm trolling the boards of several IRC clients, but the progress is slow.

Re:They really should fix IRC instead

[Saiai Hakutyoutani]

Charset changed to: CSISO10SWEDISH
--- You are now known as... Nah, forget it, Slashdot filters it out anyway. But it really works!

Re:They really should fix IRC instead

[superjaded]

True enough that IRC was made back in the day when character encoding wasn't a real issue. It is today, however, but I guess I've been using IRC long enough that I just don't think of being able to communicate in Japanese or other such non-roman language.

Two of your latter points are fairly invalid these days on IRC though. Takeovers are effectively impossible through the use of channel services like Dalnet's Chanserv and Undernet's X/W.

Server desynch should also not be an issue if the network you're on is running any halfway recent (read: within the last few years) release of a properly coded IRC server that has timestamping. There may be a better way to deal with it, but timestamping will basically take the older "copy" of a user list that a server has and will use that instead of a potentially "newer" copy that could be used to hijack ops.

IRC would be a lot more nifty if it standardized on the use of UTF-8 however, although with the annoyance of people who love to talk in high-ascii, I just cringe at the thought of some kiddy having an almost limitless choice of annoying characters to use using a UTF-8 nickname.

And as far as netsplits go.. I'm not really sure how a better written protocol can really defend against DoS attacks and overloading.

Re:They really should fix IRC instead

[Anonymous Coward]

I'm Swedish-American, so SW-ASCII is just the encoding for me!

Re:They really should fix IRC instead

[mrjackson2000]

W has been gone from undernet for years, but X is doing a much better job

Re:They really should fix IRC instead

[lokedhs]

True enough that IRC was made back in the day when character encoding wasn't a real issue. It is today, however, but I guess I've been using IRC long enough that I just don't think of being able to communicate in Japanese or other such non-roman language.

That's what you think. It happens to me very often that I need to type a single word in cyrrilic, or use some mathematical symbols (very useful when talking maths), or just use some of the nice symbols like arrows or why not the different types of accents available.

The fact is that UTF-8 solves a lot of problems the ASCII generation hasn't even thought about. It adds an extra dimension once you start using them on IRC. I recommend you try it.

And as far as netsplits go.. I'm not really sure how a better written protocol can really defend against DoS attacks and overloading.

An automatically-rerouting network perhaps?

Re:They really should fix IRC instead

[Nurgled]

At this point the only realistic way to "fix" charset handling would be to have servers use unicode internally but optionally translate data to and from other charsets for specific clients, so mIRC users can have stuff translated to their system's ANSI charset, and so on.

Of course, characters outside the chosen charset would be unintelligible, but anyone who cares will hopefully just use a unicode-able client.

Re:They really should fix IRC instead

[lokedhs]

Don't you think it would be even easier if just mirc got their act together and implemented UTF-8 support?

Re:They really should fix IRC instead

[drinkypoo]

Implementing good file transfers has basically nothing to do with IRC. This is because your DCC transfers are peer to peer and only the initial request is passed over the IRC network. The only things sent are the host, port, and the filename. While Irc is pretty lame in some major ways (for instance, in this age, we should probably be using unicode) the crappiness of DCC really has nothing to do with that.

DCC is basically xmodem, which is a fairly lousy transfer protocol. From what I understand, some irc clients support some kind of mutant DCC which essentially uses zmodem. (xmodem does not do streaming and neither does DCC, which is why DCC is slower on links with high latency, somewhat regardless of bandwidth.)

Re:They really should fix IRC instead

[XO]

Dude, ChanServ has been around for longer than you have, most likely.

Besides, what's it matter if channel takeovers can't happen on DALnet due to ChannelServ, when the ENTIRE FRICKING NETWORK HAS BEEN EFFECTIVELY SHUTDOWN FOR FOUR YEARS BECAUSE OF SCRIPTKIDDIES DOS ATTACKS.

Re:They really should fix IRC instead

[HeghmoH]

The easiest and best way to fix charset handling would be to make everything use UTF-8. It's easy, completely backwards compatible, requires no changes to the server as long as they don't mess up 8-bit characters, and can represent basically every language on the planet. What's not to like?

Re:They really should fix IRC instead

[Anonymous Coward]

I think part of the problem is because Windows people in general are "thinking in UTF-16".

In fact, there has been discussions on various windows-forums (mirc forums I think) to change the IRC protocol "so it can handle Unicode". Their idea is to have it use UTF-16 instead of some 8-bit encoding. When being told that UTF-8 works today, right now, no changes to the server, if thye just fix their client, they're baffles and can't believe it's true.

Re:They really should fix IRC instead

[achurch]

Nicknames use SW-ASCII, yes that's right, the swedish variant of 7-bit ascii. That's the reason [ and { are equivalent, as is | and \.

This actually isn't true anymore for many IRC servers (Dreamforge/Bahamut, Unreal, and all their derivatives); these treat [\] and {|} as distinct.

Re:They really should fix IRC instead

[Anonymous Coward]

While were at it we should all reimplement nntp too! smtp is going to get redone soon. Once the problem becomes big and/or annoying enough (spam), then it gets fixed.

Re:They really should fix IRC instead

[boneshintai]

Most IRCds can be configured to do this. The issue is not automatic rerouting, it's that while rerouting takes place the network is disrupted. IRC, as specified, is a tree-like structure; there can only ever be one path from node A to node B, regardless of how many nodes are in the network.

A more mesh-like protocol would use more bandwidth overall (some duplicate messages) and more memory (to ensure that the same message recieved twice by one server is handled correctly) but be much, much more resistant to netsplit-based attacks and general network flakiness.

Down with spanning tree!

Re:They really should fix IRC instead

[CTachyon]

I doubt any of them grasp the subtlety of the difference between UTF-16 (a multi-double-byte encoding that can encode all of Unicode) and UCS-2 (a plain double-byte encoding, which can only encode the Basic Multilingual Plane and is what most Windows programmers think of as "Unicode"). Personally, I blame Microsoft for sloppily defining the wide-character NT API that way (although I can't blame them for not using UTF-8, since it wasn't well-known when they released NT 3.1). They should have put some more thought into forward compatibility.

Re:They really should fix IRC instead

[Bert64]

Since when have microsoft been forward thinking? All their products are written with a "just good enough for now" approach, hence why they had to scrap the win9x code base and *supposedly* scrapped the iis codebase

Wonderful XML

[Manip]

Wonderful, more incorrect use of XML... I wonder, why not XML up the XML so you can have an tag which contains even more XML? Sounds insane doesn't it.. but that is what XML does in general... Why oh Why would you write a communications protocol using XML as your base?!

I doubt this will be as popular as they think, with people designing it like this it limits it to platforms with an XML interpreter and also makes it extremely inefficient (compared to normal tags).

Re:Wonderful XML

[Manip]

How is this off-topic, the new protocol uses XML, we are discussing that protocol... it couldn't be MORE on-topic! Do you even know what the topic is?

Re:Wonderful XML

[Anonymous Coward]

Welcome to slashdot, d00d... If someone don't like your comment, you're automatically offtopic or troll. Pretty neat huh? That's why I never bother registering and just post anon all the time. ;-)

Re:Wonderful XML

[Anonymous Coward]

How to fuck up any software project: Add XML

For bonus fuck ups, write it in Java.

Ha!

Re:Wonderful XML

[Naelphin]

To improve, add RSS so you can have 9 different formats with the same name, then have someone leave in a huff and make another ;)

Remember this?

[IgD]

/j #exceed

FileBot: Offering ... Download #777 /ctcp FileBot xdcc list /ctcp FileBot send #1

FileBot: You are in the queue...

Yes, but...

[TheMadPenguin]

will it compile with gcc3? :)

--
3 million strong can't be wrong
www.MadPenguin.org

Re:Yes, but...

[TheMadPenguin]

Flamebait?!?!

I was just joking guys? I mean, come on! DCC2... GCC3...
this is funny stuff! :-)
Only meant to lighten things up, not meant to be flamebait!

Getting mp3s will be that much easier

[RLiegh]

I really, often do wonder why the RIAA (not to mention the MPAA and the BSA) has overlooked IRC for so long. 9/10ths of the channels on any of the reputable networks are dedicated to illegally distributing mp3z, moviez, warez or pr0n (or some combination thereof).

Now, dcc2 will make all that so much easier; which I guess is a boon for the various networks' profits, but at what moral cost?

Re:Getting mp3s will be that much easier

[Anonymous Coward]

Now, dcc2 will make all that so much easier; which I guess is a boon for the various networks' profits, but at what moral cost?

I haven't used IRC in years so this probably sounds like a stupid question, but do you mean to say that IRC networks are run on some sort of subscription or other charging basis now?

Re:Getting mp3s will be that much easier

[huphtur]

Shhhh! Don't give em any ideas!

Re:Getting mp3s will be that much easier

[Anonymous Coward]

... illegally distributing mp3z, moviez, warez or pr0n (or some combination thereof).

Pr0n mp3z? My, that's 0ld5k00l!

Re:Getting mp3s will be that much easier

[strider3700]

I had a buddy get his 98 box owned a year or so ago. He found out when he received a warning from his ISP that "Someone" was considering legal action against him for sharing movies. A quick look on his box showed that there was a bot running there into a couple of hidden movies into an IRC Channel.

Moral of the story is the MPAA at least are going through the big channels and trying to track them down. Due to hacked machines the real criminals will never be found.

Re:Getting mp3s will be that much easier

[\\]

Wow, that post was so uninformed and assuming it actually made me choke.

1. The MPAA, RIAA and whoever else already have people/drones/bots/whatever on many IRC networks. We see them almost every day.

2. 9/10ths of the channels on ANY network, including efnet, quakenet, or whatever are most definitely not warez channels. There are certainly plenty of warez channels out there, but if you think the recent warez group busts weren't at least in part due to irc monitoring, whether it be with clients, carnivore, or both and more, you' are either fooling yourself or just plain stupid.

3. IRC network profits? What are you talking about? Most IRC servers are run by volunteers who want to give something back. I say "most" because I don't know of any IRC servers that are run for a physical profit of some sort. Do you?

Moral costs, feh. Whoever modded you Insightful needs to be blindsided with the cluebat.

Re:Getting mp3s will be that much easier

[epiphani]

DALnet hasnt allowed filesharing in any respect in over a year.

Re:Getting mp3s will be that much easier

[XO]

ChatSpace.

Re:Getting mp3s will be that much easier

[N1KO]

Quakenet, Gamesnet and many others do not allow any kind of illegal file trading. There was also a story here a few days ago about some warez groups getting raided, so IRC isn't being overlooked.

Re:Getting mp3s will be that much easier

[Tyrell Hawthorne]

9/10ths of the channels on any of the reputable networks are dedicated to illegally distributing mp3z, moviez, warez or pr0n

To quote a .sig here on Slashdot, "for the millionth time, stop exaggerating!" It's not that bad. Sure, there may be a lot of trading channels, but there are also a whole lot of channels where people come to chat.

DCC isn't so good but

[Rosco P. Coltrane]

It's easy to dismiss DCC as a flawed protocol. Sure it has its shortcomings, but remember, it was designed before the internet started to become firewalled to death. I remember, until perhaps 1997, DCC was just fine and easy to use, and almost never gave us any trouble. Now you have to prep up your firewall, deal with your NAT box, or get the IRC client to take care of it, ...

Here's a quick overview of how a DCC connection is initiated:

- The initiator's IRC client opens a TCP socket, then (let's call him Bob) sends a DCC (CHAT, SEND) request through normal messaging. Basically it's a plain-text message starting with ^A, similar to a CTCP request. Then it listens to the socket.

- The target IRC client (let's call him Joe) gets it, decodes Bob's socket's IP address and port inside the DCC request, and tries to initiate a TCP connection to Bob.

- Once the connection is established, if it's a DCC CHAT, text is sent as-is across the TCP connection back and forth. If it's a DCC SEND, then the file transfer protocol is used over the connection.

Of course, the confusing thing for people who aren't familiar with DCC is that it's the initiator's client that temporarily becomes the server for the contacted client, and not the other way round, like most people are used to, with http for example. So basically, it's people who initiate DCC connections who must open one or more inbound TCP ports in their firewalls, and configure their IRC clients to limit themselves to using those ports.

Re:DCC isn't so good but

[anethema]

FINE?

It doesnt do ANY crc checking. Just try sending a few files..stopping them..then resuming them. Do a diff and its pretty much sure that one of them will be corrupted.

Its a damn pain in the ass.

Re:DCC isn't so good but

[TekPolitik]

It's easy to dismiss DCC as a flawed protocol. Sure it has its shortcomings, but remember, it was designed before the internet started to become firewalled to death.

It was also designed when Internet pipes were a lot thinner and far more overloaded than they are today. One major university in Sydney (UTS) had a 48kbit pipe for the entire campus. The network was also a lot less reliable - dropped packets were commonplace. When sending a file at full speed over this kind of network, you had a greater risk of timeouts in the network aborting the connection.

There was also the issue that back then the Internet was an entirely academic network, and a lot of the people running it did not approve of the IRC protocol.

The file transfer facility was also only a sideline. The primary purpose of IRC networks back then was <horror>chat</horror>. If you're sitting around chatting anyway you can afford to wait a while for your file transfer to complete.

When you're dealing with overloaded pipes, and trying to fly below the radar, and speed is not considered important, throttling your file transfer well below capacity by requiring and waiting for acknowledgements seems like a pretty good idea.

There was even a facility in IRCII where you could reduce the packet size if your connection was dodgy enough.

Also the way the protocol worked, it was a matter for implementers to decide whether the sender would wait for the acknowledgements at all. A sender could shove the entire file down the pipe if it wanted. The acknowledgement was in the form of the number of bytes the recipient had read. The recipient had no idea what the size of the packet was (and had no reason to care). If the sender transmitted without regard to acknowledgements, it looked no different to a file transfer where the packet size was the size of the file.

The protocol was designed for its day, but that was what, 1991? The net has changed so that perhaps some of the design decisions are no longer appropriate, but that doesn't make the protocol flawed - just out of date. Most of the other protocols have been updated since then too. RFC822 became RFC2822. RFC821 became RFC2821. I think FTP had resume capabilities added too. The IRC protocol itself seems to have been updated every other week. It's about bloody time the IRC client developers got together to update DCC as well, but that doesn't reflect on DCC's design at the time, merely on changing needs.

I also think the complaint that the original protocol was "not extensible" is amusing since their DCC2 protocol is precisely an extension to and compatible with the original DCC protocol.

Okay

[Anonymous Coward]

That's nice and all, but it doesn't really matter unless MIRC supports it, since that's what 95% of the people serving files on IRC run.

Re:Okay

[Anonymous Coward]

Don't worry. The MIRC author will be muscled into supporting it if there's any trouble on his part.

Re:Okay

[Anonymous Coward]

That's good! Then 95% of the pirating will also be gone!

IRC-Junkie.org Article

[szemeredy]

A group of IRC client programmers announced today they are working on a new direct connection protocol named DCC2 of which the draft can be found here.

"The DCC2 community, a group of leading IRC client developers, today announced an initiative to create standards that will make establishing direct connections between IRC clients easier. The group will also work to standardize the protocols used to transfer files and text messages between clients once a connection has been established, allowing for a simpler and more feature-rich user experience" developer Dan Smith wrote in a press release to IRCJunkie. Smith is also the lead developer of the windows IRC client dIRC.

Besides dIRC, the developers of the next IRC clients are involved with the new DCC2 protocol; Visual IRC, Ircle, KVirc, Bersirc, Chatzilla and OrnateIrc. We asked Smith why key clients like mIRC and BitchX are yet not present in this list.
"I have not talked with the authors of the clients you listed personally. Our group is following a standards process and would appreciate input from anyone who expresses interest! I am personally impressed with the large number of major client authors (Windows, Unix, Mac) who have already expressed interest and are helping to write our drafts."

The current DCC protocol is known to be lacking in clarity where it comes down to finding out why something fails to work.
"The main goal of our negotiation draft is to identify connections that are more likely to be established. The second goal is to allow the clients to know exactly why a connection failed, instead of a silent failure" Smith explained their goal to improve in this area as well.
For users behind a NAT who are not really known with networking issues this is a well known source of problems. Smith explains how the DCC2 protocol would handle in case of problems in this situation: "... direct connections between two ipv4 users behind NAT/firewalls will still fail if they do not have ports forwarded for connections. However both clients will know why the connection failed and can take appropriate action, such as opening ports using UPNP or notifying the user that their network setup prevents connections. With the addition of IPv6 to direct irc connections, users can map ipv6 addresses inside of their NAT, and use ipv6 in the connection negotiation process as well. I highly recommend sixxs.net for anyone interested in ipv6 technology."

"File name and size information never needs to pass over IRC", the website of the DCC2 protocol reads. Some networks have taken action against channels where music files are being shared over DCC. We asked Smith if this will prevent the network to see what is being transmitted between the clients.
"The main goal of the file transfer draft is to allow multiple files/directories to be transferred concurrently, along with additional metadata such as file checksums, descriptions, etc. The fact that this file metadata is listed out of band, and possibly encrypted, keeps file transfers private between two irc clients. The direct connection negotiation still takes place over irc."

The DCC2 protocol will be compatible with the currently used DCC protocol. "While DCC2 is a completely new way to publicize connection data, we have added a compatibility layer to work with historic dcc. In short, we found that many clients ignore unused tokens after historic dcc messages. The DCC2 tokens can be appended to the historic dcc commands, and if both clients support dcc2 then a connection negotiation takes place", Smith explains.

It is expected that during the coming summer the first clients will come with DCC2 at a experimental stage.

No mIRC support?

[Kjella]

Like it or not, pretty damn many use mIRC. Under community members, there's noone from mIRC there. I would hope that is temporary, because DCC really could use replacement. I'm now firewalled off with no incoming ports, two years ago I was NAT'd with no incoming ports.

It leads to extremely stupid things like being able to recieve but not send, even though it is obviously possible since once the connection is established, the data should be able to flow either way. The other big alternative is FTP, which also is horrible at dealing with passive mode.

The hilarious part is that the reason corporations, universities etc. seem to give for it is p2p - when they get around this trivially. On a network, someone will be active and there's no problem. You're only being a major pain in the ass for me when I want to do something with a friend that also has no open incoming ports.

Kjella

Re:No mIRC support?

[tepples]

Like it or not, pretty damn many use mIRC. Under community members, there's noone from mIRC there.

"Afraid of being 0wn3d through your web browser? Switch to Firefox." Likewise, "Firewalled off from DCC? Switch to $different_irc_UA."

I would hope that is temporary, because DCC really could use replacement. I'm now firewalled off with no incoming ports, two years ago I was NAT'd with no incoming ports.

Is this enforced by an ISP with a monopoly on your residence's last mile? Or can you fix this at your firewall?

Re:No mIRC support?

[Mr2001]

Frankly, the author of mIRC doesn't seem very interested in standards.

Instead of using the same color attribute codes as other clients at the time, he came up with his own design for color codes - arguably a poorer design, since it's harder to parse, and harder to read in a client that doesn't process color codes. (Thanks to mIRC's popularity, the other systems died out.)

His design for DCC Resume contradicts the uses of PRIVMSG and NOTICE set forth in the RFC: PRIVMSG is never supposed to be sent as an automated client response.

I'm a little concerned that mIRC won't ever embrace DCC2, and will perhaps come up with a different, inferior, incompatible solution to the problems that DCC2 is designed to solve.

Re:No mIRC support?

[Bert64]

Well, ANSI color has worked for years on any terminal which supports it, even without an irc client you can raw telnet to irc and ANSI works.. It took mirc _YEARS_ to support ANSI, but eventually they did.. while having their own non standard color scheme aswell.
I remember back in the days, when mirc color codes started appearing, you saw garbage on the screen and it made it hard to read the text... We used to automatically ban anyone who used those codes.

You forget the benefits of an open protocol

[CdBee]

IRC may be ugly, but like Windows, it's here because everybody uses it.

Its massively cross-platform-available and easy to integrate into messaging apps.. That's worth a lot more than the costs incurred by its kludged technology

Re:You forget the benefits of an open protocol

[sffubs]

Don't forget that it's relatively easy to write your own IRC client/bot/library, whereas protocols like Jabber (whilst pretty and extensible) are much harder to implement.

That has got to be worth something.

Re:You forget the benefits of an open protocol

[RAMMS EIN]

But then, XMPP is also open.

And not _everybody_ uses IRC, most people I know don't know it, and use MSN (which, IIRC, used to have an open protocol) for chatting.

Try again...

[Kjella]

yes, he is. the openssh source is available under the gpl. how difficult can it be to get it, and integrate it into an irc client for file sharing?

...the openssh source is OSS, but it is not GPL. What licence it's really under, is left as an exercise to the reader.

Kjella

Re:Try again...

[Simon (S2)]

...the openssh source is OSS, but it is not GPL. What licence it's really under, is left as an exercise to the reader.

lol :)
you are right. anyway, i was talking about the protocol, not the implementation of it.

What is the point?

[DiZASTiX]

From the memo:
"DCC2 allows IRC clients to negotiate connection settings using a handshake mechanism for agreement to protocol usage. Protocols available on the offering client are published to the receiving client. The receiving client may then reply to the offering client, listing the subset of the available protocols that must be used. The receiving client also has the option to open the connection if the offering client cannot accept incoming connections."

It looks like the big thing they are trying to do is simply increase compatability between one user connecting to the other using dcc2. I do not beleive that dcc2 will have a great difference of quality over the regular dcc but it will have more compatibility.

They aim to "incorporate new technologies" but I dont see where they are going with this...

Re:What is the point?

[AllynM]

mIRC is scriptable. once the standard is set, it would take only a short time to implement into mIRC with an easily installed script.

Re:What is the point?

[iamriley]

It looks like the big thing they are trying to do is simply increase compatability between one user connecting to the other using dcc2.

The point is to let the protocol decide the best way to connect given several options so the user doesn't have to manually try each of the many variants of the DCC command that have been added to the different clients to overcome the problems with DCC (e.g. dealing with NAT).

I do not beleive that dcc2 will have a great difference of quality over the regular dcc but it will have more compatibility.

DCC2 will perform better than DCC in most circumstances. DCC requires ACKs every so often, halting transfer until the ACK is sent from the receiver. Since TCP/IP already guarantees delivery, this part of the protocol is completely redundant, and it can significantly slow down delivery.

They aim to "incorporate new technologies" but I dont see where they are going with this...

DCC2 is both simple and extensible, unlike DCC which, though simple, is not at all extensible. Some functionality that DCC2 could help standardize accross clients are whiteboard sharing, voice/video chat, encryption, IPv6 connections, etc.

--Riley, dIRC developer, Algenta Technical Staff member.

Why is this modded as funny?

[mark-t]

I had the same question actually. There are only two clients I ever use - one is chatzilla, and the other is ircII. I only ever use the former when I am in X, which is not all the time... I use the latter when I am in console mode, or ssh'd into my home box remotely, which is a lot of the time.

So as the parent poster said.... where's ircII?

As an IRC Admin...

[Dunarie]

As an IRC Admin, all I have to say is, just fucking wonderful, all IRC needs is a better file transfer method, to bring in more scum, and drag IRC down even more. IRC Stands for Internet Relay CHAT, and while it's nice to have a way to transfer files (like on most IMs), it's gotten out of hand, and it's doing nothing but hurting us chatters on IRC. I like Kazaa, WinMX, and the like as much as anyone else here, but I also love being able to chat on IRC.

When I tell people I use IRC, more and more people say something along the lines of "yeah, much better than kazaa" or "I could never figure it out, so I still use kazaa myself", it's quite sad. ISPs hate IRC, and it's hard to find any that will let you host IRC servers, if not because of it's rep for illegal MP3s, warez, ect, it's cause of the DDoS attacks IRC attracts because of the extra scum file transferring brings.

And now they want to improve DCC, JUST FUCING WONDERFUL!

Re:As an IRC Admin...

[liquidsin]

How is dcc bringing down irc as a whole? The only large scale filesharing I ever see on irc is on small networks, usually set up explicitly for filesharing. Even when it's on a major network (efnet, dalnet, undernet) if you're an admin and it pisses you off that much, k-line everyone in a filesharing channel and you'll just be helping your network (more room for chatters to connect). As for the actual file transfers, they don't have any effect on your network. They're sent straight from client to client without the network routing anything more than the original negotiation of finding each other.

Re:As an IRC Admin...

[Dunarie]

I don't mind keeping DCC, I use it myself sometimes, but I see no need to improove it, it'll just draw in more people on interested in file sharing only. It won't matter what I do on my server/network, if the majority of other servers/networks give IRC such a bad rep, that it'll be almost impossible to run a legit IRC server. I also know that the files don't transfer dirrectly through my server, it works in a very simaler manner as Kazaa, and the other p2p networks, but that doesn't stop them from getting targeted by lawyers, and the like.

Re:As an IRC Admin...

[grazzy]

do that and have your server ddosed back to the stoneage.

Re:As an IRC Admin...

[Anonymous Coward]

That's sad. It's not like you are under obligation to provide an IRC server. Aren't those mob tactics?

Re:As an IRC Admin...

[Anonymous Coward]

Much agreed! The last thing the earth needs is yet another standard to send bits from one point to another. In practice it would really mean DCC and DCC2 would *both* have to be in all IRC client and server software to avoid incompatibility, which means yet more bloat client-side and it means the eventual need to upgrade every IRC server/client on earth to support both. Extra work for hundreds of millions of machines because a few people think the current standard isn't "good enough".

It's like saying the current English alphabet isn't good enough because the letters XCKQ are so close. Maybe we should make an alphabet 2.0 to get rid of the cruft and rewrite every dictionary to support both spellings? It's a logistical nightmare and a waste of everyone's time.

If you want to use an alphabet set to make new words, that's fine, but changing the underlying "protocol" is very uncool. What will happen tomorrow when someone says DCC2 isn't good enough? DCC3? 4? When does it end? Hasn't anyone noticed that when you have a plethora of "standards" none is really "standard" anymore? http, smtp, ftp, telnet, ssh, sftp, irc, dcc, the list goes on and on. All of these things have flaws, but the last thing we need is to overhaul all of them!

Re:As an IRC Admin...

[ikkonoishi]

As a Post office worker, all I have to say is, just fucking wonderful, all the post office needs is a better package delivery system, to bring in more scum, and drag the post office down even more. The post office is for writing letters, and while it's nice to have a way to send packages (like on most letter carriers), it's gotten out of hand, and it's doing nothing but hurting us letter writers.

Re:As an IRC Admin...

[liquidsin]

And if you do nothing about it, your server is being used to facilitate copyright infringement, and probably the ddosing of other targets. I guess it depends on when the U.S. gov't decides to start going after irc servers for the actions of their users.

Re:As an IRC Admin...

[Anonymous Coward]

As an oper, I can agree with you

Re:As an IRC Admin...

[Depris]

IRC may stand for Internet Relay CHAT but it's _evolved_ into much more than that. I think you are missing the point here. The bottom line is that not everyone uses IRC to just 'chat' and any improvement made to any service with usuage as high as high as irc is a good thing.

Re:As an IRC Admin...

[Anonymous Coward]

Maybe, but it's a grand tradition. As far as I remember, IRC op infighting was the origin of the DOS attack (originally in the form of pingfloods, early '90s).

Re:As an IRC Admin...

[semafour]

http, smtp, ftp, telnet, ssh, sftp, irc, dcc, the list goes on and on

DCC is unique in this list in that it is the only protocol you listed that does NOT have a standard document describing it. Hence, DCC2.

Re:As an IRC Admin...

[xant]

back to the stoneage.

You mean, the server will be forced to run IRC again?

Re:As an IRC Admin...

[jp10558]

I don't know, IRC never seemed to be that good for chat, especially if you are a newbie(which everyone is at some time). They have whole textbook lenght webpages they direct you to so you can chat. And the communities that I as a newbie can find suck. Certainly there is little chatting in most, or for instance in politics they just shout at each other whatever the party line of the day is. Then they ban you based on your nick one day, before you can even type a sentance.

If I want to chat in a community, I go to filetopia. If I want to shout at other people, there is yahoo chat. Both make it much clearer what the chat rooms are for, and how to find one on a topic you are interested in. Both work much better IMHO for chat than IRC.

Re:As an IRC Admin...

[trons]

Of course they do, that's because they were designed a few years ago, designed for a target audience consisting of pure n00bz :) IRC is rather old, and most clients that are developed for it don't bother with designing a n00b-interface for these n00bz. Eventually they end up using some IM program, and that's when the real smalltalk starts. You have the most intriguing conversations in a channel...

Just replace the servers

[iamacat]

They could use a more efficient protocol to talk to each other and route traffic and clients don't have to know any difference. Except for, well, DCC.

Filenames

[Morth]

Are they joking about the valid filenames? Essentially it's just the characters accessible with or without shift on an US keyboard. This excludes any character not commonly used in English, which seems ridiculous to say the least.

Re:Filenames

[Anonymous Coward]

This was an oversight (yeah, a big one - oops). We're currently looking into sensible ways to allow the full range of Unicode filenames to be used.

Time has moved on

[nurb432]

Yes, in the old days IRC *was* about chat. but as time went on, it morphed into more of a file-trading network.

'chat' has moved more to the traditional IM networks, for various reasons.

Hey, things happen, things change. Remeber the old BBS's? Nothing stands still.

Re:Time has moved on

[Garak]

Depends on what town you grew up in....

My home town of 8000 people has to be the IRC capital of the world with 100's of people chating on IRC at anyone time. It started way back in 96 and the channel is still going strong today. Best of all its pretty damn stable, its been years since there has been a conflict. Back in the day I must admit to taking the town channel on several occations.

IRC is still being used by chat by isolated groups.

Re:Time has moved on

[N1KO]

IM is worse than IRC, at least with IRC you can install any client and it'll work on any network. I stopped using IM because I couldn't find a client that let me connect to everyone I knew and supported all the features of the official clients.

Also, all the popular protocols are propietary and clients magically stop working after a couple of months because companies drop backwards compatibility on purpose.

Re:Time has moved on

[juhaz]

Yes, in the old days IRC *was* about chat. but as time went on, it morphed into more of a file-trading network.

Some networks did, some didn't.

IRCnet is still a chat network, and looks like it's not going anywhere soon or morph to warez-kiddie toy. Which is good.

Re:Time has moved on

[Anonymous Coward]

Hmm, it's not a "one or the other" trade-off sort of situation, imo. Both chat and filesharing channels seem to coexist and thrive simultaneously on many networks.

This new DCC2 protocol probably won't change things so much as some of the posts have suggested. Also, IRC server admins should be *happy* about DCC2, I think, because it puts liability for any file transfers more directly on the users, where it ought to be.

Re:Time has moved on

[trons]

IRCnet still a chat network? It must be the biggest warzone of kiddies struggling to split a few servers and gain operator status on some channel (thanks to that wonderful idea of nick/channel delay). I mean, if there is one network that's hardly still usable for the purpose of having a chat, it MUST be IRCnet! :P

Reference

[Morth]

Should probably have given a reference. Well here it is (the dcc2-quotedname part).

Finally!

[Necrotica]

It's about time some people did something about this. I really hate things that stop working just because you decide to secure your systems. Trying to do DCC sends over NAT is a nightmare.

But it seemed like there were two implementations of DCC. The "right" way, which most Unix-based IRC clients did, and the "backwards" way, which Mirc did. I never seemed to have any problems with DCC sends when using a Unix-based IRC client but it always seemed like I would have to stand on my head and chant voodoo chants when trying to use Mirc. Unfortunately, Mirc is by far the best IRC client out there. Yeah, Irssi and BitchX are good too, but there aren't any GUI based IRC clients for Unix that can hold a stick to Mirc. Try being an op in a busy channel and have a requirement for robust userlist functions, channel protections, file sharing, etc. You can't have them all in any Unix-based IRC client but you can with Mirc.

I always ended up having to set up a socks5 proxy server in order to get DCC sends to work correctly. I truly hope they implement the protocol correctly this time...

Re:Finally!

[Anonymous Coward]

I always liked x-chat a littler better than mirc, but not by much. I just like how the interface is laid out better. And I'm partial to perl scripts. That said, I can totally see liking mirc better. It was all I used for several years.

Re:Finally!

[Smoovious]

> But it seemed like there were two implementations of DCC.
> The "right" way, which most Unix-based IRC clients did,
> and the "backwards" way, which Mirc did. I never seemed
> to have any problems with DCC sends when using a
> Unix-based IRC client but it always seemed like I would
> have to stand on my head and chant voodoo chants when
> trying to use Mirc.

Yeah, I've noticed the same problems... IMHO, the mIRC people screwed up big time when they decided to replace their old DCC system with a new one. Whenever I try to receive a file from a *nix or other 'standard' client now, more times than not, the remote end reads a successful send while my end (the mIRC end) reads an incomplete file and quits because they aren't handshaking properly. Switch to my other computer with an older mIRC with the older DCC system in it and they work flawlessly.

I simply don't understand why they felt the need to fix something that wasn't broken to begin with and ended up with something broken. I never had problems with failed DCC's not timing out under the old system. Under the new one? A failed resume will sit there on my screen for hours and hours and maybe timing out. If someone sends me a DCC using the IP of 127.0.0.1, or another reserved local IP that my LAN uses internally? THEY NEVER EVER TIME OUT! On top of that, the old DCC system wasn't succeptible to that DCC exploit that the new DCC system was. Don't get me started on the larger DCC windows either. The old ones I was able to keep so small they never blocked anything on the screen, the new ones are huge and UGLY! /me sighs...

Why is it whenever any author updates their programs to make it better, I end up losing the things about it I liked most... like being able to set priority levels for programs in Win311 right in the PIF file for example.

This ends Smoovious' Rant-of-the-Day...

-- Smoovious

File name and size information ...

[dougmc]

The current dcc protocol isn't *that* bad -- it's very similar to ftp's protocol. It's biggest problem is that it can't work in both directions (send and receive) through a NAT or a firewall that won't let you open a listening port and have somebody else connect to it. So if you're behind a NAT, you can receive a file but can't send one.

How dcc works: if you're sending a file, you open a listening port, then send your IP and port to the remote host via a CTCP message. The remote host connects to that IP and port, and accepts the file.

To fix the send/receive via a NAT problem, one could merely make an extension (or just a seperate sending command) where the sending machine requests that the receiving client open a host and port and then the sender connects to it. It wouldn't be too difficult to implement, but it might require that a ctcp message be sent back from the receving client. We've been talking about this for over a decade. The hardest part would be to talk the other client authors to implemenet it.

One other, less commnon problem -- that IP that is sent comes from your hostname in many cases, so on a multi-homed box it's often wrong. Here is a pseudo-fix that's just under 10 years old for ircII.

File name and size information never needs to pass over IRC", the website of the DCC2 protocol reads. Some networks have taken action against channels where music files are being shared over DCC.

But make no mistake here -- the *only* reason one would need to avoid sending file name and size information over irc would be to avoid censorship or logging done by the irc servers. It's just metadata, and a few bytes of it -- the servers can handle it without any problems.

In fact, it would be nice if the new dcc protocol (if it's ever completed and widely implemented, which I doubt, based on my experience with how irc stuff is done) could support sending small files directly through the servers with no additional TCP connections. It would be *very* slow (thanks to flood control -- perhaps 100 bytes/second tops) and would put a larger load on the servers, but it would allow two clients behind two different NATs to send files to each other when nothing else would. Wouldn't be practical for .mp3 files, but it would for .ircrc files. Of course, the server admins would hate the mere idea, and if people used it a lot they'd add code to the servers to find and block it, K-line the users, etc.

Your soap box is a bit rickety

[toupsie]

My, my aren't we a little defensive. Did I make a moral judgment about piracy? All I said that the majority of the transfers done via DCC are for pirated files. So far, all I have heard is, "Yea, so, other people pirate through [insert protocol here]". I never said that improving the protocol would make one "responsible" for piracy. All I said that pirates would "rejoice" from the improvement.

Why do people have an issue with honesty? DCC is used mainly for piracy -- oh yea, that and "log files".

Re:Your soap box is a bit rickety

[Kymermosst]

All I said that the majority of the transfers done via DCC are for pirated files.

You're probably right, and normally I don't feed trolls like you, (I've been reading up un the thread), but where's your proof? If you don't have direct proof, where is your source?

Perhaps you just took a blind guess, and therefore are full of shit because you didn't do the research before you made your claim.

Re:Your soap box is a bit rickety

[DJayC]

Just to clear something up, I said "logo", not "log". You keep using the "log file" as a joke, but it's not what I said. I was referring to the many times I need to send logos to people I talk to on IRC for various reasons. It's faster to just fire it over with DCC than to post it somewhere, or email it. The same with PHP scripts, or any kind of file really..

You may be right that most of the BANDWIDTH is taken up by some type of pirated file, but I doubt the same holds true as far as the overall NUMBERS of transfers. Not everyone on IRC knows about pirated software channels...

Re:Your soap box is a bit rickety

[aminorex]

I have never DCC'd a file in violation of a copyright owner's intent.

I use xmule for that.

I use DCC to collaborate with cow-orkers.

Re:Your soap box is a bit rickety

[metamatic]

All I said that the majority of the transfers done via DCC are for pirated files.

And similarly, the majority of large JPEG images transferred via HTTP are porn. So what is your point?

Don't forget DCC chat

[br00tus]

When you're chatting privately with someone normally in IRC (/msg), your conversation is going over the IRC servers. Thus, any IRC server admin can theoretically read all of these "private" messages. With DCC chat, a direct connection is made between IRC clients so that the conversation is between these two IP's, separated from the IRC servers. Of course, the conversation could be monitored from other places then of course and then you can start talking about encryption and so forth but that's another story.

But yes, the DCC protocol is used for more than file sharing. I've been using IRC since at least early 1992, and I have used DCC send and receive from time to time, very rarely for a sound file or video game. Usually it is for a text file, or a photograph, or a C program, or something like that. If you want to stop technological innovation because you fear it might hurt the profit of some corporation, then you might want to consider how the automobile, the telephone, and other instruments can be used for similar purposes.

4 days too late

[Anonymous Coward]

We could have used this last Wednesday...

missy

Oh, please!

[toupsie]

Well if you are so sure you are right that a majority of files transfered via DCC are legit, lets see your proof. We are not stupid here, we know what IRC and DCC is mainly used for -- just read the other posts on this topic. Please don't insult our intelligence here on Slashdot.

Next thing you are going to tell me is the Earth is flat. You wouldn't be calling me a "troll" if you couldn't back up your case.

Re:Oh, please!

[Anonymous Coward]

"We are not stupid here, we know what IRC and DCC is mainly used for -- just read the other posts on this topic. Please don't insult our intelligence here on Slashdot."

If it is efficient pirates will use it as will porn peddlers. Who the heck cares what DCC or heck even IRC are mainly used for? I use IRC for tech support from like minded users. I have also benefitted from people sending me a config file or document. At the end of the day the I am better for the tech being there even if people like you want to raise your noses in the air and haughtily dismiss IRC as a bastian of pirates to the exclusion of all else.

My real problem with your sanctamoneous argument is it may lead others in authority to stifle a source I benefit from. Your arguments are like those of the antigun nuts. Guns are used in crimes lets ban guns. Meanwhile I live in a society that has tight legal controls on guns and yet people are still being shot in the streets. So what then is the solution? Is it to search everyone or maybe ration out movement? If it can be used to pirate software it will be used to do so. So go after the pirates and leave the rest of us alone.

M. Kenery

Re:Oh, please!

[Little Brother]

According to the basic rules of debate I learned in my Elementary Logic and Critical Thinking class, the person who makes the origional assertion has the burden of proof. Thus, it is the person who makes the positive claim, in this case that the majority of DCC files are illicit, that must prove his point, the person who has not made such a claim need only refute the proof offered, if possible.

That as it may, I wouldn't be surprised at all if the assertion that most DCC bandwidth is used in illegal or quasi-legal transfers.

Re:Oh, please!

[Anonymous Coward]

Please don't insult our intelligence here on Slashdot.

Intelligence? On SLASHDOT? Please don't insult our intelligence by assuming there's any kind of intelligence on slashdot.

Oh, and please don't insult the intelligence of everyone by thinking in black and white.

XMPP Worse Than IRC, IMO

[RAMMS EIN]

Honestly, I don't think XMPP is going to help a lot. I am not an XMPP guru, but from what I've seen it looks less efficient than IRC.

The main problem with IRC seems to be the enormous load that is put on servers, mainly caused by using the servers to relay client to client messages.

There is a solution to this problem: DCC. Using DCC, clients connect directly to one another, and thus spare the servers. With a little extension, DCC can also be used to implement chat rooms client-side, so that server relaying of messages is only needed for initially connecting the clients to one another.

Of course, we could design a protocol specifically for the purpose of connecting clients to one another, and I think that would be a good idea. Jabber and IRC both do a lot more than this, which makes them, in a sense, bloated.

Re:XMPP Worse Than IRC, IMO

[MulluskO]

Using the server for transfer of messages isn't so much of a problem, really. More of a feature if you ask me. It allows some degree on anonymity, and allows you to keep your IP address to yourself if the server has hostmasking enabled.

Also, I think it would be hell to try to get 2000+ people all chatting client-to-client. With firewalls and NATs in the way, it's much easier on the user that way. Furthermore, if you see text in the channel, you can be sure that everyone sees it. It's a trifle, but left to the peers people would game the system even more than they do now.

Re:XMPP Worse Than IRC, IMO

[metamatic]

OK, let me outline a few of the problems with IRC:

1. It's a double-tree structure, which means all IRC networks have a single point of failure.

2. There's no smart routing, so the servers have to carry traffic even for channels that nobody connected to them is using.

3. Nicknames are global, which means there's contention for popular ones, even if the ten people who want to use mine would never otherwise run across me.

4. It's centralized on a few servers, so it's easy to DoS out of existence. (I know all about this; I was a DALnet user.)

5. There's insufficient standardization of everyday stuff people expect to have like colors, fonts, file transfer, away messages, and the like--so I see garbage instead of messages because they have colors in, people don't use /away because it doesn't work in all clients, actions don't always work, there are three or four different ways of getting idle time info, and so on.

Re:XMPP Worse Than IRC, IMO

[RAMMS EIN]

Many thanks for pointing that out, that's what I've been waiting for.

However, I'm still wondering how else you would do it. I mean, if you're not using client to client connections, it's going to have to go through the servers. Thus, servers need to know where they are (point 1).

Sending channel messages to all servers (point 2) _might_ be cheaper than keeping track of which servers actually need the data. If not, it wouldn't hurt to not send data to servers that would only discard it, so that is more an implementation than a specification issue.

Global nicknames (point 3) are problematic during login only. It's slightly annoying for users that they can't always get their prefered nickname, but it's about the best way to ensure no two people with the same nick will ever meet.

Few servers (point 4): I guess the alternative woulh be a sort of P2P structure. But then, how can you trust the nodes? If you want the nodes to take care of only the messages they themselves send, use DCC and you're already done.

Insufficient standardization (point 5): the beauty of IRC is that the protocol does not have to be adapted to be extended. CTCP and DCC are standardized, or at least there are specifications. For the rest, if clients don't interoperate, that's their problem, not IRC's.

Re:XMPP Worse Than IRC, IMO

[metamatic]

1. Each server knows which channels the clients connected to it are on. It's pretty easy to turn that information into one list, which would then be used to filter server-to-server connections. Effectively, the server would work like a client of other servers.

2. It *might* be, in the current tree topology. It clearly isn't for the "leaf" servers, even in the current topology.

3. Users not being able to get a preferred nickname means users having a different nickname every time, which means users not recognizing each other. Plus, it doesn't matter if two people with the same nickname meet; all that matters is when two people with the same nickname both join the same channel, and that contention can be handled when the join is performed.

4. Have a mesh of servers, and those servers provide the connectivity for the clients. Servers can operate rather like Gnutella nodes, except that since there's a central list of servers which make up the network, it's easier to do authentication and to find another working node to connect to.

5. Clients not being able to interoperate due to lack of standardization may not be a problem for IRC-the-protocol, but it's a big problem for IRC-the-chat-system.

Re:XMPP Worse Than IRC, IMO

[RAMMS EIN]

A yew more comments before I leave home:

point 3: That's why, on networks I've been on, you can register your nickname, which keeps others from using it.

point 5: This just means the client writers have to get their act together and standardize the extensions they use.

Re:XMPP Worse Than IRC, IMO

[metamatic]

I know about nickname registration--did you miss the bit where I mentioned I was a DALnet user?

Nickname registration is the wrong solution, because it isn't scalable. Look at AIM, where you have people resorting to stupid nicknames because none of the reasonable ones are available.

Why can't people read?

[toupsie]

My real problem with your sanctamoneous argument is it may lead others in authority to stifle a source I benefit from. Your arguments are like those of the antigun nuts. Guns are used in crimes lets ban guns.

Please me show a posting where I advocate the elimination of IRC and DCC. You are taking a statement, "DCC is mainly used to transfer pirated files" and assuming I am stating "DCC should be outlawed because it is mainly used to transfer pirated files". I am just stately a fact of life not making a moral judgment.

It cuts both ways.

[Ayanami Rei]

Anime Music Videos, demoscene compo-paks, and other nicities are often found on P2P networks too... it's all those people trading their WaReZ and illegal MP3Z and DVD rips on it that are giving it a bad name.

Yaaddaa yadda yyadda. Everything can be used for ill or good.

What? No encryption?

[Anonymous Coward]

A least it can do, is allow encryption... I don't even see that in the spec....

Wouldn't trust them too much

[Anonymous Coward]

they copied microsoft.com site design.

Re:What? No encryption?

[iamriley]

A least it can do, is allow encryption... I don't even see that in the spec....

Probably because you didn't look hard enough.

--Riley, dIRC developer, Algenta Technical Staff member

you have been kicked from #slashdot (potty mouth)

[Anonymous Coward]

you have been kicked from #slashdot (potty mouth)

Not a flame...

[XO]

IRC is not a file transfer network. IRC is a chat network.

So many people are using IRC for so many things that it's not built for, that it has become nothing but a gigantamongous tangled mess full of SHIT.

The only way to save it is to destroy it. If not, eventually, it will all be taken down forever by script kiddies, such as what happened with DALnet (last i knew, they'd had a 4 year long DOS attack on them...)

Start over. The WHOLE NETWORK. Not the fucking file transfer protocol that's hacked over on top of it. Jesus.

Re:Not a flame...

[Anonymous Coward]

if u dont like IRC, u dont have to use it =)

DCC Torrent style

[CaptCanuk]

4 years ago, I was thinking of a way to improve DCC transfers across IRC by splitting up files and creating a bit torrent (before BT was around of course) style client that would send the fragment files to various users via dcc and stitch them up later. Of course it would require using specific scripts or a client/bot. I did create a simple IRC client once and implemented DCC transfers. It was easy for me to identify NAT connections on both sides that prevented DCC transfers from working properly - good to know the protocol is finally catching up =)

Online gaming comunity uses IRC a lot

[dusanv]

In fact UT has an IRC client built in. There are big networks (ETG, progamer) with only gaming related content (no warez at all).

Profit?!?

[RAMMS EIN]

Profit? What profit? It's going to attract more people to IRC all right, but that's going to _cost_ the networks rather than profit them. They pay for the hardware and the bandwidth, which users use for free. Not that bandwidth costs of initiating DCC sessions are that huge, but it's still some.

Yeah, right.

[juhaz]

It'll just shift the DCC attacts to target IRC networks (as if they aren't under fire already, witness the destruction of DALnet), and cause grief to those who still use IRC for what it's meant for.

Pirate away if you wan't to, but don't get our IRC servers killed because you didn't have enough bandwidth to keep your own warez network running.

Re:Yeah, right.

[Shakrai]

It'll just shift the DCC attacts to target IRC networks (as if they aren't under fire already, witness the destruction of DALnet), and cause grief to those who still use IRC for what it's meant for.

I don't shead many tears over DALnet because I never cared for their big-brotherish attitude and I felt like their "services" (which every other baby-IRC network that came after co-adopted) went overboard. That said I never advocated or wished for seeing a network brought down by DDoS attacks.

I was always an Undernet fan before it was torpedoed into near-oblivion by DDoS (why do people have to attack a donated service?) then taken over by new coders and admins that locked it down into a paternalistic fascist state. Can't use /map? Can't see what server your buddy is on? WTF?

Then again it is a free service and your only recourse if you don't like it is to stop using it -- which is pretty much what I did. Still lurk on my old channels on Undernet but most everybody is gone these days. Who has the time anymore?

Wonder if EFNet is still "pure" and worth using. But then again who has time nowadays to join a new network and meet new people? Is IRC even worth anything anymore? Undernet has been taken over by cluebies -- the signal to noise ratio is unbearable these days.

Oh well. </OffTopic Nostalgic Rant>

Re:Yeah, right.

[juhaz]

I don't shead many tears over DALnet because I never cared for their big-brotherish attitude and I felt like their "services" (which every other baby-IRC network that came after co-adopted) went overboard.

I don't think I've ever used DALnet, no idea about attitude or number of services, I just brought it up because it's probably the biggest and most well known case of whole irc network brought down because of DDoS wave.

Can't use /map? Can't see what server your buddy is on? WTF? /map? Never been on any network where that exists, or ever had, and who cares about that or on what server someone is? Totally useless data, I'd say.

Never used EFNet either, what comes to time... well, that obviously depends on person.

I've always been mostly IRCnet person and it seems to stay relatively untouched so far, of course there's no point in trying to claim that influx of idiots doesn't reach there at all, it does, no corner of internet is safe from them.

Re:Yeah, right.

[Shakrai]

Never been on any network where that exists, or ever had, and who cares about that or on what server someone is? Totally useless data, I'd say.

Hardly. If you have a 300 second ping between you and your buddy you can jump servers and go to the one he is on. /maps and/or /links were interesting informational commands -- granted you don't really need them but one of the coolest things about IRC was that it wasn't (until recently) dumbed down for Joe User. Undernet these days might as well be a slightly harder to use AOL Instant Messenger.

I'd forgotten about IRCnet because I never used it. I guess it is one of the big four though. Perhaps I'll check it out -- though more likely then not I've given up on IRC -- which is ashame. I have some cool memories on IRC.

I sat on IRC as the first Persian Gulf war started -- we got updates faster then CNN did. We discussed in real time the OJ Simpson verdict, the events of 9/11, the Seattle earthquake, the Yugoslavia bombing and election night in 2000 (that was interesting!). Back in those days you could join most channels and find a rational person to talk to. Nowdays it seems to be dominated by script kiddie AOL Windows users.

Oh well. All good things...

Re:Yeah, right.

[juhaz]

Hardly. If you have a 300 second ping between you and your buddy you can jump servers and go to the one he is on.

Guess it might so in that case, though 300 second lag is pretty damn rare. Whois does show the server on ircnet but it's not much use because more often than not you can't jump there anyway, because everyone seems to I-line only their "own" folks.

I'd forgotten about IRCnet because I never used it. I guess it is one of the big four though.

Yup, it's about equal in size to undernet and efnet, QuakeNet being easily biggest of 'em all now. Might be partially a continent barrier, IRCnet is big in Europe and EF&DALnets in US.

Probably worth a try if you find the time, of course you might end up hating that one too, but nothing much to lose.

Back in those days you could join most channels and find a rational person to talk to. Nowdays it seems to be dominated by script kiddie AOL Windows users.

Well, depends on channel(s) too... there are some bastions of rational people left. And luckily QuakeNet seems to be drawing away the worst of the worst.

That's happening everywhere, though, nothing limited to IRC, Usenet is full of whining morons now, web boards and the like have been always their domain.

...and the second part

[ewe2]

Taco, you might want to update the story with the link to the second draft, Draft File Transfer Specification. It isn't on the IETF site yet, however.

Ok, but

[RAMMS EIN]

Ok, but you still need some identifier. I think it's preferable to have a human readable and rememberable identifier (to avoid situations like ICQ UINs). Such an identifier could also be used as a nickname.

One good system, as I see it, is to do like Jabber: register @, then set your nickname. The nickname can be used as long as no collissions occur. If a collission does occur, the account name can be used to resolve it.

All of this can be done without breaking the current IRC protocol without much trouble, and thus I can't count global nicknames against IRC.

Re:Ok, but

[metamatic]

Nicknames serve two purposes on IRC: they are both a means of identifying the person, and a shorthand identifier to perform actions on that person (like sending messages).

The former purpose requires long, descriptive identifiers. The latter requires short, concise identifiers. So there is a fundamental conflict.

What I am proposing is that there should be two identifiers. A longer one, global, which identifies the individual the way user@host used to; and a short nickname, local to each channel, used for messaging commands.

Nicknames vs Identifications

[symlynX]

Why don't you use PSYC as an IRC replacement?
It's IRC compatible.. even lets jabber users in
and defines the nickname namespace as local to
each user.

People have a psyc://my.trusted.server/~nick
identification which is unique, once you know
the person you will only be shown the nick.
If the nick collides with an other you can
rename the user within your personal namespace.

And you get to use your favorite IRC or jabber
client even though PSYC is a totally different
conferencing protocol.

Enjoy

Re:Nicknames vs Identifications

[metamatic]

What does PSYC gain me over XMPP? Given that XMPP is an RFC, I need a compelling end-user reason to use something else.