Ask HN: What's Wrong with IRC? | Hacker News Reader

Ask HN: What's Wrong with IRC?

50 pointsimgabe91 comments

With the proliferation of chat apps like Slack, Discord, Teams, etc. why don't more companies just set up their own IRC server?

The pricing for Slack seems insane for something that was essentially a solved problem 30 years ago.

Admittedly, I haven't used IRC much and I know the UI/UX isn't the best, but that could probably be fixed pretty easily and tacked on to the existing messaging infrastructure?

View on HN

If all you want is text chat with no shared history, sure IRC is fine. But think about these features that the chat apps bring:

Search: half-remember some conversation from months/years ago? It's right there, in the app.

Persistent history: onboarding a new employee? All of the company's past communication is there to browse and search (see above point).

Inline file attachments: need to share a small file or a screenshot with someone? Drag it into the app and they can get it at their leisure. No need to mess around with DCC send or uploading to Google Drive and sharing a link, it's right there.

All of these could be solved with IRC (in fact, Slack was initially built around IRC) but they require extra infrastructure and tooling and development to make it seamless, and that takes extra development and hosting costs.

Our group runs The Lounge, and at this point only a couple people use standalone clients any more (and one person with a Matrix bridge). It gives you all the above (except perhaps the company wide persistent history, I'm not sure) and it's still IRC.

The last time I looked at The Lounge, the installation and configuration seemed pretty involved, not to mention ongoing maintenance.

Has this improved recently?

> Search: half-remember some conversation from months/years ago? It's right there, in the app.

I've never had to do that and Discord or Slack aren't the right places for that anyway they should go in some knowledge repository like a wiki.

Slack's pretty bad as an information repository. How do you know there hasn't been a subsequent discussion that updated the conclusion of a particular chat? Search isn't particularly consistent in how it serves up results.

By all means chat asynchronously to decide on something, but then get it into a wiki. I actually like Slack's auto-expiry for free accounts, as it incentivizes the mindset - if you want to keep the information around, boil it down into a readable form and put it in the right place in the company's documentation.

Agreed!

Sure, this a correct mindset, and an obvious one for people who build and maintain information repositories professionally, but at an average company with hundreds or thousands of people, it's a losing battle to enforce. Paying for Slack and having the ability to find information in conversations that should have been documented but were not is valuable in practice.

This is the wrong point of view for many (probably most) workplaces, where the officially "maintained" information repositories are often very out of date and where the alternatives are usually: 1) Find a conversation you can at least start from, or 2) Get someone to give you a brain dump now.

Sure, a curated, well-maintained repository could be better. It also requires work time that usually doesn't get budgeted for. Slack is a band-aid, but a useful one.

Being able to say, "I know this issue came up a few months ago, let me see what we decided back then" -- and being able to back that up with a link -- is a superpower. Not everything that comes up in discussions gets documented.

Exactly the opposite of my long-term experience – Slack search is good enough that it’s my first port of call for information, and regularly finds me the right answer. It’s a better information repository in practice than any other system I’ve used at work. That is kind of sad, of course I think “proper” documentation is better, but such is life.

>Search: half-remember some conversation from months/years ago? It's right there, in the app. Persistent history: onboarding a new employee? All of the company's past communication is there to browse and search (see above point).

This is where Slack really squeezes companies. Our (barely) medium sized org has a seven figure Slack bill, and they only support 1 year of history. Going beyond that becomes absurdly expensive. It would be absolutely pricless for me to be able to go back and read older convos. But it's somehow impossible to do without spending millions of dollars. Absolutely insane.

Where do see the one year history limit? Any paid plan has unlimited history, from what I see.

The numbers you see on a website are very different from what corporate pays. Everything is negotiated through sales.

Being able to search in the past for a half-remembered conversation sounds great until you have idiotic, asinine corporate data retention policies that require anything beyond 90 days to be deleted anyway, for some bullshit reason like being open to litigation or whatever and that being subject to discovery.

Then that's implemented with no warning to be able to migrate important info out into a wiki or other documentation. So in the end, no better than IRC really, but I get it, not a Slack problem, but allowing that whiplash at a click of a button doesn't help. Slack seems to help paper over deep cultural problems in a way that makes it all colorful and squishy.

But as other seem to agree, it's pretty bad at keeping anything organized like you want to be as an info repo, there are tools that are geared toward that specifically. Don't crowbar one into the other.

> Being able to search in the past for a half-remembered conversation sounds great until you have idiotic, asinine corporate data retention policies that require anything beyond 90 days to be deleted anyway, for some bullshit reason like being open to litigation or whatever and that being subject to discovery.

Well that just doesn't sound legal. In fact, I'm pretty sure Google just got the book thrown at them for this. [1]

[1] https://www.cnn.com/2023/03/29/tech/judge-google-deleted-cha...

That might not be the official reason, in Europe you can argue you sometimes discuss customer info and thus it needs to be deleted once no longer relevant.

Of course stating you're doing it for the purpose of destroying evidence is stupid.

dude, we work at the same company...

The company I work for has the same chat retention policy, but despite that, even being able to go back just 90 days has proven very useful!

> What's Wrong with IRC?

• No support for server-side history, and all that comes with that (usable mobile clients, offline messaging and push notifications to mobile clients, persistent presence in channels, search, editing/deleting messages, auditability, etc). Bouncers are a poor solution, as they aren't part of the IRC server and integrate awkwardly, if at all, with clients.

• No support for attachments. (DCC SEND isn't a solution; not only does it require direct IPv4 connection between users, but it doesn't work at all in groups.)

• Poor user authentication. Connection-time auth solutions like SASL are poorly supported; after-connection auth like NickServ is hokey. Support for federated (non-password) authentication is practically nonexistent.

• Short - and unpredictable - message length limits (typically around 500 bytes).

• Crude permissions system.

> No support for server-side history

That's a feature, not a bug. If you want conversations to be searchable, use email. Instant messaging is like phone calls or in person communication: transient (if potentially async).

> No support for attachments.

Good, no silly gifs cluttering up the chat. But this is a feature that's easily added.

> Poor user authentication

This one probably has the most merit. But probably easy to implement with a few server tweaks.

> Short - and unpredictable - message length limits

Brevity is a feature. It's a chat, no one wants to listen to a monologue in conversation. The unpredictability is a bit annoying.

> Crude permissions system

How fine grained do you need it to be? Read and write access for channels exist. There are plenty of bots which can grant additional permissions based on whatever criteria you set out.

But hey, I'm also that stubborn bastard who still likes text-only email.

> [server-side history] That's a feature, not a bug.

Whatever your personal feelings on message history are, people and businesses need functionality like usable mobile clients they can receive messages in without keeping the client open continuously, or the ability for administrators to delete messages which have been sent by other users. IRC doesn't, and cannot, provide those features.

> [no attachments] Good, no silly gifs cluttering up the chat.

Also means it's difficult to discuss inherently audiovisual content like graphical designs, or to transfer files -- all things that come up in business contexts.

> [permissions] How fine grained do you need it to be?

It's not that the permissions aren't fine-grained so much as that the entire system is crudely designed. Users' permissions in a channel are mostly tied to their presence in the channel; if you leave and rejoin (or disconnect and reconnect to IRC), any permissions are lost and have to be regranted by another user in the channel. Bans are tied to nicknames (which are volatile) or connection hostnames (which are differently volatile). Invite-only channels use passwords. And so on. It's a mess.

Yes, you can add bots to handle some of that for you -- but having to rely on bolt-on components for basic functionality is a sign of a badly designed service.

> people and businesses need functionality like usable mobile clients they can receive messages in without keeping the client open continuously

Do they really, though? If Jim isn't at his desk and I still need to talk to him, I can just send him an email, or try again later. That is the part of communication that IRC excels at: fleeting conversations.

IRC chat history is old-school FOMO.

> Do they really, though?

Yes. Usable mobile clients are table stakes for a modern messaging service. Caveats like "if you put your phone down for a few minutes you fall offline and any messages sent during that time are lost to you forever" are, quite simply, not acceptable.

It's not the year 2000 anymore. Not everyone is sitting at a desk in front of their computer eight hours a day. Software needs to adapt.

I do not know why you were down voted, but I fully agree with you.

I do not want to see pictures in IRC at all, you want pictures, movies etc, got to one of the many pointy-clicky apps. Or you can PM and send the pic to the person who wants it via email.

No history, good for me, but you want history enable logging in your client.

User authentication - maybe a bit harder for new people, but you also have the option of turning on encryption if you want.

One missing item, with cloaking, you can have anonymity which is lacking in all the other "apps".

I see no need to change IRC at all, and I think the Freenode "owner" tried to change it and a revolt happened. Just about everyone moved to Libera chat.

The solution to these issues isn't to simply not have those features, but to make it possible to toggle those features on/off.

Ergo (formerly Oragono) covers some of that. I can't say if it provides a server based search.

> https://ergo.chat/about - Combining the features of an ircd, a services framework, and a bouncer (integrated account management, history storage, and bouncer functionality).

Putting it into SASL-only mode is a couple lines in the config. I'm not sure if you meant poorly supported in clients.

Are there any clients that don't split long messages when sending?

Upvoted, this looks better than most IRC solutions I've seen.

"I know the UI/UX isn't the best, but that could probably be fixed pretty easily" is doing a lot of heavy lifting. Most of the time when you ask "why isn't open source thing more popular" the answer is UI/UX. Impericaly, it is neither easy nor common for open source software to have good enough UI/UX to be adopted by non-technical people.

This is the biggest answer. IRC is in that most terrible of spots where there are too many users with too many different clients to ever universally adopt new features anymore, while being old enough that many desirable new features have been implemented by its non-OSS competitors.

It is not too dissimilar to email, or the whole IPv4/IPv6 debacle.

> why don't more companies just set up their own IRC server?

Why don't you grow your own food? Why don't you just write your own payment processor?

I used to think this way until I started a company with employees. My opinion on the matter changed almost instantaneously.

1. One does not simply set up their own "X". Setting up X takes time and you will also have to manage it, which also takes time (and is harder to anticipate when you are fully responsible for managing it).

2. As someone making decisions on this type of stuff (eg a founder, executive, head of IT, etc), maintaining something like X is a poor use of your time and not something you want to have to even think about. So you'll be paying for it anyway even when it's "free" by having an employee maintain it or sacrificing your own time on it.

3. You may trust yourself to be able to maintain it properly, but if you delegate it to an employee, the math changes. Now you have to hire someone you can trust to do a good job maintaining it and who is willing to do that kind of work. And you need to consider things like "what if that person quits/retires/gets sick" and "what if they get hacked or go rogue" and "what do I do when they go on vacation"?

4. Businesses have a lot more requirements of their communications software than just communications. If an employee loses a device or gets hacked you need to easily revoke access to everything, so you probably want to use SSO/an identity provider to make that easy. If you get sued you need to have a way to do legal discovery.

5. If you run into a bug or make a mistake, and introduce downtime or lose chat history, you just lost a lot of productivity or valuable info - operating things like this reliably is expensive, whereas having a support contract really reduces tail risk/provides peace of mind.

So if your option is to pay someone $10k for something like chat that Just Works (99.99% at least), and you are actually trying to build/operate a business and not just play around, something like $10k for chat can be an amazing deal compared to the true costs of doing it yourself. You pay someone some money and barely think/worry about it anymore, done.

> Why don't you grow your own food? Why don't you just write your own payment processor?

I find that usually if someone says "why don't X _just_ do Y", they haven't really considered what it takes to _just do Y_. Similarly,

> I know the UI/UX isn't the best, but that could probably be fixed pretty easily

could be expanded into 50 points of why exactly it wouldn't be _pretty easy_ to to "fix IRC UI/UX".

Honestly I don't know what answer OP expected here. If it's easy to set up/maintain Slack alternative based on IRC, with fixed UI/UX and appropriate for _most companies_, they should simply start a Slack competition for half the price and rake the profits, I guess

I wish I could upvote this twice. Many people only consider monetary cost as "cost" because their own time is basically free. But when you have to pay for any extra time spent on "fixing" IRC to become business capable, the proposition by Slack and their competitors starts to make a lot more sense. Even if you already have people capable of doing the work, do you want to task expensive employees on replicating something you could easily buy at a lower price or do you want to have them work on something that will actually increase revenue?

People seem to feel that using open protocols for chat is like putting a hand in a toilet. XMPP seems to be mostly used by soliders and police.

Proprietary chat apps on the other hand go bad like cheese. When they start out there is a honeymoon period where they know they have to perfect onboarding because otherwise people won't use it, but once it gets a critical mass they fire the engineers and stop fixing bugs and keeping up with a changing environment.

The story is "want to try a meeting with Zoom?" and people would say "it's got to suck right?" and you'd reply "it works as well as Skype did 10 years ago" and then they try it and say "Wow!" but you know ten years from now it will be legendary that Zoom sucks and there will be something new that people are comparing to what Zoom used to be.

There ought to be a law mandating chat interoperability, Facebook Messenger could actually have a longer shelf life if you could talk with Microsoft Messenger because competition and the threat of exit would keep them on their toes.

I use IRC regularly and will continue to do so, but I’ve changed my opinions in recent years to admit that it is only useful for power users. The spec maintainers went too long without supporting features of competing systems like authentication, history, Threaded discussion, and a whole bunch of other things. Many of these features have been added to v3 of the specification, but it is too little too late. It is absolutely absurd in 2024 to tell somebody to install a bouncer and host it on digital ocean. They are not going to do that, they are going to use Discord. With that being said, I still love IRC unlimited extensibility and simplicity. But I’m a software engineer.

"only useful for power users" is table stakes for avoiding excess noise in any messaging application

IRC is amazing but it's hard to have persistent login, sharing of pics, threads, etc. These days I'd recommend matrix for a non-geeky but self-hosting audience. Definitely not something like discord that constantly tries to datamine the hell out of you.

For IRC I use Quassel which fills in all the missing gaps quite smoothly but it's on the user to set that up. Thus it's not for everyone.

At work we used to have irc servers around though because it allowed us to speak freely without HR constantly looking over our shoulders. But sadly the cybersec team hates these with a passion.

Persistent history (i.e. being able to read messages in a channel from both when you were offline and from before you joined) is pretty important for Slack-like company chats.

That fundamentally doesn't work on IRC, as it's message-oriented (like XMPP, which has some elaborate bolt-ons and hacks to implement history that actually work ok), not history-oriented like e.g. Matrix.

There's no point in overhauling IRC when Matrix is a much more modern alternative that includes E2EE and such things out of the box, no custom extensions required.

Also IRC doesn't store message history, which is kinda a really important thing.

Shell sessions and bouncers sort of alleviate the history issue if that is what you really need. I always thought that not having history was part of the magic of IRC.

That said, all your private messages as well as any messages in public channels can be logged and will persist on your PC until you delete them.

You can't just tell Julie in HR to get a persistent shell session and set up her bouncer.

For Matrix, you can say "go to chat.company.com" and click log in with Google.

> For Matrix, you can say "go to chat.company.com" and click log in with Google.

And half of them logs in with their private Google account.

Usually not as bad as allowing personal GitHub accounts to be added company teams.

Eventually somebody starts wondering who spikeycactusplant4589 is.

Trust me. It’s bad. Real bad. ‘Cause when it’s a startup, there are minimal restrictions. You can share what you want.

You absolutely can tell Julie in HR to log into the company instance of The Lounge or whatever friendly frontend IT set up. Users should no more need to run their own bouncer than their own homeserver.

This assumes that there is actually a friendly frontend meeting the equivalent feature and UI/UX experiences of things like Slack and ignoring the cost of maintaining that service by IT.

Yes, I assume that https://thelounge.chat/ exists. As to cost/maintenance... there are no free lunches. You can pay with your money and your data, or your money and your time. I happen to find the ladder preferable and frankly cheaper than people think.

I'm sure Julie from HR also isn't present for every physical chat at the watercooler, and isn't any worse for wear.

In fact it'll be great for everyone if HR is not present at every watercooler conversation. At most companies we got work done despite company leadership and policy, not because :)

> Shell sessions and bouncers sort of alleviate the history issue

And that's why people don't use IRC

This has all the energy of the infamous response to Dropbox back in the day [0]. "Just set up a client, and a bouncer, and adjust your retention policy in this text file buried three levels deep and make sure you have enough disk space, and...", when at the end Julie in HR just wants to keep an eye on what happened in the #watercooler channel when she's away on vacay.

[0] https://news.ycombinator.com/item?id=9224

Actually, I think my biggest issue with IRC is that at least in the past, it looked like it leaked my IP address to chats, which is a pretty big privacy issue (they can figure out what country/province/national subdivision I live in, and that makes me uncomfortable). While I'm sure Discord or Slack or Teams has my IP address at a company level, at least individuals in a Discord/whatever cannot by default get my IP address.

this has been configurable in at least some IRCds for a very long time, to hide the host. It's been that way from personal experience for at least fifteen years, but it could be longer.

Well, that's awkward. I should have learned that. Unfortunately, it also speaks to the unfriendliness of IRC that I've looked this up before and the answers are always "get a VPN."

Unfortunately cross-device history is table stakes for any messaging application. IRC doesn't stand a chance against any popular app today.

IRC is not mobile-friendly (and I have to regretfully admit we live in a push-notification-requiring sort of world now).

Myself, I needed something IRC-like, which was open-source, and mobile friendly, so I tried Mattermost team server for a few years. What turned me off over time was that it required manual upgrades. I would have preferred something which was a nice, tidy Debian package.

Now I've turned to the prosody XMPP server instead, which is a standard Debian package (and now upgrades itself, if and only if, there are security problems, with Debian's "unattended-upgrades"). It runs on a $5US/month VPS. Setting up all the SSL stuff, and firewalling rules - as it uses multiple ports - did take a few days to figure out!

PS: A similar discussion around merits/demerits of IRC was recently on mastodon here: https://hachyderm.io/@miah/112649146585492861

I made a couple of related comments (WRT prosody, and Mattermost Team server): https://c.im/@sbb/112673859554591548 https://c.im/@sbb/112673727757562126

Plenty of people use IRC on mobile, not sure what you mean by "not friendly"...

One of the former SourceHut developers has worked on a pretty good mobile client: Goguma. https://f-droid.org/packages/fr.emersion.goguma/

Setting up and running IRC requires some time and knowledge most companies don't want to invest in. It's much easier to buy than to build, especially when it's not your core competency.

Slack, etc. pricing is a rounding error for most companies.

I spend time in a coding Discord channel, it's a regular many times a day thing for people to paste 1-10 lines of code. With syntax highlighting. That's not possible on IRC, pasting 10 lines is "spam" and gets you complained at, everyone needs their own syntax highlighter, or the sender needs to bodge uploading to a pastebin site and other people need scripts to fetch them or clicking links waiting for a separate program to open to see them, then they're not inline, the sender can't edit them afterwards.

Emoji.

Search.

Pictures.

Screensharing.

Voice calling.

Video calling.

Web clients which can join video/audio calls.

Smartphone apps.

Push-Notifications.

Colours.

Embedded inline Office365 documents, in the case of Teams.

Meeting invites built-in to Outlook, in the case of Teams.

Click thing in Teams, opens in Edge browser with the Edge sidebar open to the Teams chat place where you clicked, for context.

Email notifications of things said in Teams chats.

Integration with company directory for looking up who people are.

IRC is for people whose reaction to those is to complain or sneer about how they don't want them.

> IRC is for people whose reaction to those is to complain or sneer about how they don't want them.

This is the real reason IRC will never achieve wide adoption. The people who use it actively don't want the features that the people who don't do.

Don't want the features, and feel superior for not wanting those features: https://news.ycombinator.com/item?id=40813886

I see emoji on IRC every day btw :)

I'm sure you do see them, but having encodings consistent between sending client and receiving client isn't part of IRC; RFC 2812 - Internet Relay Chat: Client Protocol[1] says:

    > 2.2 Character codes
    
    >   No specific character set is specified. The protocol is based on a
    >   set of codes which are composed of eight (8) bits, making up an
    >   octet.  Each message may be composed of any number of these octets;
    >   however, some octet values are used for control codes, which act as
    >   message delimiters.
    
    >   Regardless of being an 8-bit protocol, the delimiters and keywords
    >   are such that protocol is mostly usable from US-ASCII terminal and a
    >   telnet connection.

Mojibake from disparate clients is part of the design; people have had to go outside the standard to make undocumented informally specified variation(s) such as "use utf8". Saying IRC is encoding-agnostic passing 8-bit bytes around, is like saying "I see emoji using TCP/IP every day".

(Contrast with HTTP where a client can declare what it accepts in the request headers on a per-request basis, and servers can declare encodings they are sending in the response headers on a per-message basis. Contrast with proprietary Slack where one company codes every client and can make them all behave the same).

[1] https://www.rfc-editor.org/rfc/rfc2812#section-2.2

Interesting, thanks. utf8 appears to work out fine in practice though.

The current IRC specification recommends UTF-8: https://modern.ircdocs.horse/#client-to-server-protocol-stru...

It is also possible for servers to tell clients only UTF-8 is allowed: https://ircv3.net/specs/extensions/utf8-only . This is the default of some server implementations.

I don't think this is specific to chat; pretty much the same question could be asked about any SaaS offering. At the end of the day, rolling your own is at least somewhat of a risk in terms of how much it will cost, how soon it will be ready, the quality of the product being made by your employees who potentially aren't experts in the given domain, etc. In the ideal case, it would probably cost a lot less than paying for service, but you need to weight that by how confident you are in your ability to achieve that, and sometimes a high cost with a known upper bound is going to be more palatable than an unknown cost that's hopefully lower but potentially unbounded.

There are technical issues with running an IRC server and the protocol.

It's the UI/UX you mention that seems to be the bigger blocker.

In my experience IRC was the preferred platform among software developers for a long time. Setting up a persistent shell and bouncer and managing your logs was common and preferred. It was how a good deal of the, small at the time, open source world ran (this is the 90's up through the aughts).

I recall that started to change when Slack and other alternatives started breaking into the market. A newer generation of software developers didn't care for IRC and the UI/UX around it. Open source, open protocols, free (as in freedom) software didn't matter to this generation.

And as management and executives got more interested in micro-managing developers we needed to include non-technical folks into our chat systems... which is where the UI/UX argument struck again: our friends in HR, management, etc couldn't be expected to setup their own irssi + screen client, log rotation, notifiers, etc; writing and hosting custom bots to integrate with systems became a chore and lost art, etc.

Now we have to run multi-gigabyte, resource hogging clients to post memes and emojis. But at least it's easier to administer and get folks on board. At the cost of all your data belongs to Slack I guess.

You do get a lot out of Slack than chat though. Forms, integrations, workflows, huddles, etc. It's a different ballgame from early to modern Slack.

> Admittedly, I haven't used IRC much and I know the UI/UX isn't the best,

I mean, you seem to understand what's wrong. IRC is meaningfully worse to use than Slack/Discord. So people use stuff that's nicer to use.

> but that could probably be fixed pretty easily and tacked on to the existing messaging infrastructure?

If it were easy, it would have already been done. "The UX isn't great" isn't a recent discovery, it's something that's been known for a very long time.

I regularly use two messaging platforms: Discord, and Element. The former is proprietary and the latter is open. Element is meaningfully worse to actually use. And it's still the best Matrix client I personally have used.

> Element is meaningfully worse to actually use. And it's still the best Matrix client I personally have used.

fwiw we’ve spent the last few years fixing this, starting with mobile, and Element X is the result: https://element.io/labs/element-x. it’s more of a whatsapp/imessage/signal replacement rather than a discord replacement right now, but i really hope we fixed the UX this time.

(edit: that said, at this point i’m worried that even if we made Element better than Discord, it would still have its old reputation to shake off, and I’m blanking on projects who have managed that. just like even if someone built a desktop linux env which outperformed macOS, it might have an uphill struggle for adoption.)

That's great! To be honest, I was very impressed with how you all handled the criticism of the website, by the way.

I don't generally use Element on mobile, but I will give Element X a try! Thanks for the pointer.

TBH, I’m surprised to hear Element (X) described like this.

I thought the space that Matrix was intended for was group chat, similar to IRC, Slack, Discord, Mattermost, Zulip, etc.

Now you say that Element X is a replacement for WhatsApp/iMessage/Signal, which to me is a totally different kind of application.

Basically, I see WhatsApp et al as a better way to send SMS (E2EE) or send vacation pics to my family (without broadcasting them on Instagram) whereas if I would want to discuss a tricky PostgreSQL issue (or whatever) I would kind of expect the project to have some kind of presence on IRC, Slack, Discord or similar.

So now I’m curious about the change of course. Would be very interesting to hear the rationale for this.

Matrix is intended for chat of any kind. The 'messenger' featureset (i.e. WhatsApp/iMessage) is basically a subset of the 'Team Collaboration' (i.e. Slack/Discord/Teams) featureset. Historically Element has tried to handle both use cases, but it spread us too thin and we didn't pull it off.

So with Element X, we've very deliberately focused on the Messenger use case at first (also driven by the fact that we have more paying customers asking "i want to run my own decentralised WhatsApp/Signal alternative" than "i want to run my own encrypted Teams alternative") - and it is unrecognisably more polished and focused and usable than normal Element. To quote someone in one of the community Element X rooms a few days ago:

> just downloaded element x from f-droid and wowza it just.. loads instantly? can't believe i now live in the age of element being faster than discord

Once the 'messenger' use case is fully launched (aiming for "end of summer"), we'll then carefully add the team-collaboration features (spaces, threads, etc) back in - and hopefully end up with something which can be used for both.

Yes, the fascinating thing about Matrix is that they have 30+ clients listed on their page of which none (!) implements all the features of the protocol — for instance, there is no client that supports E2E and multiple accounts.

You would think instead of creating more than 30 sub-par clients it would make sense to create one that is actually good.

fluffychat supports both

And what you think, doesn't make any sense, because Matrix is an open protocol. Its like complaining about people making millions of websites, but not actually good ones.

> why don't more companies just set up their own IRC server

> The pricing for Slack

You've answered your own question there. Because "pricing" an open (as in RFC defined) IRC server is significantly more difficult than "pricing" a proprietary protocol.

So the "companies" follow the money, and setup their own proprietary silos.

Of course OP could offer IRC as a service, undercut Slack etc, and make a fortune. Just like this guy could have undercut dropbox

> For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.

https://news.ycombinator.com/item?id=8863

Discord (et. al.)are just better IRC. More options for saving convos, having chat, support for reactions and media, etc. Just does a better job at being IRC than IRC does. Only downside is long term preservation and “openness”. Almost everything is a trade off I suppose.

Nothing? I read these HN link posts from IRC. ##hntop on libera network.

Many s/w projects still maintain support channels on IRC.

The migration to proprietary support mechanisms isolates a number of users. Mozilla in particular is much more difficult to interact with since migrating away from IRC.

I've also worked for a company that ran it's own XMPP chat server. XMPP chat clients allow file attachments, see messages from times when client is disconnected (without a bouncer), integration of voice and video chat, whiteboard, etc. Pretty much everything slack, discord, etc offer.

This question is similar to why do companies use the cloud, when most of the time they could just run a server. My biased opinion: laziness. Mostly the laziness of following fashion instead of the technically superior solution.

I will pay you $5,000 today (metaphorically speaking) if you can give me a today solution on IRC that gives me every feature I care about with slack and works as well as slack for people who have never used IRC.

Caution: That means interoperating with Okta/SAML, and seamless client-side history with administrator-set retention periods (deleted on server and all clients), and the ability to move something from a DM to a private channel to a public channel and vice versa and the hundreds of features that Slack has built because they've had millions and millions of dollars that open source doesn't have.

Businesses have different needs than IRC (or Matrix) provides. It'd be amazing if someone could build a foundation that allowed common open source competition over slack but we can see all the problems with business-focused OSS these days.

As others have said, the UX for IRC is pretty bad, and I say this as an operator of a decently sized network for the last 20 years.

Meaningfully FOSS communities are better served by Zulip or Matrix.

Slack started as a set of features over IRC (at least to a large extent), and was compatible with IRC servers for quite a while. Turns out, when you try to make IRC actually suitable to the environments where users aren't always on (among other deficiencies in it for enterprise use-cases), you end up with something sufficiently customized to no longer be IRC.

You can either lie and say it is (but get called it), try to change what IRC is for everyone else (good luck, the open servers don't want your features and consider lack of history a feature not a bug, but it is a "bug" from an enterprise perspective), or create something new out of the old system. Then you get Slack again.

Or you can make a largely from-scratch system (Discord) that resolves these problems from the start rather than trying to patch over something that doesn't actually do what you need.

Or you can try to make a new protocol (XMPP, Matrix) that tries to resolve these and hope people build compatible clients and servers and don't fork it in a way that breaks compatibility.

The is only 1 reason for me: slack connect.

Whenever I sign up a new customer, they get a slack channel where they can talk with our team. By far the best way to do this is to connect our slacks. With anything else they'd have to log in to another system or download a new client which means it won't happen.

I would love to try any of the other open source improved chat solutions out there. But the network effect, alone, keeps me on a paid plan.

Barriers to use IRC for non-technical people are higher.

Strongly agree that this is a great answer. Anyone who neglects to see the interpersonal persective/psychology of entire demographics of users (considering their needs and wants), focusing only on the technical, is missing a big dimension of the picture here.

Another example of why proprietary options are less desirable:

https://slimsag.com/2024/slack-to-destroy-history-of-free-co...

https://news.ycombinator.com/item?id=40813877

We looked at it, at some point, but why bother when Google Chat came for free in Gsuite?

It really depends on your needs. IRC can work just fine, and all the "problems" become features. Decentralized everything, free choice of clients, extensible via bots, hosted or managed networks are available.

If you wanted to build your own chat thing, maybe base it on XMPP instead.

Integrations and whatnot would be my best guess. But smaller projects and groups still use IRC.

I would wager it is a generational thing also.

IRC doesn't have good mechanism for censorship, shadowbanning, etc.

No good way to mould and conform political speech to what is acceptable.

No good interface for law enforcement.

IRC will be dead quite shortly.

I understand what's wrong with IRC.

I don't understand what was wrong with Jabber.

I see plenty of reasons in the other answers, but I think it boils down to: "it's a different philosophy".

IRC is akin to watercooler conversations: people who are around may hear what you say and they may join the discussion, but they don't have to. People who are not around are not expected to ever hear about the conversation (though a colleague could repeat it to them later).

When you talk to colleagues behind a whiteboard, you don't expect everything that was said to be recorded. At the end of the discussion, if deemed necessary, you take a picture of the whiteboard and/or write a summary that you save in a persistent place (typically you send the summary to the participants by email).

Now, in 2024, people (especially tech-savvy people, in my experience) have a hard time living with "old school" technology. "Why should we use email in 2024? Does IRC still exist, though it was invented before I was born?". The IRC UI/UX could have been improved a ton, but people have a different philosophy now. They expect everything to persist, they want official communications to feel like WhatsApp (or Snapchat or TikTok, depending on the age) interactions. Many people reaching university now don't know what a "file" is on their system: they just access "stuff" through "apps".

IRC fundamentally doesn't work like the modern chat apps that modern people are taught to use. You can't add threads to IRC and still call it IRC, because you will end up talking to people who don't have threads and it will break either your or their UX. You can't add reactions for the same reason, or history (because you will expect them to see all your messages, and they will assume that it is fine to miss most of them).

TL;DR: IRC is great, and I love it. Nothing is wrong with it. It is just not being used because that is not how (most) people interact anymore. It does not explain why modern chat apps seemingly must be poorly-written ElectronJS abominations, though. Probably it's cheaper to develop and users just don't give a damn.

Reply on news.ycombinator.com