Hacker News Reader

Comment by subhro | Hacker News Reader

I am invariably going to see in the world of Slack, "IRC, why don't you die already".

No, IRC is not going to die. FreeNode is alive and well. And while you busy slamming and wishing death of IRC, just check the memory usage of your Slack client.

View on HN

How does the memory usage of my Slack clients in any way impact the utility of the tool? Private and public communities that are active, relevant, and directly impact my livelihood are on Slack, so I'm also on Slack.

I'm also on IRC, Discord, and Telegram.

This isn't a zero-sum game.

I'm on all of them. IRC is by far my favorite.

Kind of like HN. When someone is commenting on HN I automatically have more interest than eg Facebook vs. Twitter as the primitive experience of HN (Which I personally love) filters out a lot of "noise".

There's great communities out there on IRC.

Just head to #postgres on freenode and see how helpful they are over there.

Because communication should not be expensive.

The problem is that those communities chose to use Slack. And now they're locked in to a proprietary protocol controlled by a single company with perverse incentives for censorship.

In prior years those communities would've chosen IRC. But nowdays everything has to be pretty hand hold your hand for you (ie, host your images, assume you know nothing of how to participate on the 'net by yourself).

It is a zero-sum game. And Slack has done the embrace, they done the extend, and they've started the extinguish (by cutting off IRC bridges).

Slack is perfect for organizations, whereas IRC is not. And no, we're not locked into anything.

> Slack is perfect for organizations, whereas IRC is not.

Why not? Organizations can host their own IRC server(s). Won't that be better than relying on a third-party's services?

And if needed, they can write their own bots, clients, or even their own specific extensions to the protocol.

Because the last thing organizations eant to do is host their own infra for a chat, implement their own search for a chat, re-implement the bits, the hooks, the integrations for a chat etc.?

Hosting things on their own infrastructure is very popular for large companies. They tend to take security a lot more serious that the average startup.

True and that's why hosted services focus a lot of effort on compliance.

https://slack.com/security

Listen, you want to convince my boss to spend more on the infra. For in house chat w/ drag and drop file hosting, and boost my pay for now having responsibility to manage that, be my guest :)

> Slack is perfect for organizations, whereas IRC is not. How so?

> And no, we're not locked into anything. How so?

I wish there was a way to ignore certain users / bots, this is such a pain for me, it makes slack too spammy and noisy for me so I only ever read private messages.

Is there a reason IRC couldn't look like slack to the user?

kiwiirc is an opensource webUI IRC client (demo at https://kiwiirc.com/). To my untrained eye it looks slack-ish, but not being a slack-native I'm not really sure what Slack's draw is and whether its something webUI clients for IRC can't do.

Wow, that is pretty darn nice for an IRC client!

The UI is the easiest thing to fix and as you have shown already has been for some time. What separates IRC and the rest is all the features you would expect by default in a messenger of the 21st century:

- history

- with search

- logins

- simple bots

- automatic content fetching (wiki/youtube Links, pics and gifs)

- file transfers that just work

- image pasting

- message editing

And probably others. Yes, those features exist in one way or another in IRC. The point is not whether you can or not; the point is how much time and energy do I want to spend to install and maintain those. I may have had the patience to do it a few years back, but I value other things now.

To many, not having such features on IRC is a bonus.

As a sidebar, from what I can tell the term "bot" for an automated agent accessible through chat originated on IRC.

For sure, credit where it's due. However IRC doesn't beat the ease of installation that Slack providers for bots.

There's not, and there are services like https://www.irccloud.com/ that "slackify" IRC so you don't have to deal with ZNC, making your logs searchable,...

IRC can't ever have authentication, because most clients won't support it. You can't have conversations that rely on rich text, code blocks with syntax highlighting, embedded images, or web previews: these things are possible (in some cases there's more than one way of doing them) but some users will always be using clients that don't support them, and will regard you as the problem if you try to create an expectation that clients should support those things. In turn this makes useful integrations hard: you can have a bot that sends an alert message that heap usage is high on your server, but it's not going to be able to include a graph. IRC can't ever have server-side history and synchronise read status between devices; you can run another server that does that for you (whether that be IRCCloud, ZNC or something else), but at that point you're not actually using IRC, you're using that server's protocol.

"Most" important clients support SASL authentication already.

Sure. But good luck persuading a network to go authenticated-only, or even configuring your private server that way. It's not impossible but it's very much not the culture and not where the documentation/support will guide you.

Having to share Gists instead of inlining code blocks, and (of less importance) reaction gifs, was a huge non-starter.

Irc is all but dead. I see less and less places where it is used. In the same way NNTP is dead as a doornail and completely irrelevant. Last time I saw that used for something else than filesharing was something like 10 years ago. The same place also used IRC.

Both failed to modernize or keep up with progress. The only places where this stuff is at all still used/tolerated is places where the average age is well above forty and where the audience is engineers only. Most millennials that I work with don't even know what this stuff is because they simply never encountered anything where this is still in use. The ones that do tend to be male and heavily involved with OSS. It's a somewhat elitist thing at this point.

People seem to like to hate slack and similar solutions. The OSS way to deal with stuff like this is to build something better and not get too nostalgic about decades old stuff that did not keep up with a changing world.

Here are the design goals for a modern team chat solution: - It must be stupidly easy to create a private team. Think minutes. This is not something you put an engineer on either. That would be a waste of time/resources. - There must be zero admin overhead. This is the first thing you do in a new project. SAAS is the way to go here for most places; sign up, click, click done. There's absolutely no excuse to waste any time setting up software, servers, and committing to managing that for the vast majority of teams. - It has to be inclusive. Anywone should be able to jump in. Especially non technical people. Like your manager, designers, users, etc. - It has to have mobile apps that are usable and fully featured.

IRC may be elitist but that can be an advantage. For me it is the place where I feel most confortable to have a social chat with strangers.

(Note: there is IRCv3 and irc cloud both of which bring quite a lot of Slack features into IRC)

My problem with Slack is that while it's much more advanced client it still doesn't feel native, is slow and often bloated. The only thing I miss is markdown, sometimes a bit of formatting is vital to getting the message across.

I like slack quite a bit, but it's not designed to be a replacement for general use case of IRC - it focuses on specific use cases and can be manhandled into other use cases with a lot of pain towards the users.

matrix.org/riot.im seems like a more sensible alternative to IRC - but their systems are overloaded and slow - multi second latency is the norm.

The speed has gotten better recently. It usually sends messages in under 1 second. The UI is still a little laggy when switching tabs but everything is slowly getting more polished and faster.

Some time ago I tried to start a federated homeserver, connected to it and joined the main matrix channel (at the matrix server). Thirty seconds later (IIRC) my client (riot) gave up on the attempt. Nothing showed in the channel. I was told the servers (synapse) were syncing the required information. I checked the logs and, true, a lot of stuff was being sent back and forth.

One hour later, a lot of stuff was still being sent back and forth. I still could not join the channel, and there was still no user-friendly feedback on the failure.

These are fundamental flaws in usability and design that really need to be addressed before the system can gain more widespread acceptance. Have they since been corrected, or have improvements been made to mitigate them?

They are also working on a new server written in Go instead of Python which will hopefully make it faster

I'd blame it on using python to implement the server...

Yes, sure, good for a PoC, but there are reasons ejabberd exists.

Reply on news.ycombinator.com