I love the simplicity of IRC, I still use it to this day, but I have to say, I understand why IRC cannot be used for any serious team communication.<p>The two biggest pain point that I see is:
1. Because there is no real account management you don't have any proper authentication, which make administrating a channel real dodgy (even with network provided bots).<p>2. No offline history: You have to have a client/bouncer running 24/24 if you want history.<p>One thing though, because of how IRC work, you don't have the problem that other protocol like XMPP faced with multy-device sync (there is a extension for that in XMPP but, like almost every extension in XMPP, not many client support it).<p>Also, nowadays we should consider end-to-end encryption standard.<p>I feel like IRC is in the same space as email: It's a very good technology that just lack a few feature to be perfect but any project that try to replace them just end up over-bloated with features ...
The article here claims that IRC is better than Matrix because Matrix supports pasting long snippets and IRC doesn't. The author furthermore claims that Matrix users are being a "nuisance" by posting long snippets to IRC with a link fallback, like this:<p><pre><code> ihabunek [m] sent a long message: < https://matrix.org/_matrix/media/blahblahblah >
ihabunek [m] uploaded an image: image.png (39KB) < https://matrix.org/_matrix/media/blahblahblah >
</code></pre>
This is "being a nuisance"? It's just two chat lines, and the first line isn't meaningfully longer than a link to pastebin. Maybe pasting the image was a bit excessive, but it's very likely to be auto-expanded in GUI IRC clients, making it an excellent fallback. It's not "being a nuisance." It's two links. It's fine.<p>The truth is, IRC folks do need to share long snippets and images, and they do it by linking to them; that's exactly what Matrix does when integrating with IRC. That's one among many reasons that Matrix is better than IRC.
It isn't that the features don't exist. I think most people on IRC just see the internet as their platform. Integrating image hosting into IRC seems absurd when there are perfectly good browsers and ways to host or self host images. Stuffing everything into one client, or worse, one corporation just restricts features and provides a single point of failure in both technical and censorship terms.
> IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages shall not exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters.<p>Yeah, lets just forget how painful it was for non english speaking users to use IRC. 255 characters for unicode and 510, but you have to guess encoding.
Kooky "reaction GIFs" in work chat are so inane. I mean, there's certainly a time and a place for browsing funny GIFs on the web, but making it a first-class part of work chat is so juvenile it's unreal.
I'm glad Freenode has a user base for work related stuff, but I man do I miss when Undernet or Dalnet was still popular. I know I'll never run into my mother on IRC, and it is probably because of the format.
Lacking support for pretty much everything other than lines of text alongside a handle enables one of my favorite aspects of IRC: a 10-row terminal is more than sufficient for the entire client UI.
This really comes back to the Capability vs. Suitability model that Gary Bernhardt has spoken about: <a href="https://www.youtube.com/watch?v=NftT6HWFgq0" rel="nofollow">https://www.youtube.com/watch?v=NftT6HWFgq0</a><p>IRC is capable. It is a box of nuts and bolts that lets us communicate and build awesome bots and so on.<p>Bloating the protocol gives us suitability: features that are robust and can federate.
We are running our own IRC server (UnrealIRCd + Anope for services) for 10+ years. We have bots for gitlab/github, schedulers, management bots (you can basically control whole infrastructure and all services from IRC), event logging channels, alerting, jobs/tasks bots, status checking etc. all with authentication and authorization.<p>This is working well for us, without any issues for years.
IRCv3 notwithstanding, the protocol from a software engineering point of view is horrible. It doesn't support asynchronous operations because responses cannot be tied to their corresponding requests, and many commands, successful or not, require a human to parse. Too bad that IRCnet only runs whatever has been written down in an official IETF RFC.<p>Despite all these deficiencies it's still widely used – My guess is that nobody has come up with a chat medium that would replace it completely. It's still pretty much the only decentralized, push-pull, clutter free real time discussion medium.
IRC is one of the few Internet venues I still frequent. Been using it since 1998. Some years ago an important (but small, private) channel moved from EFnet to Freenode, so that is the network I now use. Seeing Freenode IRCops looking to fix what ain't broken ("but it's opt-in" they'll say..) makes me have doubts about the move. If this sounds "get off my lawn" to you, you're getting it.
I think if most people saw the limitations of irc as the author then it would still be the dominant protocol<p>And it doesn't seem to me that "fixing" irc is just a matter of adding the bells and whistles, but there's some work to be done on the lower levels as well<p>For example, how well would irc work on mobile? Keeping logs requires a bot usually on irc as well.
This reminds me of what Apple does to the SMS/MMS ecosystem.<p>MUDs face a similar set of issues. Some new MUD frameworks skip over these by ignoring telnet and going HTML/JS.<p>There's an interesting third path, GMCP, which is basically treated by the server/client (once support is negotiated) as out-of-band communication. If either end can't negotiate support, you get the basic experience. As a pressure-release valve, options like this <i>can</i> be better than clients or servers trying to overload the primary protocol with magic messages that other servers/clients without support are still forced to digest and display.
The idea of embedding links to multimedia is a good one. They just need to form an open standard for encoding media and rich text in text streams, and let clients parse the standard and decide how to format it. Text clients could remove any multimedia/rich text, GUI users could render it all, blind users would receive alt-tags in a way that's easily spoken by TTS, etc. Because it's a standard for encoding media in a text stream, you don't have to change the IRC protocol, just add a plugin to the client. You could even format it so the simplest clients could just strip everything but the text.<p>Something like:<p><pre><code> %M!i=//shrt.url/j3f87h38f;t=fr,bb;a=Kitten Mittens!
Finally, there is an elegant, comfortable mitten for cats.
</code></pre>
This indicates an image link, a text foreground color of red, text background color of black, and alt-text for the image as "Kitten Mittens". Any existing IRC client can simply remove everything from "%M!" to the "!" + newline, or if they don't, the text just shows up on its own line below the metadata, which isn't hard to read. You could even encode it in-line, such as <i>"This is some %M!t=fr,b!text!."</i> Harder to read if the client doesn't implement the standard, though.
Formatting is pure fluff - it's convenient to have bold/italic/spoiler/code tags, and it is possible to implement them in a TUI without degrading anybody's experience. Link tags are not really necessary and a lot of clients don't even have them.<p>The image upload thing, though, the convenience there is being able to just upload an image directly into the client, rather than having to deal with some external service. That's it. There isn't much preventing this from being implemented in an IRC client.<p>Character limits are silly and should be removed - enforce them with a moderation bot if you really have to.<p>Just because most modern chat services are Electron trash does not mean we should throw out every bit of convenience learned. IRC (clients) could stand to gain better text formatting and file sharing options - things that make life easier for users, and in most cases don't really affect how the actual protocol works.
<i>P.S. A friend pointed out that the migration of non-hackers away from IRC is like a reverse Eternal September, which sounds great</i><p>I was a part of the original Eternal September in the 1980's as the Internet was opened up to undergrads. The idea of a "Reverse Eternal September" sounds super awesome! I wonder how it can be implemented? (In a limited context, not across the whole of the Internet, of course.)
The article doesn't talk about the best feature of Slack: a consistent message history for all the users. In IRC messages can easily get lost due to network splits or client disappearing. Not having everyone with the same message timeline can make some conversations quite awkward.<p>This is really the only feature I miss in IRC.
Ability to remove spam messages would be awesome, these days it is very hard to deal with on a public channels. Also log out of the box. None of them are distraction. And proper authentication out of the box. Better design for poor, unstable connections, i.e.
mobile phones.
Perhaps a side pan for embeds makes sense. upload images or code snippets by providing irc style references in the chat while not interrupting the flow of conversation because images and whatnot are expanded on the embed pane.
Counterpoint: The lack of accessibility in Slack does not mean it shouldn't be solved. Baby with the bathwater. Why dump all of slack when instead we can work on an accessible interface.
I just use <a href="https://www.irccloud.com/" rel="nofollow">https://www.irccloud.com/</a> and it's the best of both wordls ¯\_(ツ)_/¯
Now let's talk about the inherent lack of a good centralized identity service, the danger of the majority of IRC servers and clients being written in C and the inefficiency of the protocol itself for applications like high latency links? We might also talk about the lack of important modern features like basic negotiation of client encoding capabilities and what an absolute tire fire DCC-based features continue to be due to the "just link to an external website" mentality that stifles all discussion of replacements?
> "Remember that not everyone is like you."<p>Of course they aren't, but most people aren't like Drew Devault either. Most people don't use ancient hardware to prove some sort of point. The "Drew Devault will approve of it"-argument generally doesn't show up in a business case.<p>In a perverse way, I am glad that programmers come up with better and better ways to waste hardware resources. In doing so, they ensure the continued progress of the semiconductor (and battery) industry through mass market demand.<p>I do not believe it is a coincidence that Moore's law has slowed significantly right at the time when computers became "good enough" for the everyday user. If it wasn't for gamers spending hundreds of dollars on pushing more pixels on-screen, we'd be way behind on deep learning.<p>Buy a new computer, Drew.
Well, I consider stuff like the absence of server-side friend lists, server-rendered embeds and formatted messages a bug at best, though in IRC's case it's simply the lack of ability because the protocol is horribly outdated, modern approaches and limitations could afford a lot of QoL improvements.
IRC is forever tainted by graybeards that won't give up their terminal clients. People who want to get work done have moved on. The next generation of developers have no interest in IRC. It's a dead end.
It seems that the author references different IRC clients but at the same time ignores (can't say if on purpose or not) the fact that there are also alternative Slack clients which address many of the pain points.