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.
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.
> connect time that they require to be reflected back
> correctly as a countermeasure for certain kinds of proxy
> abuse.
That tripped me up when writing an IRC bot - it worked on many servers but failed on one particular server that sent the PING cookies.
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.
There is an IRCv3 extension to get an acknowledgement the server received your message: https://ircv3.net/specs/extensions/echo-message-3.2
> It feels like something that could be solved with a third party server and a client that supports it
Some IRC clients, such as IRCCloud or the Matrix bridge already do this.
Or no wait, we need to invent a kind of paper that you can write on with a pen and have it magically mirrored on n similar paper documents.
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. :(