Hacker News Reader

Comment by Dowwie | Hacker News Reader

How many open source slack alternatives before someone writes one that actually utilizes the IRC protocol?

Is there a defensible argument against using IRC?

There already are a number of IRC client web frontends. The one I'm working on is Glowing Bear -- https://github.com/glowing-bear/glowing-bear . It uses a proper IRC client running on a server (WeeChat in a terminal multiplexer) and connects to that via WebSockets. Minimal reinvention of the wheel, and you can continue using all those nice scripts, triggers, and filters that WeeChat offers. The frontend (Glowing Bear) is completely static and runs 100% in your browser, connecting to your server directly.

I really don't get those projects that consist of a designer frontend and a terrible half-baked IRC client in nodejs.

Designer front ends matter. You have no screenshots, which is going to severely limit adoption. If the design is average or subpar, it will limit adoption.

Also, integrations with third party services matter. Everyone seems to ignore this, but it's critical.

Uhm, there is a screenshot in the README, both for mobile and a desktop browser. Maybe we could move it up a bit more. As for the design, sure, you're right that it matters. We try to keep it as clean and intuitive as possible, but none of the core devs is a designer, so we just do it as best as we can. Ideas for improvement (or even pull requests) are always greatly appreciated!

For third party services, Glowing Bear has a number of plugins that embed various content right in the conversation (images, youtube, spotify, etc). Not sure if that's what you're referring to.

The uhm is unnecessary; I don't see any screenshots on the GitHub page, linked or otherwise. The page linked from the website is https://github.com/mattermost/platform.

For third-party services, I'm talking about things that matter for getting work done. For example, issue trackers like JIRA.

The IRC protocol isn't pretty, and there are plenty of incompatible server implementations, but if you're controlling both the server end and the client end it's certainly where I'd start. My first thought when I saw Slack was "someone did a pretty web irc client finally, cool" (I have no idea if they use irc internally? but it seemed such a direct match)

The IRC protocol might not be pretty, but what protocol is? HTTP? AMQP? XMPP? Protocols are not meant to be pretty, just efficient and robust enough to support the desired feature set. It's a shame that none of Slack, Hipchat, now Mattermost support IRC. They're all just IRC clones, drawing on the same ideas, just giving you a crappy (but pretty!) web interface.

Slack "supports" IRC in that you can allow IRC connections, and then people can connect to your Slack instance via IRC. This might also be the case for some of the alternatives.

And it's a pain in the neck! It means that some of the participants in the channel are not able to read what's happened while they were away. Some of them get encoding errors. The IRC people do not get the same graphical elements as everybody else. They can't use custom /-commands.

In conclusion, in order to communicate the most effectively, you have to know who's on IRC and think about the differences in user experience for these people versus everybody else.

IRC has weaknesses (namely lack of centralized logging and unspecified text encoding) and fixing these weaknesses means forgoing support for existing IRC clients.

> And it's a pain in the neck! It means that some of the participants in the channel are not able to read what's happened while they were away. Some of them get encoding errors.

Everyone I've ever worked with who uses IRC has a client or bouncer running somewhere that never disconnects and assumes UTF-8, so neither of these are realistic problems.

>centralized logging

A logging program is just another IRC client. Problem solved.

I also assumed Mattermost supported IRC, without even checking. It's a bit disappointing that it doesn't, but I wonder how easy it'd be to add support for IRC in Mattermost, given that we have the source code?

This is my biggest problem with Slack. It's a cool product that could have been built over IRC. But no, they had to create their own walled garden.

Whilst I take your point, worth noting that Slack does offer an IRC gateway to allow for use via an IRC client. Not quite the same thing as basing everything on IRC, but better than nothing?

True. Did it always offer that? I seem to have missed that feature last time I checked Slack out.

I saw the IRC gateway feature a little bit after the launch. I don't remember seeing it in the initial launch feature list and that it was "coming up" more or less.

Reply on news.ycombinator.com