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.
Netcraft hasn't confirmed it yet, but EFnet is still dying.
...here's a highly technical description of the software:
https://www.youtube.com/watch?v=O2rGTXHvPCQ
Isn't Slack based on IRC? Slack is the Latest Cool Thing you know.
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.
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.
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.
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.
... 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
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.
Without IRC, how would have I gotten all those warez...er...I mean chat with friends?
/me slaps Whipslash with a wet trout
#DeleteChrome
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.
IRC's best feature was the automatic translation of passwords to a bunch of asterisks.
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.
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.
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.
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?
That was it.
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.
.
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 ...
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.
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.
MidnightBSD: The BSD for Everyone
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.
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.
I think I missed half the comments.
At first glance I thought it was a scene from hackers 2.0.
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.
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.
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.
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
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 ;)
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.
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.
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.
Even a DMZ doesn't work if your ISP blocks incoming connections before they even get to your modem.
"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.
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.
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.
2001? noob.