[alexandernst]

Because whenever somebody asked for:

* 24/7 presence, the reply was "you can do that with a bouncer"

* backlog, the reply was "you can do that with a bouncer"

* full text search, the reply was "that's up to the client implementation"

* file sharing, the reply was "it's already possible with XDCC"

and so on and so forth.

Basically, it's not that Slack is great, it's because IRC as a whole just refused to adapt to what users actually wanted/needed.

[dijit]

More like nobody bothered to make a decent product that could do all the nice things slack is doing.

(although, that's not technically true since irccloud does all the things you just mentioned)

[rakoo]

> (although, that's not technically true since irccloud does all the things you just mentioned)

Yes but then you're not using IRC, you're using IRCCloud. Its features are independent from the backend that is used; they could switch to Matrix or XMPP or a proprietary protocol for that matter, and the features would still be there. You can't expect the one you talk to to have IRCCloud and tell them "just search in the conversation history, it's there" because the protocol doesn't allow it.

The GP's answer is correct, Slack does a lot of useful things by default. That's why people like installing Ubuntu or even Debian but don't want to take time to setup an Archlinux or a Gentoo anymore: it's fun, but if I just want to do something other than tuning my install I'm not going to consider those distributions.

Now, the question is, does that mean that LFS or any bare distribution "lost" to, say, Fedora ? No, because they are meant for different needs. I'd say it's the same for IRC: it's best suited for people who are not interested in the full history and want to talk to people in a synchronous manner, people for whom text is a more than good enough solution and aren't necessarily interested in binary exchanges, people who like pseudonymity, etc

[dijit]

Weird distinction.

There’s no difference from this over using weechat relay.

[rakoo]

The client -> relay protocol for weechat relay is not the same as the client -> ircccloud protocol for irccloud, and both of those are _not_ IRC

All those clutches exist to support the deficiencies of IRC, which only proves the initial point: IRC in its current form doesn't do enough, and that's why Slack, with all of those features out-of-the-box, "won".

[Spivak]

If you replace IRC with SMTP the story is very different. IRC has a lot of protocol problems but the biggest one was honestly just not having an IMAP equivalent. IRCCloud is just providing the complementary protocol to IRC. Its existence doesn't necessarily mean that IRC is a bad transport protocol.

[theamk]

IRC has no message storage - so not only it has no IMAP, it has no POP3 either.

And IRC is a horrible transport protocol because it handles errors by dropping messages. SMTP has both message-ids and explicit confirmation response to make sure that as long as server comes up, eventually, the message will be delivered exactly once. IRC does not; so it is simply not appropriate for the cases where each message matters.

[dijit]

What I was eluding to was that irc (as a server to server protocol) is fine. As a client it has deficits but those are quite literally smoothed over by websocket capable bouncers and weechat relay.

IRC The protocol is not competing with slack. The IRC ecosystem is. And yes, it lost.

[rakoo]

You might actually be right, server-to-server IRC is good for finding an efficient path between all the servers in the network (ie it considers the network as a whole, not just a series of 1-to-1 connections) and send the minimum information required, so we should be able to keep that and make the client-to-server protocol different.

In short, make the relay/bouncer part of the server itself, and tell clients to connect with the relay protocol, not the IRC protocol. If there were some common standard for this second part that would actually be a great thing.

[josteink]

> nobody bothered to make a decent product that could do all the nice things slack is doing.

Slack is a closed-source for-profit SaaS, ruled by a single benevolent company.

IRC is an open protocol-specification with a multitude of clients, servers and networks.

You couldn’t find better apples and oranges for comparison if you tried.

[dijit]

I agree completely.

But we're talking about reasons people ended up choosing slack over something like IRC (or, really, any open protocol instant messaging specification).

The grand-parent comment raises good points, people want these things, being connected and reachable while not being connected to the server with any client and having a context later on. These are problems that can be solved but nobody has put effort into making a sexy product to do it. (and monetising that kind of product might be troublesome)

[josteink]

> nobody has put effort into making a sexy product

Again we are comparing a product to a protocol.

I’m just pointing out that this is not a reasonable comparison.

There were multiple web-enabled IRC bouncers (closed products) which would be easy to use for anyone, including non-techsavy people.

But evidently the majority of IRC-users were fine without that and preferred the traditional client-server-protocol realm.

[dijit]

IRC is more than a protocol, it’s an ecosystem. You cannot simply talk about IRC in complete isolation.

It’s akin to comparing SMTP with chrome.

You have to include the clients and surrounding infrastructure.

[robjan]

Yes, and there was plenty of opportunity for someone to develop a client that scratches all of those itches. But they didn't.

[petepete]

The main problem is that the IRC standard wasn't kept up to date. It's barely changed in the last 25 years.

The things that IRC is missing, as listed above, could easily have been added.

[Latty]

Frankly, it reminds me a lot of XHTML vs HTML5. I buy all the arguments XHTML had, I like the vision it had for the internet. It also wasn't what actual end-users valued, and something that offered that won out because it provided more value, even if it didn't pursue the same vision.

[nabla9]

In other words: protocols lose to proprietary services.

[lidHanteyk]

The replies really should be "no, stop wanting that." IRC is not meant for such interactions, and is built around different social expectations. If you want 24/7 presence, then you ought to justify it socially, because there is a qualitative cultural difference between folks who regularly idle on IRC vs. folks who are only connected to IRC when they actively want to discuss something. Similarly, backlogs are only marginally useful and are usually a security risk, but the typical client does offer full-text search through IRC backlogs, when needed, and I'm not sure why that's a problem for users.

It's obvious why Slack wins for businesses: Because it gives businesses greater control and legibility over their employees' work habits and decision-making. DCC or any other P2P connection is anathema to this sort of control.

Users want different things. They want both plain text and rich text, and similarly, they want both plain chat and rich chat.

Oh, and aside from all of this, there is a working group [0] which publishes proposals for modernization of the IRC protocol. Adoption rates are low, but perhaps that should tell you something about what users actually want.

[0] https://ircv3.net/

[drngdds]

>Adoption rates are low, but perhaps that should tell you something about what users actually want.

I think it tells you that everyone who wants rich chat (which is most people, btw) already left for Slack or Discord.

[bsdubernerd]

I like the ephemeral nature of IRC. It's supposed to be for real-time communication, the "chat" in irC, not for keeping bouncers. Bouncers defeat the point of IRC entirely.

I also use slack btw, and discord, and matrix too, so I fully understand the importance of a backlog, and having server caching for files is much more convenient than using an additional sharing site.

IRC is not perfect, but for what it does is pretty nice. Having a customizable backlog per-channel would solve most of the issues you have with reconnects and people's expectation. I'd love this backlog to be short by default though (<10m).

X/DCC is plainly annoying and it just breaks too often nowdays. Server assist, even for 1-on-1 sharing would be very useful. Sharing one image with a group of people while working on something is really, _really_ useful and having a common way of doing it that integrates with the chat is very helpful. Reasonable limits and auto-expiration (matching the backlog length or even shorter) would also be very useful.

We know what introducing file sharing does to a chat though. Instant memes pop up. I love how IRC channels look compared to all modern equivalents: just boring text, and minimal text formatting. If file sharing is added, I wished it would never be with inline formatting to keep it the same.

I don't care for search. Storing info in these chat mediums is a horrible, _HORRIBLE_ way to reference anything. Short backlogs are the only way to enforce people to store valuable content where it belongs. Searching through the backlog would then be no different than what irc clients already implement (simple look-back).

Keep in mind text-only chats are so compact that having a full day worth of backlog and downloading that from a cold-cache is still cheaper than getting a single inline animated gif. Just for reference.

I hate slack threads and how people tend to use them. I wished people would simply create ephemeral chats instead.

I find all matrix clients to be absolutely horrendous for exactly the same reasons. They become cesspools of memes and repository of information that are terrible to use. Honestly, the best way to use matrix seems to be gomux, or weechat via a matrix plugin, simply because these clients _ENFORCE_ a certain kind of usage that keeps the TEXT in the chat in the center. Sadly, both are incredibly limited. Cannot get ephemeral channels to work on weechat (which would be the "modern" equivalent of a query with multiple parties). Channel discovery is horrible.

But the backlog does help a lot for reconnections. So does the built-in file sharing.

It seems that the userbase of matrix has a different concept of what a chat should be, and that's why I still prefer IRC for now.

[teuna]

I like how your comment, which I totally agree with, is right below this one when I read it.

> Frankly, it reminds me a lot of XHTML vs HTML5. I buy all the arguments XHTML had, I like the vision it had for the internet. It also wasn't what actual end-users valued, and something that offered that won out because it provided more value, even if it didn't pursue the same vision.

[kazinator]

It's because everyone wanted a proprietary chat system, whose single client EXE for Windows chews 400+ megs of RAM.

[dijit]

Realistically, people don't tend to care about how much ram they're using, that's why PWA's are able to take the jobs of native applications, and people are even happy about it.

People only care if there's not enough resources.

[lonelappde]

There's never enough resources.

[bzb3]

Barely anybody cares that the protocol is open, and 400 MB of ram is pretty much nothing in 2020