Slashdot Mirror


IRC Turns 30 (www.oulu.fi)

IRC (Internet Relay Chat) was born at the Department of Information Processing Science of the University of Oulu 30 years ago. Taking some time out of his summer job, Jarkko Oikarinen developed the internet chat system. For the last several years, Oikarinen has been working at Google, overseeing the development of several communication services. Though several mainstream services have ended support for IRC over the years, the system is still in existence and used by many.

92 of 157 comments (clear)

  1. EFnet is still dying! by AndroSyn · · Score: 3, Funny

    Netcraft hasn't confirmed it yet, but EFnet is still dying.

    1. Re:EFnet is still dying! by Highdude702 · · Score: 2

      Efnet is full of scum now, dalnet has been dead to everyone but sex fiends for 15 years, Freenode has become "free support network" for various companies. XDCC is on its last leg as it has been for 20 years. Private IRC servers is where the fun is at..

    2. Re:EFnet is still dying! by Netcraft+Confirms+It · · Score: 1

      Yes, it's dying. It's been dying for 20 years.

  2. For those not familiar with IRC... by Anonymous Coward · · Score: 3, Funny

    ...here's a highly technical description of the software:

    https://www.youtube.com/watch?v=O2rGTXHvPCQ

    1. Re:For those not familiar with IRC... by Doctor+Morbius · · Score: 2, Insightful

      It's not spam. It's relevant and funny.

      --
      If I disagree with you it's because you are wrong.
    2. Re:For those not familiar with IRC... by Provocateur · · Score: 1

      Get off my lawn!

      It had to be said.

      --
      WARNING: Smartphones have side effects--most of them undocumented.
  3. Old code never dies. Working code at least by AlanObject · · Score: 2

    Isn't Slack based on IRC? Slack is the Latest Cool Thing you know.

    1. Re: Old code never dies. Working code at least by reanjr · · Score: 4, Insightful

      It should have been. There's no reason it couldn't have been. It even used to support it with an optional gateway. But no. Slack decided to fill our Intertubes with yet another worthless proprietary clone of IRC.

  4. And re-invented over and over again ... by UnknownSoldier · · Score: 4, Insightful

    The latest re-incarnation is Slack. Before that was HipChat, etc.

    Note: If you can't stand the amount of spam images in a channel and want to minimize the stupid GIF animations you can use the Slack command: /collapse

    It is almost comical how every modern utility has been re-invented multiple times.

    1. Re:And re-invented over and over again ... by Narcocide · · Score: 2

      The biggest part of the problem is people framing the task of creating better communication tools in a metaphor about bulk harvesting of vermin for extermination.

    2. Re:And re-invented over and over again ... by mwvdlee · · Score: 1

      The fact that it's constantly being re-invented is proof of it's quality.
      Businesses would be trying to vendor-lock customers in proprietary protocols based on OTHER open standards if it wasn't.
      Worse, they could be inventing their own protocol from scratch.
      IRC will still be around long after the latest fad chat has died.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    3. Re:And re-invented over and over again ... by Anonymous Coward · · Score: 1

      You sound like a member of PETA. Glad you got that Animal Crackers business sorted out, I was losing sleep over that.

    4. Re:And re-invented over and over again ... by CaptainDork · · Score: 1

      AI builds a better mouse.

      --
      It little behooves the best of us to comment on the rest of us.
    5. Re:And re-invented over and over again ... by tlhIngan · · Score: 1

      The latest re-incarnation is Slack. Before that was HipChat, etc.

      Note: If you can't stand the amount of spam images in a channel and want to minimize the stupid GIF animations you can use the Slack command: /collapse

      It is almost comical how every modern utility has been re-invented multiple times.

      Except consuming so much CPU and RAM that buying an i9 with 32GB of RAM is sort of necessary to use Slack.

      Which I never understood since Discord runs perfectly fine consuming next to no resources.

      Of course, the IRC client consumes even less resources since it doesn't have to carry a full web browser with it, but hey.

      I'm not sure what Slack is doing, reimplemented polling sockets or something?

    6. Re:And re-invented over and over again ... by bobmagicii · · Score: 1

      "Though several mainstream services have ended support for IRC over the years" in my personal echo chamber, most of the people i know are getting tired of all the electron apps and going back to irc *shrug*

    7. Re:And re-invented over and over again ... by UnknownSoldier · · Score: 1

      Yes, I should have mentioned that Slack is a bloated resource hog.

      Probably because Slack is built with Electron

    8. Re:And re-invented over and over again ... by antdude · · Score: 1

      IRC is fast and not bloated. Slack and others are so bloated and slow. I'm old school. :(

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
  5. Re:Old code never dies. Working code at least by tepples · · Score: 1

    It probably depends on how you define "based on". In any case, Slack isn't compatible with IRC at present, as the summary links to a story about Slack having shut down access to its service through IRC protocol.

  6. IRC and Usenet are why we don't need Facebook by mi · · Score: 5, Insightful

    IRC for "instant" communications among individuals and groups, and Usenet for public forums is why there is no need for Facebook, Twitter and other centrally-controlled systems so prone to censorship and similar abuses both by the commercial interests controlling them, and the governments able to twist the former's arms.

    --
    In Soviet Washington the swamp drains you.
    1. Re:IRC and Usenet are why we don't need Facebook by ArchieBunker · · Score: 1

      Do IRC servers still require you to run ident?

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
    2. Re:IRC and Usenet are why we don't need Facebook by SantiagoMcRib · · Score: 1

      He didn't say the "I" in "IRC" stands for instant, he said that IRC is for instant messaging and usenet is for forum posting and anything built on top of those platforms, or extending that base level of functionality is being used as a tool for censorship or data harvesting.

      Maybe the real dumbass is the guy who can't fully parse through sentences before launching into his pedantic ranting?

    3. Re:IRC and Usenet are why we don't need Facebook by jellomizer · · Score: 1

      Except the fact that IRC and Usenet was like getting an open firehose of information especially on popular boards. Social Media you just get a garden hose, where can control the nozzle.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    4. Re:IRC and Usenet are why we don't need Facebook by mi · · Score: 1

      Except the fact that IRC and Usenet was like getting an open firehose of information especially on popular boards

      How is that a problem? You have — and always had — the tools necessary to filter this and, if a particular server's policy didn't suit you, you could switch without changing the interface(s) and losing the associations, contacts, and the audiences.

      --
      In Soviet Washington the swamp drains you.
    5. Re:IRC and Usenet are why we don't need Facebook by ljw1004 · · Score: 1

      IRC for "instant" communications among individuals and groups, and Usenet for public forums is why there is no need for Facebook, Twitter and other centrally-controlled systems so prone to censorship and similar abuses both by the commercial interests controlling them, and the governments able to twist the former's arms.

      I loved Usenet. But I don't think it would ever scale to the quantity of data (basically, videos) that's posted to youtube or facebook or twitter.

    6. Re:IRC and Usenet are why we don't need Facebook by CaptainDork · · Score: 1

      No.

      IRC ans Usenet had major problems.

      There was no censorship, which made them useless as tits on a boar hog, they were very awkward to use. The new kids on the block have GUI and dancing bunnies.

      Also, both of those platforms were so ridden with viruses (pre-malware vandalism) that users were scared to click on anything.

      When Compuserve showed up we all evacuated the IRC and Usenet spaces.

      What, precisely, did IRC and Usenet offer as a firewall against advertisement, government snooping and manipulation, and trolling?

      Nothing.

      That's the state of the art today with Facebook and Twitter, and all the rest.

      --
      It little behooves the best of us to comment on the rest of us.
    7. Re:IRC and Usenet are why we don't need Facebook by mi · · Score: 1

      But I don't think it [Usenet] would ever scale to the quantity of data (basically, videos) that's posted to youtube or facebook or twitter.

      Stipulating for the sake of argument, this would be a bad thing, why wouldn't it?

      By Moore's Law, our computers have become 65534 times more powerful than they were 24 years ago (in 1994). Facebook et al themselves are demonstrating, the hardware and the network connectivity are there — as you say. Why wouldn't servers talking an open protocol with each be able to do it? SMTP-servers can — e-mailing videos is "totally a thing" today — why wouln't NTTP-servers not be?

      --
      In Soviet Washington the swamp drains you.
    8. Re:IRC and Usenet are why we don't need Facebook by mi · · Score: 2

      There was no censorship, which made them useless

      There was some censorship — some groups were moderated, the moderators chosen by mutual consensus. The consensus was not binding on the non-consenting, however, and so could not itself become too abusive.

      both of those platforms were so ridden with viruses (pre-malware vandalism)

      Totally not a problem today, is it?..

      What, precisely, did IRC and Usenet offer as a firewall against advertisement, government snooping and manipulation, and trolling?

      What they offer is the diversity. Standing up your own IRC or NNTP server was and remains trivial. The like-minded could join your network with their own servers, carrying your channels and/or newsgroups. The early Internet's optimistic promise of "routing around censorship" would hold...

      Now, try standing up your own Facebook...

      --
      In Soviet Washington the swamp drains you.
    9. Re:IRC and Usenet are why we don't need Facebook by nnet · · Score: 1

      whats the fqdn of your nntp and irc servers?

    10. Re:IRC and Usenet are why we don't need Facebook by CaptainDork · · Score: 1

      You make good points and I didn't say the current crop of trash was better at security.

      However, I take issue with:

      Standing up your own IRC or NNTP server was and remains trivial. The like-minded could join your network with their own servers ...

      I'm looking at my Facebook Friends list and none of them would understand WTF you're talking about.

      As you know, social media evolved from klutzy BBS through IRC and Usenet out to Compuserve and AOL, to Myspace, Facebook, Twitter, and all the rest of actual useful shit.

      However, the DNA is very similar for all the above.

      All those softwares are leaky and always will be.

      --
      It little behooves the best of us to comment on the rest of us.
    11. Re:IRC and Usenet are why we don't need Facebook by 0100010001010011 · · Score: 1

      I don't think it would ever scale to the quantity of data (basically, videos)

      It already has and does. I have yet to see full 50GB+ BlueRay rips posted to FB.

    12. Re:IRC and Usenet are why we don't need Facebook by 0100010001010011 · · Score: 1

      GPG signing and/or encryption.

    13. Re:IRC and Usenet are why we don't need Facebook by CaptainDork · · Score: 1

      You know what that means and I know what that means, but no one on my Facebook Friends list has any idea what that means.

      Just as we moved from assembly (extremely difficult) out to the higher-level languages for a reason, so did we grow the social platforms to include the Gentle User.

      --
      It little behooves the best of us to comment on the rest of us.
    14. Re:IRC and Usenet are why we don't need Facebook by ljw1004 · · Score: 1

      [I don't think it would ever scale to the quantity of data (basically, videos)]

      It already has and does. I have yet to see full 50GB+ BlueRay rips posted to FB.

      The upload rate to Youtube I saw for last year was 270 terrabytes/day with retention period of forever, compared to usenet daily volume of 27 terrabytes/day last year with retention period of 4 years. You reckon usenet could handle an order of magnitude more than it currently does?

    15. Re:IRC and Usenet are why we don't need Facebook by gr8dude · · Score: 1

      The comparison is not fair.

      One doesn't need to know how an IRC server works in order to use it. You can create a friendlier client GUI and thus lower the entry barrier so even the folks on your Facebook list can use it with ease.

      Yes, the OP mentioned setting up one's own servers, but only a fraction of those on IRC are responsible for running the infrastructure - the others are just people who want to chat.

      In my area, back in the days, a lot of people just said "mirc" when they referred to chatting online. To them, it was not an IRC server, not a protocol, not a network - they didn't care. It was all about the "pacman-like" icon of a particular client that happened to be popular. So, one could argue that IRC is not only for geeks.

    16. Re:IRC and Usenet are why we don't need Facebook by CaptainDork · · Score: 1

      One could argue, however, that IRC is a vacant lot.

      No party, no ice and no crowd.

      --
      It little behooves the best of us to comment on the rest of us.
    17. Re:IRC and Usenet are why we don't need Facebook by Highdude702 · · Score: 1

      But the liberals want censorship, therefor IRC is bad.

    18. Re:IRC and Usenet are why we don't need Facebook by Highdude702 · · Score: 1

      Sounds like you need smarter Facebook friends, however them being Facebook friends.... I think there may be a trend here..

    19. Re:IRC and Usenet are why we don't need Facebook by CaptainDork · · Score: 1

      Why would I need smarter Facebook friends?

      Sharing is a simple mouse click, and I get cat videos.

      You aren't smart about this shit -- you're just experienced.

      I certainly would not add you as a Friend.

      And I wouldn't "server-up" to connect with you.

      Your experience does not impress me.

      --
      It little behooves the best of us to comment on the rest of us.
    20. Re:IRC and Usenet are why we don't need Facebook by mea2214 · · Score: 1

      ... compared to usenet daily volume of 27 terrabytes/day

      Did I read that correctly? I thought Usenet was pretty much dead. Many very popular newsgroups, like rec.sports.baseball, that received 1000+ posts/day back in the day were completely empty as of a couple years ago.

    21. Re:IRC and Usenet are why we don't need Facebook by ljw1004 · · Score: 1

      [usenet daily volume of 27 terrabytes/day] Did I read that correctly? I thought Usenet was pretty much dead. Many very popular newsgroups, like rec.sports.baseball, that received 1000+ posts/day back in the day were completely empty as of a couple years ago.

      I got the number from https://en.wikipedia.org/wiki/... -

      Much of this traffic increase reflects not an increase in discrete users or newsgroup discussions, but instead the combination of massive automated spamming and an increase in the use of .binaries newsgroups

    22. Re:IRC and Usenet are why we don't need Facebook by CaptainDork · · Score: 1

      I don't know what your point is, so I'll offer one of my corollaries:

      When anything is digitized, it enters the public domain by default. © 2018 CaptainDork

      --
      It little behooves the best of us to comment on the rest of us.
  7. Server-side chat history and attachments by tepples · · Score: 4, Insightful

    For some use cases, tne big advantage of Skype, Slack, HipChat, Discord, and other web-based functional clones of IRC over IRC itself is that they store chat history on the server side. This lets a user see messages that were sent to a channel while the user was offline. It's as if an IRC server had built-in functionality equivalent to that of a bouncer, except that each user doesn't have to lease a VPS on which to run ZNC. The major IRC networks couid offer a built-in bouncer to compete with proprietary web-based chat, but they don't.

    Another is that web-based chat allows uploading attachments. IRC has traditionally used pastebins and filedrops for this. The major IRC networks couid operate pastebin and filedrop services for their users to use, but they don't.

    1. Re:Server-side chat history and attachments by tepples · · Score: 1

      I agree that in theory, chat with server-side history is functionally to a message board. Some communities prefer chat with history because history allows users in less populous (and often less economically privileged) time zones to catch up. They prefer chat with history over a message board primarily for two user experience reasons:

      Lighter chrome per message User interface elements are smaller than those of phpBB, Slash/Rehash, and other popular message board software. Slash and Rehash, for instance, add two lines (subject and byline) above each comment and one line ("Reply to This | Parent | Share") below. Chat collapses these by default, except for the author's name and an optional timestamp. This encourages shorter messages that aren't quite as monolithic, encouraging a more conversational style as opposed to the more formal style of monolithic multi-paragraph message board posts. Real-time updates All users looking at a channel receive new messages instantly through a WebSocket without having to refresh the page.
    2. Re:Server-side chat history and attachments by dknj · · Score: 1

      Or, it's a chat system that is simply logged.

      I recall plenty of Epic and mIRC scripts that would fetch metadata from links ala slack and hipchat. I remember plenty of eggdrop bots which provided /fortune and /build functions. Nothing new, and is most probably what powers the backend of Slack!

    3. Re:Server-side chat history and attachments by tepples · · Score: 1

      Say I wanted to set up an IRC server that supports logging of messages and attachments, plus a server-side metadata bot so that posting a link in a channel doesn't cause a couple hundred users' metadata fetching scripts to all fetch metadata at the same time, thereby hammering the site with requests. Is there an IRC server distribution that supports all this?

    4. Re:Server-side chat history and attachments by Highdude702 · · Score: 1

      Iirc all servers can log, just not log and play back on connect that I know of. However since IRC is an open protocol there is nothing stopping someone from making a server that does just that and if you look around you may even find plugins for current servers that add those enhancements.

    5. Re:Server-side chat history and attachments by skids · · Score: 1

      For some use cases, tne big advantage of Skype, Slack, HipChat, Discord, and other web-based functional clones of IRC over IRC itself is that they store chat history on the server side.

      ...for other use cases this feature is actually now legally tenuous (GPDR and such) and may require, depending on the country of origin of the users and/or the service provider, staffing to remove any PII that ends up in the channel or exercise the "right to be forgotten".

      So if they cannot already, I'd expect these protocols to make that feature optional.

    6. Re:Server-side chat history and attachments by tepples · · Score: 1

      I don't see how the law would differ between logged chat and a message board. For example, would Slashdot be required, and would Slashdot be able, to handle an erasure request from a user?

    7. Re:Server-side chat history and attachments by tepples · · Score: 1

      It is - or at least was - generally considered bad taste to log chats on IRC.

      Was. I get the impression that since EFnet's popularity peak, many chat communities have become more open to logging as a way of allowing people in less privileged time zones to participate.

  8. QBD by rilister · · Score: 2

    ... and surely there's no better way to celebrate than browsing QDB: the best of IRC. One of the funniest things I've ever read on the internet. Captures the unique blend of genius and idiocy on IRC
    http://www.bash.org/?top

    --
    'This writing business. Pencils and what-not. Over-rated if you ask me. Silly stuff. Nothing in it' - Eeyore
  9. IRC: the good and the bad by Anonymous Coward · · Score: 4, Insightful

    IRC did a lot of things right, that more "modern" IMs do totally wrong. IRC is decentralized, and anyone can run a server. It's lightweight, and easy to use. It is an open protocol. It lets you use any client you want, not just some single Facebook-blessed one. It wasn't made to monetize your communication.

    However the core protocol needs end to end encryption. Not encryption where a multinational manages your private key "for" you, but true, E2E encryption. Not as some weird add-on that most people will never use, but by default. This is to keep Zuckbook style snooping away. It needs better protection against malicious actions. It needs some more modern features like presence.

    At the core, it is what the internet should be: decentralized and put power in the hands of users, not advertisers and data scrapers.

  10. IRC's Legacy by Only+Time+Will+Tell · · Score: 1

    Without IRC, how would have I gotten all those warez...er...I mean chat with friends?

  11. Congrats! by 93+Escort+Wagon · · Score: 4, Funny

    /me slaps Whipslash with a wet trout

    --
    #DeleteChrome
    1. Re:Congrats! by Highdude702 · · Score: 1

      I think you meant Large Trout.

    2. Re:Congrats! by 93+Escort+Wagon · · Score: 2

      I hung out on Undernet - we did things differently.

      --
      #DeleteChrome
    3. Re:Congrats! by Highdude702 · · Score: 1

      Yea that's where I was "raised" so to speak, warezdk and some others is where I frequented. But that's actually a default in Mirc since about 1994

  12. Re: Old code never dies. Working code at least by AlanObject · · Score: 4, Insightful

    I just don't get it.

    Unfortunately if you work on outgoing business you end up using a lot of different communication utilities. It isn't just Slack, but over the past several years I got involved with companies and standards-setting bodies that use it. So if you want to be plugged into the real-time communications of that company or group, you have to use it.

    But that isn't really different from other software -- on this Mac I am typing with I also have to have Skype, GoTo Meeting, WebEx, Zoom, and a few others I forget the names of until someone calls a meeting. If you ask any engineer on the call why they use it they just shrug and say "that's what our company uses."

    To make matters worse many of the "your business in the cloud" type operations like Zoho try to get in the action as well. I think the Zimbra mail server (VMWare) also offers "collaboration" features that host chatrooms and IP calls. The only time I pushed back on using something is there was one from Asia that had a bad reputation for installing malware. I forget the name. I got the client to switch to WebEx for that call but who knows what the condition of their own systems are at this point.

    So to answer your question: there really isn't any big technical merit between them. Yeah some work better than others. Skype really fsked themselves up but since it is Microsoft you will still have to use it. What counts is marketing and market share. No real mystery.

  13. Best feature by religionofpeas · · Score: 4, Funny

    IRC's best feature was the automatic translation of passwords to a bunch of asterisks.

    1. Re:Best feature by Anonymous Coward · · Score: 1

      It works here too... hunter2

    2. Re:Best feature by SantiagoMcRib · · Score: 3, Funny

      What did you say? All I see is *******

  14. 20 years ago I met my wife on IRC by Anonymous Coward · · Score: 3, Interesting

    Met my wife on DALnet's #England channel 20 years ago when I was in the UK and she was in the USA, we now live in the USA with our kids, that channel resulted in a lot of people we personally know getting married, so who needs Facebook and Tinder.

  15. End-to-ends encryption by tepples · · Score: 1

    However the core protocol needs end to end encryption. Not encryption where a multinational manages your private key "for" you, but true, E2E encryption.

    Some chat services support end-to-end (E2E) encryption for one-to-one chat but not group chat. The point of the latter is to broadcast a message to all other users of a channel. How would end-to-ends (plural) encryption work?

    It needs some more modern features like presence.

    IRC protocol already has presence support, which many clients expose as the /away command. Though this doesn't include "offline" status at the protocol level, an IRC server could in theory implement "offline" as a subset of away status by providing a bouncer for all users of the server to use.

    1. Re:End-to-ends encryption by tepples · · Score: 1

      Until you get to a channel with 200 or 500 people in it, and the size in bytes of the set of asymmetrically encrypted copies of the symmetric key for each message greatly exceeds the size in bytes of the message. I've seen channels that big in both IRC and Discord.

      And if a new user joins and a channel's moderator accepts the new user's request to be read in on the channel's history, how does the new user's symmetric key get added to all the existing messages? By decrypting the symmetric key of each message using the moderator's private key and reencrypting it using the new user's public key? That could take a while.

      Furthermore, how does the user keep his key synchronized across two desktop computers, a laptop, and a tablet?

    2. Re:End-to-ends encryption by dknj · · Score: 1

      B L O C K C H A I N

    3. Re:End-to-ends encryption by tepples · · Score: 1

      Why is it that on Slashdot, so many people think that just because something is not 100% perfect in 100% of the possible cases they can imagine, it must be useless?

      It may be a counterreaction to a delusion commonly observed among marketing departments that if something is 100% perfect in one case, it must be perfect for all cases. I personally was trying to help characterize the limits of end-to-ends encryption so that people considering it could see under which conditions it is practical.

      I already keep things synced across multiple devices. [The keypair for end-to-end encryption] is simply another file in the mix.

      Does this work for both web-based and non-web-based chat clients? I thought web applications, such as clients for chat services, couldn't read arbitrary "files" from your device for security reasons, and you didn't want to upload your private key to the server in order to prevent the server from compromising your encryption. Once you have synced the file containing a keypair, how do you get it into the JavaScript-based chat client's local storage? Or is it generally better to drop a web-based client in favor of an installable native client, provided one even exists for a given pair of chat protocol and client platform?

    4. Re:End-to-ends encryption by tepples · · Score: 1

      Correct. IRC was intended for installable native clients. But as I understand it, IRC also originated in a time when most computers connected to the Internet had a compiler already installed, or at least allowed execution of unsigned binaries added by a user, as opposed to being cryptographically locked down to those apps hand-picked by the computer's manufacturer. That makes installable native clients slightly more practical than in a 2018 scenario where one wouldn't want to launch without iOS support.

  16. Freenode still huge for F/OSS project development by TheDarkener · · Score: 1

    I work with a small handful of open source project teams and Freenode is still the hub that most F/OSS developers use to communicate with each other. I head a project called "Cool Mic" (#coolmic, a livestreaming audio client for Icecast) and I've worked with the two primary developers for years. I've never met them IRL (they live in Germany, I live in California). I consider them good friends, along with the people in #icecast. My local LUG has a pretty active IRC channel as well.

    I've seen countless bugs get squashed, users get instant support, and friends be made on IRC over the past 20 years and, at least with Freenode, it shows no signs of slowing down. If anything it's getting more popular. It speaks to the distributed nature of the Internet and how distribution (separate, independent channels for instance) truly serves to strengthen the network as a whole. Huge monolithic services like Facebook and Twitter only take away from what makes the Internet robust and resilient IMHO.

    --
    It is pitch black. You are likely to be eaten by a grue.
  17. How does DCC SEND traverse NAT? by tepples · · Score: 1

    Skype, Slack, Discord, and other proprietary web-based chat platforms allow uploading attachments even if your device is behind network address translation (NAT).

    DCC requires the sender to be able to receive incoming connections, which is not true of a device behind NAT. UPnP is supposed to let applications configure a router to punch a hole in the NAT, but it's often disabled for security reasons, and it doesn't work anyway across a NAT operated by your ISP (called a carrier-grade network address translation or CGNAT).

    Or are you referring to use of a reverse DCC SEND to let a sender behind a NAT send a file to some proxy, from which a recipient behind a different NAT retrieves the file with a normal DCC SEND? If so, which if any IRC networks make such a proxy available to their users?

    1. Re:How does DCC SEND traverse NAT? by AndroSyn · · Score: 1

      Well the DCC protocol itself isn't actually a part of the IRC protocol itself. It's an informal add-on to the protocol, that involves the clients speaking to themselves.

      As far as traversing NAT goes, unless you have a specific protocol handler for IRC, like you would for FTP, it doesn't. If you had a file send protocol that was based on UDP, you could use IRC as a replacement for a STUN server. However, that is a completely client side issue, its not something the IRC protocol itself addresses directly, maybe it should though.

  18. Re: Old code never dies. Working code at least by Highdude702 · · Score: 1

    That was it.

  19. Re: Old code never dies. Working code at least by epiphani · · Score: 4, Insightful

    IRC as a protocol and software stack is generally crap. While it was functional, a huge swath of IRC would have to be completely rewritten - including the underlying foundations - to turn it into a modern Slack or similar service. Honestly, it would be far easier to start from scratch than to base it on IRC. While a few things could be learned from how IRC was built, I wouldn't use that code as a base for anything.

    Source: Me. Maintainer of Bahamut IRCd from 2001-2018.

    --
    .
  20. Re: Old code never dies. Working code at least by UnknownSoldier · · Score: 1

    Because Slack is the latest "shiny" / fad.

    "Benefits" include:

    * When you are offline DM (Direct Messages) are emailed to you
    * Chat saved server-side
    * Multi-Factor Authentication
    * Threads (can reply to someone and start a thread)
    * Multi-line code snippets using ```...``` and basic MarkDown
    * Editing of messages
    * Preview of links
    * Custom emoji

    Yeah, most of those are fluff.

    Now if there was only an auto-kick clueless noobs who can't fucking read the pinned messages and have to use @here in a channel of 500+ people ...

  21. By Geeks For Geeks. by westlake · · Score: 1

    IRC for "instant" communications among individuals and groups, and Usenet for public forums is why there is no need for Facebook, Twitter and other centrally-controlled systems so prone to censorship and similar abuses.

    Let's be honest here. IRC and Usenet clients were --- and in many ways still are --- painfully arcane and riddled with geek jargon. Microsoft Chat, the IM messaging and chat rooms of online services like AOL were proof that ift didn't have to be this way.

    1. Re:By Geeks For Geeks. by mi · · Score: 2

      it didn't have to be this way.

      Exactly. It didn't have to be that way — and whatever shortcomings there were, weren't due to any inherent deficiencies of the protocols.

      Instead of throwing it all out, we could've improved the clients. Indeed, the NNTP-client still built into Thunderbird is not any less friendly, than the rest of the application. Likewise, Pidgin and other modern instant-messengers offer perfectly decent IRC implementations.

      What makes it "by geeks for geeks" is the absence of marketing — there is no single entity to offer Apple, for example, a large sum of money to put an IRC-client on every iPhone. There are no other problems...

      --
      In Soviet Washington the swamp drains you.
    2. Re:By Geeks For Geeks. by Highdude702 · · Score: 1

      That microsoft chat program you speak of, was just an IRC client.

  22. Re: Old code never dies. Working code at least by laffer1 · · Score: 1

    It's basically IRC with a few extra features, better file transfer, audio chat/screen sharing, easy ways to share code snippets and lack of compatibility with all operating systems. For people that don't know IRC, it's amazing.

    It also supports bots and integration hooks that tie into things like jira, jenkins and other tools.

  23. The value of a distribution by tepples · · Score: 1

    Is there an IRC server distribution that supports all this?

    if you look around you may even find plugins for current servers that add those enhancements

    Hence why I asked "distribution".

    The benefit of Skype, Slack, Discord, and HipChat is that someone without experience in looking around doesn't need to learn how to look around for a combination of server and plug-ins. To many organizers of communities of people on the Internet, the benefit of everything already being there outweighs these chat platforms' proprietary character. If someone were to come up with a solid answer for "Which server and which plug-ins?" to which I could refer people, there wouldn't be quite so much of a need for Skype, Slack, Discord, and HipChat.

    1. Re:The value of a distribution by Highdude702 · · Score: 1

      I don't include relying on other peoples infrastructure as a benefit.

  24. Re:Pretty sure I did it thru NAT by tepples · · Score: 1

    it's been a LONG TIME since 1994-2001 when I was on IRC

    Back when IRC was still popular, most Internet-connected households had only one PC connected to the Internet at a time, and there weren't enough Internet users in IPv4 address-poor countries to make CGNAT a necessity. Nowadays, those are no longer the case quite as often.

    What brought NAT up ? Was it in your conversations earlier with others??

    Yes. For example, Bert64 reports that all home ISPs in Myanmar use CGNAT.

  25. netsplit by Anonymous Coward · · Score: 1

    I think I missed half the comments.

  26. Is that zero cool? by mydots · · Score: 1

    At first glance I thought it was a scene from hackers 2.0.

  27. Re:"CURE" for DCC/NAT's in bookmarks/favs... apk by tepples · · Score: 1

    Many ISPs' networks are structured in such a way that "port forward 113 & open a range" is not enough. See the post by Bert64 that I linked above and "Carrier-grade NAT" on Wikipedia for background. And even on those ISPs that do allow forwarding a port, a customer may not understand how to do so.

  28. I miss MindAlign... by gosand · · Score: 1

    Back in 2008ish we started using MindAlign at a large bank I worked at, where we had a distributed team. It was great! I'd used IRC in the past and it was similar but I think better for what we were doing. I heard that MS had purchased them, and incorporated their code into MS Lync Group Chat, which we then started using because it was MS, so - Corporate Approved! :|

    Then MS completely crapped on that product and killed it, and now there is MS Teams which is their super-integrated-with-O365 garbage solution to a problem they already had solved!

    So where I work now we can't use Slack (not corporate approved) so we are stuck with what we fumbled around with before MindAlign way back - regular IM but no searchable logged history. It's a combination of Skype for Business and regular Skype, because we have to chat with contractors who don't have corporate accounts.

    --

    My beliefs do not require that you agree with them.

  29. Re: Old code never dies. Working code at least by reanjr · · Score: 1

    And yet no protocol has been introduced since that actually solves the same problems. XMPP came close, but then died off with everyone's taste for XML.

    It's not that IRC is a super great protocol, it's that it's the only standard we've got. Extend the standard (I don't agree the fundamentals would have to change for Slack). Make a new standard. Use XMPP. Whatever. Just don't introduce another useless proprietary messaging protocol.

  30. Re: Old code never dies. Working code at least by Kjella · · Score: 1

    IRC as a protocol and software stack is generally crap. While it was functional, a huge swath of IRC would have to be completely rewritten - including the underlying foundations - to turn it into a modern Slack or similar service. Honestly, it would be far easier to start from scratch than to base it on IRC. While a few things could be learned from how IRC was built, I wouldn't use that code as a base for anything.

    Is there such a thing as "the" IRC code, I was under the impression it was a protocol not an implementation. But in any case I think the DCC code would need a major workover. Or really any non-text case, today I'd probably go for JSON or XML, back then it was trouble enough with non-ASCII....

    --
    Live today, because you never know what tomorrow brings
  31. Re: Old code never dies. Working code at least by AndroSyn · · Score: 1

    I'd 100% agree with you that trying to turn IRC into something modern like Slack just doesn't make sense. I know I certainly wouldn't try doing it.

    Things like channels and nicknames, really don't work so well in modern contexts. The fact that it is an ephemeral medium, that if you're not connected to IRC, you don't have any chat history.
    Trying to use IRC on a mobile device is even worse, nothing like getting a ping timeout and not realizing it for a few minutes because you hit a dead zone. Then you disconnect/rejoin rinse and repeat.

    The one thing about working on an IRC daemon is that you learn a lot of lessons on how NOT to design a modern chat system.

    At least that's the viewpoint of this jaded ircd-ratbox coder ;)

  32. Re: Old code never dies. Working code at least by AndroSyn · · Score: 1

    Is there such a thing as "the" IRC code, I was under the impression it was a protocol not an implementation.

    It's both. There are many IRC daemons out there, most of them written in C, thats what the clients connect to. The protocol presented to the client tends to be mostly compatible across implementations, with various minor quirks here and there.

    But in any case I think the DCC code would need a major workover.

    As far as DCC goes, thats a client side protocol, that really doesn't involved the ircd at all beyond passing the messages between the clients exchange the IP/port info.

    Or really any non-text case, today I'd probably go for JSON or XML,

    One of the nice things about the IRC protocol itself is that it is rather fast to parse. You can pretty easily parse it with something like strtok(). Given the time period the protocol was designed, speed of parsing is very important. Especially since most IRC daemons single threaded event driven processes.

  33. Re:Use a DMZ instead then... apk by tepples · · Score: 1

    Even a DMZ doesn't work if your ISP blocks incoming connections before they even get to your modem.

  34. Re:True that: I agree but... apk by tepples · · Score: 1

    "Time for a new ISP" doesn't help if all the other home ISPs in the same city have the same dain bramage. Please reread the Bert64 comment I linked.

  35. Re:IRC is dying, thank god by Highdude702 · · Score: 1

    So its like Twitter or Facebook, except anybody can be "The Man" not just one side of a political spectrum? Sounds better than both to me the way you describe it.

  36. Re:BIG "IF" that tepples but... apk by tepples · · Score: 1

    ISPs applying this technique filter out all incoming connections. The subscriber's modem doesn't even have a publicly routable IP address. Instead, the ISP assigns the subscriber an IP address in the reserved space 100.64.0.0/10 (as documented in RFC 6598), which is routable only within that ISP's network, and translates addresses within that range to a much smaller address space as packets enter and leave the ISP's network.

    And as Bert64 wrote, Myanmar is among the countries that have so few IPv4 addresses allocated to them that all ISPs have to run home users behind NAT in order to provide service. Say you have 16,000-odd IP addresses (a /18) but 10 million customers. The pigeonhole principle means you can't put each customer on a separate IP address. At a global scale, with 7 billion people and 4.2 billion IP addresses, you can't give everyone a unique address.

  37. Re: Old code never dies. Working code at least by secretagentmoof · · Score: 1

    2001? noob.