^ This. You get people who will scoff IRC for its simplicity, but ultimately the up-time is near 100%. I've communicated on it effectively all the way for to a 5kB/s internet connection and it was still quite responsive.
A similar story using Jazz RTC - it used to go down every week or two weeks or so. It was so bad that we had quick dial to their call center. The joke was, we used to switch over to a Raspberry Pi hosted locally in the office running a Git Server - and there was zero downtime on that.
Just a small bit of polite anecdata, but I've fled IRC partly due to some pretty extreme quality-of-service problems - and these were on the major servers and communities that were really the only raison d'etre for using it in the first place - things like Freenode and stuff.
Basically we had a lot of cases of silent failure where messages would completely fail to go through, and this led to some pretty nasty social awkwardness, because there was no indication the service wasn't being 100% reliable. I only ever discovered it after several years, when I had a bouncer logged in from a rather different network address, and it was pretty terrifying how much was getting dropped (sometimes up to 10% of messages - although usually it was "periodic" failures where a whole conversation would essentially be dead for one side. I observed this over several months, and it was just mindblowing.
It was the silent failure that was the most insidious thing - there was absolutely no indication things weren't working perfectly, and it was only after we discovered this that we had the horrible realization that all of those communication problems we had in the past were not because individual "people" were bad communicators (or were ignoring you, being rude, etc), but because they genuinely weren't receiving entire paragraphs of text. At random, with no indication anything was dropped.
There are a lot of other extreme frustrations we had with IRC, but this "hidden QoS problem" was the last straw. A lot of the work we were trying to coordinate on it (gamedev stuff) involves more than just text, and just trying to share images across the thing constantly felt like being a second-class citizen (manually uploading something to an FTP when even AIM/MSN could transfer stuff no problem with a copy-paste). The fact that I was forced to use it for over a decade ... I've lost thousands of manhours of my life fighting with it when almost any modern tech stack would have avoiding those particular wastes of time, and that's just something I can't forgive. As irrational as it may be to do so - I can't help but hate it. :(
I run an IRC network (this one: ircs://irc.darkscience.net/darkscience) and there are shortcomings with the protocol for sure.
I've been a staunch advocate for IRC for a while, but the truth of it is that there's nothing built-in for reliability. It assumes reliability from TCP.
If the TCP connection is interrupted, you will be disconnected.
If a route on the internet changes, you will start losing incoming and outgoing traffic; and you will be kicked from the server with a ping timeout. Losing messages shouldn't be possible without a route change on the internet that drops state, but I suppose if there is a leaky bucket style buffer cache somewhere in the pipeline it could happen?
In a similar vein; mattermost, when I ran it, would deliver messages out of order or not at all- I believe this was caused by nginx and a limited amount of buffer caches.
I suspect that the reason slack forces you to use their client is because they're working around protocol limitations like this with retry logic, because I've had messages not delivered with programs like wee_slack or my python bot (which thinks it delivered the message).
Anyway, if you want a more reliable connection for IRC there is RobustIRC which alters the protocol to be more reliable. Also ircv3 extensions largely attempt to solve issues inherent with relying solely on tcp.
Sounds like your client wasn't configured to send periodic PINGs. Usually you set your client to send a PING every 30-60s, and disconnect if there is no server PONG for two to four times the ping interval. That way you have an upper bound on what messages from you may not have reached the server. (IRC is over TCP, so if a server sends a PONG for a PING, then every message you sent before that PING has reached the server.)
This is unlikely to be the case. Almost all servers out there require fairly frequent ping/pongs and if your client doesn't work right it'll just be entirely unusable (like "disconnect every 5 minutes")
What they typically require is a message of some sort sent regularly from the client, and if they haven't received anything in a while, they'll send a PING to elicit a response from the client (if it's still alive). Most servers don't even check that the PONG matches the PING they sent, they're just happy to get something back before the timeout, although there are servers that send a cookie in a PING at connect time that they require to be reflected back correctly as a countermeasure for certain kinds of proxy abuse.
For example, EPIC is one of the oldest clients and it doesn't send its own PING messages unless scripted to do so, and it works fine.
Dropping messages is something that should notify you - in the raw protocol this is entirely possible, so it's just something that needs to be added to the client.
The problem of adding files is something that it would be nice to solve, I think in general the IRC servers themselves wouldn't want to potentially sacrifice the ability to handle text whilst being overloaded with attachments. It feels like something that could be solved with a third party server and a client that supports it, with a short-ish TTL to keep the server freed up. Receiving side it would simply be a case of opening a link or deciding if the content can be displayed inline.
I quite like not being available when I'm offline. I don't want to logon to have a quadrillion messages to read back through - most out of date and don't concern me. We have email for this kind of thing.
Things are starting to sound to me like if there was an authenticated HTTP “endpoint” that juuust echo $line >> www-root/channel/latest.log, then that could replace ~80% of all intents and purposes of Slack and IRC and Wiki with million-fold resource savings...
We'd just made the transition from local hosted HipChat over to Slack about a month before a _big_ outage occurred. The team responsible for the internal tools got told by management to do some herculean efforts to get hipchat temporarily resurrected.
I logged in to my desktop machine, and had IRC up and running in under 5 minutes and had details out to the team ready to use it should an emergency strike. It's _really_ simple to spin up an IRC server for such purposes. Just about the time the Slack outage was over, the HipChat server was back and working again... :) (there's a lot of reasons why it took so long, and it wasn't really Atlassian's fault)
It genuinely is impressive. The protocol itself is so simple that building something like a bot to write the results of builds is a job that can easily be done in a day (assuming you're completely working from scratch, i.e. pushing bytes over sockets).
There are quite a few clients that even support encryption, so it's not even necessarily insecure either.
5 kilobit per second should be fine for IRC. A typical PRIVMSG command is what, 200 bytes or so, which gives space for three PRIVMSGs in a second. IRC doesn't compress, but it's also not particularly wasteful with bandwidth.
I meant 5 kilo bytes. Of course that speed is screamingly fast for IRC, but for most of the internet you're left with a completely unusable experience. Try loading Slack on a 5kB connection for example and post back your results in a week! :-)
Lets be real though, nobody actually enjoyed dialup speeds. Sure, we were lucky we had the internet at all but when cable and DSL came around it was a breath of fresh air.
I don't miss the speed, but I miss what the speed enforced. Pages were lighter and less wasteful with resources. These days you have pages that will not load without JS enabled, which is sometimes 10x or 100x the actual content it's displaying. That's not to mention images - people happily throw in a 1MB image, because why not? A 10MB gif to replaces a 1MB video, because why not?
Of course there are still people in remote areas, poorer Countries, low-signal zones, etc, who actually do have to deal with this daily. I remember reading a while back how Youtube and Facebook were completely unusable for some users because of this - not because of the actual content they are delivering.
My old laptop with win 7 cant run youtube 144p (anymore). It just freezes up. If I download the videos in lubuntu, vlc plays the 720p but 480p is all I need. There is clearly nothing wrong with the hardware.
When downloading files, there was a lot of waiting involved, but if you were dealing with email without attachments, usenet, IRC, and some of the older chat platforms like ICQ, AIM, MSN messenger, yahoo messenger, etc. the lack of speed wasn't really noticable.
These days, most websites and online platforms like Slack won't work at dial-up speeds.
Usenet could take quite a while to download your messages. All text websites and IRC were reasonable by the time of 33.6kbaud modems, but even by 1995 most websites had some graphics to download which were always painful. It only got slower from there as more was added each year.
This episode of computer chronicles may remind you of the joy and horror of that time period. Note that most of these people are actually on corporate networks not dialing in... and its still horrendously slow.
A similar story using Jazz RTC - it used to go down every week or two weeks or so. It was so bad that we had quick dial to their call center. The joke was, we used to switch over to a Raspberry Pi hosted locally in the office running a Git Server - and there was zero downtime on that.