It's strange, and there isn't much I would say I could do personally. But I'll keep my server going as long as I physically can, out of stubbornness if not anything else.
- We don't use much cloud technology at present. That means we run our own DNS nameservers (using PowerDNS and a single MySQL node - AXFR and slave nameservers give us redundancy ). We implement Let's Encrypt renewals on top of this using the DNS challenge and have some custom software to securely push certificates to the IRC servers. This keeps costs down.
- We've replaced our old Iris webchat with The Lounge in public mode, which is fully containerised.
- We have some additional infrastructure for staff: our LDAP directory, an IdP which runs on top and provides SAML & OIDC auth, Git for code and some internal web services for pooling/depooling servers and monitoring.
- Some of the staff have written services and IRCd modules to help control spam and support connection limit exemptions (for e.g. bouncers).
 This allowed us to continue operating with no user-visible impact when we had a hardware failure on the primary DNS box.
I've come to the conclusion that trying to get the irc protocol to handle this is a dead end. A better solution would be to make the server handle multiple protocols. I'm using quassel for over a year now, and it makes irc usable from mobile. It does so by being split into a core and a GUI, so basically like a bouncer, but the protocol between them is designed from scratch, to handle connection drops and even connecting with multiple quassel clients to a single core while syncing up everything properly.
Now the big question would be if it were feasible to support the quassel protocol directly on the irc server, in parallel to irc. This way the hardcore irc fans can keep using it the way they always did, while at the same time making it easy for the kids these days to get started, by not having to set up a quassel core somewhere first. Just grab the app and go.
- It's a PWA, so I can add it to my homescreen on Android just like any other native app (and I find the UX better than most native Android IRC clients).
- It supports Web Push notifications, so I find out when I've been mentioned, even without the client running locally.
- It remembers and restores state across restarts.
...and it turns out that's basically all I wanted. I wonder if the network hosting its own instance of such a capable client would be enough for new users to get going?
This is what we do on EsperNet (https://webchat.esper.net/), for what it's worth - using a forked version of The Lounge with some minor changes. It works reasonably well, but we do have to run it in public mode which limits some of the advantages (e.g. the bouncer-like behaviour).
With that said, it's a well made application and is a big improvement upon CGI:IRC and Iris. xPaw and astorije are great, too.
You can plug Glowing Bear into it too, if you want a web interface.
Shameless plug for anyone who just wants their own IRCD: https://github.com/LukeB42/Psyrcd
I wasn't intended to compare IRC to Slack but since you've started us down this rabbit hole: I'd take IRC over Slack any day. Sure Slack is more "modern" and it can - in theory - do anything IRC can do. However IRC is more easily extendible and in a more versatile way. To be honest there's nothing Slack does that you couldn't also do in IRC - albeit some features might require a more modern IRC client than the terminal ones us geeks often harp on about (disclaimer: I've written tools for both IRC and Slack).
The problem with IRC faces isn't a technological one - it's just a mixture of NIH (not invented here) syndrome and capitalists wanting to make money from reinventing public domain tools as proprietary solutions with expensive subscriptions. Not that I have a problem with people wanting to make money - quite the opposite in fact - but I do take issue with people who say "this can't be done in X which is why Y exists" when the real reason is financially motivated rather than any technological shortcoming.
While I loved using IRC 10-15 years ago, the user experience is simply terrible by our standards today (and adding emoji reactions isn't going to solve that imo).
The terrible user experience of slack and discord is why I started using IRC even more. emoji, images, link previews, and the like all lead to annoying/awful spam. Instead of a conversation you get a stream on memes and image macros along with link and twitter spam. I find it derails the conversation and clutters the screen. Nothing less fun than trying to have a conversation and some idiot is posting "related" image macros flooding the chat with garbage.
The bottom line is I want to talk to someone using text. IRC does exactly that.
I have experienced that to a certain extent on Matrix, but only in certain rooms that permit it. They are not usually #some_project but rather general channels like #linux
What I have found good is code sharing, (nothing a pastebin can't solve, except for the fact if it's a publicly logged channel the link may not work in the future). I only tend to hang out in technical related rooms.
> I find it derails the conversation and clutters the screen. Nothing less fun than trying to have a conversation and some idiot is posting "related" image macros flooding the chat with garbage.
> The bottom line is I want to talk to someone using text. IRC does exactly that.
I find the same with mailing lists vs bulletin boards. I think the barrier to a certain extent means people that have something worth adding will be bothered. A bit like this place. Imagine how HN would be if it was like 90% of Reddit these days shivers.
aka Matrix, (Riot is the main client) is a good one because it is decentralized and federated. This means there can be many servers and they can all be linked up. Additionally IRC can be be bridged among other things
This is completely unnecessary (to say nothing of how MySQL silently corrupts data): PowerDNS can be configured for regular AXFR's between servers and that works exactly as one would expect, irrespective of what the back-end storage engine is.
The most effective, simplest, robust and therefore cheapest way to run PowerDNS is with the SQLite back-end as the storage engine and AXFR's between master and the slaves configured (PowerDNS BV run it with SQLite themselves); this inter-database replication is nonsense, just asking for trouble due to fragility and complexity. When I see such crazy unnecessarily complex solutions, I often wonder: what the hell went through those people's minds? Aren't they able to reason it out logically? What the hell were they thinking and why the hell were they thinking it??? This solution is so irrational, that it has to be ignorance.
With every answer you raise more questions than you answer.