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.
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).
2. No offline history: You have to have a client/bouncer running 24/24 if you want history.
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).
Also, nowadays we should consider end-to-end encryption standard.
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 author specifically calls out ephemerality as a feature of IRC.
If it's easy to get history people will assume everyone is reading what they're typing. This would make people feel obligated to play catch-up every time they miss some messages due to being AFK or in the zone.
By making history hard to obtain, IRC simulates real-world conversation -- you're either in the room or you're not.
After doing some digging, it looks like there's some people working on a new spec for IRC version 3. One of the additions is the ability to request chat history from the server. Though I'm not sure when it will be implemented since it's been on the table for 4 years now.
> No offline history: You have to have a client/bouncer running 24/24 if you want history.
I would say it's even worse than this. Even if you attempt to have a client 24/7, the lack of an acknowledgement and re-transmit on lack of acknowledgement means that if you have any hiccup that causes you to need to reset the TCP connection, you can drop messages.
> 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).
That's not really an issue of IRC itself, but the IRC network you are using.
Running your own IRC server would solve that issue - ngircd for instance supports authentication using PAM or inspircd can directly perform authentication against either LDAP or a SQL database.
And doesn't IRCv3 SASL authentication + only allowing registered users into the channel pretty much solve the issue as well?
I think both of these are important problems (and number among the issues I alluded to in the conclusion of the article). I hope to see them improved in the future and will provide whatever support I can to IRC networks working on them.
However, if you're going to run your own IRC server you can also run your own bouncer service. Lots of authentication options exist as well. IRC is totally fine for an org who can stand up a server. It's pretty low-maintenance too.
Couldn't you layer your own account management and other conveniences on top of IRC ? Like use the underlying chansrv tech for auth but add your own layer on top for password retrieval or 2FA. You could always run a server which has dedicated bots doing the bounce per user. That way you never have to auth directly with the server, etc. Maybe a little over-complicated, but it lets you use the existing tech which is already widespread.
"Because there is no real account management you don't have any proper authentication, which make administrating a channel real dodgy" I think often that lack of needing an accout is an advantage, and not a disadvantage. However, sometimes you do want some, and many IRC services include NS REGISTER and NS INFO and so on for account management; even without that, channels can be passworded if needed.
"You have to have a client/bouncer running 24/24 if you want history." Or a logging bot, which some channels have. Another alternative is for the logging to be part of the server implementation; I have once done this, and it is possible, but it does not seem to be common (although I think maybe it should be done more).
Another thing about IRC is that it can be used without any kind of special software (although software specifically for IRC is still useful; for one thing, if you do not have a IRC client then you must manually respond to pings). It isn't too complicated; Matrix and Discord and so on are too complicated.
1. Use nickserv and chanserv? This is solved problem.
2. This is also a solved problem, there are bots that log everything on the channel and then you can read/search through channel history from web interface. But mostly this is not needed as you can just spin znc for whole your team.
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:
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 >
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.
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.
The issue with the "long message" thing is not pastes; it's that Matrix is misconfigured by default. When a user types a short but multi-line message, Matrix forces IRC users to click the link to see it, whereas sending multiple messages to IRC would be better. Or the beginning of the message, then the link, so at least we know if we're interested in the content.
I have seen a user who had half their messages replaced by a link, that was unreadable.
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.
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.
As a user of non-English languages, this is not really a problem in practice. We settled on UTF-8 years ago. My second language is pratically the worst case for bumping up against these limits and I never have an issue with them.
I remember when this was a significant problem but with the rise of UTF-8 it is less so (even if that is strictly against the letter of the spec, it works fine in practice). Are there languages where the 510 bytes per message are a significant limitation?
Don't most IRC clients nowadays query the max line length on connect (the capabilities output) and then just split up one message across multiple lines if you cross that limit? I haven't had to think about line length since the 90s.
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.
For what it's worth, that's not the intention on freenode's side - we want to sand off some of the rough edges. As an example, it would be nice to have a common flow for speaking to services.
Once we have some sensible way, then clients can sensibly opt to pop a dialog for new users allowing them to register an account with nickserv without having to fiddle away in a query.
Tangentially, blog posts peppered with Tumblr-style gifs is the worst thing when trying to read the content. Thankfully it seems to be a trend that is dying off, but I don't understand how people read text without being distracted by the bright and bouncy gifs sandwiching it.
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.
I used to run a server on Dalnet (then later on Espernet). Good times; nobody knew I was 15 so I learned a ton about programming from some smart people
As an aside since you brought up Undernet: Their CService website[1] has been down for weeks now. As far as I know, that's the only way to even register with X. I'm not sure if this is being worked around, somehow, or if UnderNet is just being left to die.
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.
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.
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.
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
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
For example, how well would irc work on mobile? Keeping logs requires a bot usually on irc as well.
For mobile, I had a bouncer setup that would keep me up to date whenever someone would message or mention me. I could pull up AndChat and connect right up to all of my channels, I was never actually offline. I had an icon on my taskbar that would connect me to my VPN and pull up irssi. I see now that there is a cloud client for mobile called "IRC Cloud", it sounds like a one step setup kind of bouncer for someone that doesn't have an always online machine to run a bouncer on.
I really do miss using IRC all the time. My favorite server got taken down and I never bothered to find out where everyone ran off to.
This reminds me of what Apple does to the SMS/MMS ecosystem.
MUDs face a similar set of issues. Some new MUD frameworks skip over these by ignoring telnet and going HTML/JS.
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 can 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.
Something like:
%M!i=//shrt.url/j3f87h38f;t=fr,bb;a=Kitten Mittens!
Finally, there is an elegant, comfortable mitten for cats.
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 "This is some %M!t=fr,b!text!." 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.
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.
Character limits are silly and should be removed - enforce them with a moderation bot if you really have to.
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.
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 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.)
Well, the the article pointed out one way... Have a community somewhat gated by the need for technical proficiency, and have a bigger, shinier, "popcorn internet" alternative (facebook) to bait the normies away from it. For example, suckless programs are configured by compiling them from source. This is for several reasons, but one explicit one is that it keeps away less technical users, keeping the userbase "small and elite".
The eternal september happened when the manswarm flooded in; you can't bail out the flood, but it'll drain to a lower-common-denominator cesspool if one is available, and you might be able to build a high enough tower to stay above the waterline.
[+] [-] maeln|6 years ago|reply
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).
2. No offline history: You have to have a client/bouncer running 24/24 if you want history.
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).
Also, nowadays we should consider end-to-end encryption standard.
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 ...
[+] [-] glacials|6 years ago|reply
If it's easy to get history people will assume everyone is reading what they're typing. This would make people feel obligated to play catch-up every time they miss some messages due to being AFK or in the zone.
By making history hard to obtain, IRC simulates real-world conversation -- you're either in the room or you're not.
[+] [-] swebs|6 years ago|reply
https://github.com/ircv3/ircv3-specifications/milestone/4/
[+] [-] asveikau|6 years ago|reply
I would say it's even worse than this. Even if you attempt to have a client 24/7, the lack of an acknowledgement and re-transmit on lack of acknowledgement means that if you have any hiccup that causes you to need to reset the TCP connection, you can drop messages.
[+] [-] welterde|6 years ago|reply
That's not really an issue of IRC itself, but the IRC network you are using.
Running your own IRC server would solve that issue - ngircd for instance supports authentication using PAM or inspircd can directly perform authentication against either LDAP or a SQL database.
And doesn't IRCv3 SASL authentication + only allowing registered users into the channel pretty much solve the issue as well?
[+] [-] Sir_Cmpwn|6 years ago|reply
However, if you're going to run your own IRC server you can also run your own bouncer service. Lots of authentication options exist as well. IRC is totally fine for an org who can stand up a server. It's pretty low-maintenance too.
[+] [-] LinuxBender|6 years ago|reply
[1] - https://thelounge.chat/ https://github.com/thelounge/thelounge
[+] [-] la_barba|6 years ago|reply
[+] [-] zzo38computer|6 years ago|reply
"You have to have a client/bouncer running 24/24 if you want history." Or a logging bot, which some channels have. Another alternative is for the logging to be part of the server implementation; I have once done this, and it is possible, but it does not seem to be common (although I think maybe it should be done more).
Another thing about IRC is that it can be used without any kind of special software (although software specifically for IRC is still useful; for one thing, if you do not have a IRC client then you must manually respond to pings). It isn't too complicated; Matrix and Discord and so on are too complicated.
[+] [-] lossolo|6 years ago|reply
2. This is also a solved problem, there are bots that log everything on the channel and then you can read/search through channel history from web interface. But mostly this is not needed as you can just spin znc for whole your team.
[+] [-] dfabulich|6 years ago|reply
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.
[+] [-] progval|6 years ago|reply
I have seen a user who had half their messages replaced by a link, that was unreadable.
[+] [-] Sir_Cmpwn|6 years ago|reply
https://lists.sr.ht/~sircmpwn/public-inbox/%3Ca6e64b69-c0cf-...
[+] [-] superkuh|6 years ago|reply
[+] [-] slezyr|6 years ago|reply
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.
[+] [-] Sir_Cmpwn|6 years ago|reply
[+] [-] Athas|6 years ago|reply
[+] [-] Karunamon|6 years ago|reply
[+] [-] TagAsDelusion|6 years ago|reply
[deleted]
[+] [-] frou_dh|6 years ago|reply
[+] [-] abstractbeliefs|6 years ago|reply
Once we have some sensible way, then clients can sensibly opt to pop a dialog for new users allowing them to register an account with nickserv without having to fiddle away in a query.
[+] [-] Karunamon|6 years ago|reply
[+] [-] valtism|6 years ago|reply
[+] [-] mdellavo|6 years ago|reply
[+] [-] Pigo|6 years ago|reply
[+] [-] wayoutthere|6 years ago|reply
[+] [-] beefhash|6 years ago|reply
[1] https://cservice.undernet.org/
[+] [-] ircdrone|6 years ago|reply
[+] [-] jnty|6 years ago|reply
[+] [-] fivre|6 years ago|reply
[+] [-] fnord123|6 years ago|reply
IRC is capable. It is a box of nuts and bolts that lets us communicate and build awesome bots and so on.
Bloating the protocol gives us suitability: features that are robust and can federate.
[+] [-] lossolo|6 years ago|reply
This is working well for us, without any issues for years.
[+] [-] anilakar|6 years ago|reply
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.
[+] [-] bluefox|6 years ago|reply
[+] [-] raverbashing|6 years ago|reply
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
For example, how well would irc work on mobile? Keeping logs requires a bot usually on irc as well.
[+] [-] moftz|6 years ago|reply
I really do miss using IRC all the time. My favorite server got taken down and I never bothered to find out where everyone ran off to.
[+] [-] dusted|6 years ago|reply
[+] [-] abathur|6 years ago|reply
MUDs face a similar set of issues. Some new MUD frameworks skip over these by ignoring telnet and going HTML/JS.
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 can 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.
[+] [-] peterwwillis|6 years ago|reply
Something like:
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 "This is some %M!t=fr,b!text!." Harder to read if the client doesn't implement the standard, though.[+] [-] emptyparadise|6 years ago|reply
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.
Character limits are silly and should be removed - enforce them with a moderation bot if you really have to.
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.
[+] [-] chicob|6 years ago|reply
[+] [-] floor_|6 years ago|reply
[+] [-] stcredzero|6 years ago|reply
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.)
[+] [-] antepodius|6 years ago|reply
The eternal september happened when the manswarm flooded in; you can't bail out the flood, but it'll drain to a lower-common-denominator cesspool if one is available, and you might be able to build a high enough tower to stay above the waterline.
[+] [-] ohithereyou|6 years ago|reply