[chubot]

I love using Unix and the terminal, but I hate using IRC. I don't think it works "perfectly fine".

I have been lurking on a few IRC channels due to my work on http://www.oilshell.org/ .

Problems I noticed:

- The lack of conversations/threading is really annoying. Most worthwhile IRC channels have more than one conversation going on at once. Not only do you have to untangle who's talking to who, there's no way to know where the beginning of a conversation is. I have to read messages backward to find the beginning .

- By default there seems to be a lot of leave/join spam. I used IRC for a year before turning this off and it vastly improved my experience.

- I think most clients don't save anything by default. When I reboot my computer and don't log in again, I miss messages.

- Having to use pastebins for code is annoying.

I'm sure that someone will respond with how you can solve all these problems with a certain IRC client. But I don't want to do that. I'm not technically unsophisticated -- I write software in 5+ languages and I know all about Unix and networking. I just don't want to spend my mental energy on my chat client -- I have tons of other projects to spend it on.

So I only use IRC when necessary; I use e-mail otherwise (through GMail.)

Of course, I also don't use Slack. But from what I hear it solves some of these problems.

[kqr]

I think you are focusing on the wrong thing by spending several paragraphs on the problems with the out-of-the-box experience and only one on the fact that it is an open protocol so a sufficiently technical user can fix it.

An open protocol, free choice of clients, and decentralised infrastructure is a baseline. A change is not an improvement if it removes those. (You could argue you have valid reasons to remove any of them and you'd be wrong.)

I don't see why it would be much more exhausting to use a hosted IRC service like IRCCloud to solve your problems than pick a specific alternative protocol entirely.

[chubot]

I'm explaining to the parent why "I don't understand this world" isn't a reasonable response. If you've used Slack and IRC for 5 minutes, you should know why most users prefer Slack, even if you prefer IRC.

I don't use Slack regularly, but I have tried it, and it is instantly obvious what the difference is. If you don't see it, then you probably have never designed software for end users. (FWIW, I also agree that Slack is bloated and that's one of the reasons I don't use it.)

As far as contributing to free software and open protocols, I'm working on fixing Unix shell. It would be great if IRC developers would take some inspiration from Slack and other proprietary services and fold them into IRC. Although, as mentioned in this thread, some of that may be very difficult or impossible without a commonly accepted client.

And I understand it's not a one person job. It probably requires a more coordinated effort. Decentralization has drawbacks as well as benefits.

What is not OK is pretending that problems with IRC don't exist. If you have that view, and spread it, then you guarantee that open protocols won't win.

I prefer open protocols, and I lament what has happened to Usenet and e-mail (trying to set up a mailing list for my open source project has been frustrating; spam causes problems for mailman-type lists). But honestly the proprietary services have innovated. They're not better in all respects, but they are better in some.

Open source doesn't mean being ignorant of users and dismissive of their complaints.

(FWIW I didn't know about IRCCloud. It looks interesting and I may check it out.)

[derefr]

> A change is not an improvement if it removes those.

If you see Slack as a replacement for IRC, then sure, it's not an improvement.

If you see Slack (and other proprietary solutions) as a capitalism-incentivized R&D lab for features that can then be absorbed into the open ecosystem, then it's nice that it exists, isn't it?

[aidenn0]

If you want "An open protocol, free choice of clients, and decentralised infrastructure" then Jabber and Matrix are both much closer competitors to slack. IRCv3 is a step in the right direction for IRC, but is not as far along as either of those.

[ptman]

btw, you can also use matrix.org and their irc bridges to various irc networks in place of irccloud

[jaytaylor]

Unsolicited feedback for you @chubot, in case you're open to it:

Clicking through to oilshell - I wanted to know what is different and exciting about it, but all I found was text saying it's "new". Making the value proposition clearer would go a long way and be a big help to people who are curious and geniunely want to understand what's amazing about your creation.. !

[chubot]

Thanks for the feedback. I thought I had solved that with the "Why a New Unix Shell?" link at the very top, but I understand you still have to read a bunch of text to answer your questions.

My main goal right is to have sophisticated users try it and give bug reports. It's not ready for people to use as their daily shell (and that isn't even the primary purpose of the project. As explained in the FAQ, I'm focused on shell as a programming language first.)

Some people have tried it and reported bugs, but I could use more reports. So I suppose I could try to sell it a little more and maybe get more feedback. But overall I feel like it's gotten a lot of feedback and attention. I'll think about whether it makes sense to "sell it" more.

The other thing I would like is to attract experienced developers who have implemented VMs and programming languages. Most of those people are working on their own projects. But I think many of them understand my project and half of the blog posts are aimed at that audience.

[u801e]

> The lack of conversations/threading is really annoying.

I find it interesting that people want to have threaded conversations in what is essentially a synchronous chat, but they prefer to have a degraded threading experience in their email client by using conversation view rather than traditional email threading using the Reply-To and/or References headers.

[solarkraft]

Plus: What about a history? Do I really have to have my client running to not miss stuff? That may have technical reasons, but is inconvenient.

[zzzcpan]

IRC solves these problems via things like bots and bouncers. Although running always connected irssi client [1] in a screen [2] on a server is probably the easiest way to achieve it.

[1] https://irssi.org/

[2] https://www.gnu.org/software/screen/

[derefr]

IRC doesn't solve those problems; individual users solve those problems on top of IRC (and usually not very well.)

A proper open-ecosystem solution would involve network-level history-storage-and-retrieval nodes (basically archival peers in the IRC protocol), and additions to the protocol to direct archive-access queries to those nodes.

[deckard1]

> A proper open-ecosystem solution

Not sure what you mean by "open ecosystem solution." IRC is literally just a few RFCs, a variety of server software, and a variety of client software. It's as extendable as you need it, and most networks have their own extensions already. Is that not open enough for you?

> IRC doesn't solve those problems; individual users solve those problems

As opposed to...? AI solving them? Do we need a corporation to hold our hand while we solve these issues? I'm not following what you're objecting to here. You're free to write and propose your own RFCs and extend IRC however you wish.

[derefr]

> Is that not open enough for you?

I was trying to contrast with existing solutions—IRCCloud, for example, "solves" the problem of history search by effectively wrapping IRC into a proprietary web cloud service.

By an "open-ecosystem solution", I mean a solution that applies to anyone and everyone who uses the IRC protocol, rather than only for users of some specific client.

I'm not saying IRC isn't amenable to open-ecosystem solutions; I'm saying that nobody has (yet) tried to solve this problem in an open-ecosystem way.

> As opposed to...?

As opposed to network-operators being enabled to solve these problems for users of their networks.

Consider the contrast of POP3 vs. IMAP. In POP3, the tasks of "email storage" and "email search" are left to the user, and often they'll solve them badly (by e.g. setting up direct POP3 connections from several devices to one POP3 account, ending up with random emails living only on one or another device, whichever one happened to pull them.) In IMAP, by contrast, email storage and indexing happen on the IMAP server, and users don't need to worry about it. But, since the solution doesn't involve any proprietary services, users can still "take control" of the process if they want—in this case, by setting up their own IMAP server. They just don't have to do that.

> You're free to write and propose your own RFCs and extend IRC however you wish.

I think we're in violent agreement about that. My point was that nobody seems to want to do that for the IRC ecosystem vis-a-vis network-level message archiving.

[rspeer]

And other platforms solve this problem by having history as a built-in feature, which apparently IRC can never get due to inertia.

[kqr]

IRC is not a service. It's a protocol. There are services built on IRC mentioned in this thread which have history as a built-in feature.

[rspeer]

And yet every thread about Slack (or Discord or Gitter or whatever) is full of people saying "why not just use IRC"?, as if IRC could replace a complete service.

[ergothus]

Slack addresses some of the problems, but not all:

> The lack of conversations/threading is really annoying.

Slack is arguably worse - they recently added threading (really comments that can go on a post - there is no nesting), but this has made me much more likely to miss any follow-up because messages are less visible than otherwise.

> By default there seems to be a lot of leave/join spam. I used IRC for a year before turning this off and it vastly improved my experience.

This is entirely client dependent, so not really a fault of IRC. Slack has the same option, it just defaults to not displaying it like clients as opposed to whatever IRC client you used.

> I think most clients don't save anything by default. When I reboot my computer and don't log in again, I miss messages.

Yes. I don't know the inner workings, but generally if you're offline on IRC you will miss anything directed at you. Slack definitely addresses this, and it is my favorite "feature" - it means that Slack is not good for only casual discussions. (Slack's search is my second fav, and there's nothing special about that, it just works well enough that I can usually find that comment I vaguely recall someone making within the last 6 months on one of the many channels I'm on).

I expect this is largely a client issue, though I also imagine that most IRC servers have a very limited amount of immediately available conversation. Remembering that you have direct messages waiting for you would require servers that reserve nicks. That's all guessing though.

- Having to use pastebins for code is annoying.

Slack allows for posting code in text, posting text "snippets" that can include code, and posting files that can be downloaded.

Overall your frustrations seem very reasonable, but from the sound of it you're "hanging out" on IRC channels that are being friendly for outside users to drop in and out, and for devs to have conversations that are considered temporary. Plus not having users post goatse pics or worse. Which means they aren't even TRYING to accomplish what you want. Hard to blame IRC in that case - those features aren't used even when available.

I'm not exactly saying "You just need to use IRC client X" as you predicted, but more "you probably just need to change a config and connect to IRC servers that are INTENDED to do what you want". Not wanting to go through that effort is fine, and I'm not saying Slack and other alternatives are worse or even equal for those tasks, but don't blame the plane for not flying when the pilot is making donuts on the runway.

[chubot]

I'm responding to the parent, who was questioning the existence of Slack, because IRC already exists. That's not reasonable, as I explained in the comment you're replying to, and even more in another reply.

IRC doesn't work "perfectly fine", at least in the context of the problems that Slack solves.

I think we largely agree on technical matters; it's a matter of what relevance this has to the OP -- a Slack client for the terminal.

If your stance is that IRC is irrelevant to this thread because Slack and IRC solve different problems, then I might mostly agree. But I didn't bring up IRC!

[ergothus]

> If your stance is that IRC is irrelevant to this thread because Slack and IRC solve different problems

I was saying you are comparing Slack to IRC-when-used-to-solve-a-different problem. You haven't described IRC as it could be configured to handle the same problems as Slack, only when you've encountered it in the admittedly more common case that it's intended for drop by traffic.