Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

281–290 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#281

A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to actually set those up. Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts? Some sort of open protocol. Urgh, I've been…

Edit: looks like someone asked a similar question below.

I'm curious though.

What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings.

I use a nice web gateway (kiwi) on top of an IRC channel for my student office hours and it's easy. They just supply a username and log in. No software to install, the UI looks nice, and students don't have to sign up for anything.

If I had the resources and the money, I'd focus on a good modern IRC client and server.

Am I wrong?

Re: Open Sourcers Race to Build Better Versions of Slack

#282

Earlier quoted context omitted.

IRCv3 has been around since 2004 and seems like it has largely failed to gain any traction, even among IRC networks - why would that change now?

The ircv3.net organization and the movement behind it started in 2012 and gained traction in 2014-2015. You're thinking of something else.

The specs listed under 3.1 have copyright dates including 2004, 2009, 2010.

There's also this, which may be what I'm thinking of, and perhaps not official, but one of the first things I recall:

http://achurch.org/irc3/

Dating to 1999.

Re: Open Sourcers Race to Build Better Versions of Slack

#283

Earlier quoted context omitted.

I'm sure that I'm over simplifying, but can't you just put tokens or markdown right in the chat for those sort of things? If you have an old, flat IRC client, it's ugly but you can figure it out. If you have a supported client you get a nice UI?

No amount of markdown makes up for the lack of offline messages.

ZNC handles this nicely.

The tech is all there. It just sucks to set it up yourself and should just work out of the box.

Re: Open Sourcers Race to Build Better Versions of Slack

#284

A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to actually set those up. Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts? Some sort of open protocol. Urgh, I've been…

Edit: looks like someone asked a similar question below. I'm curious though. What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings. I use a nice web gateway (kiwi) on top of an IRC…

i think the #1 value add from slack/hipchat is that it's hosted for you. we spend thousands of man-hours each month and year keeping our servers up. uptime is hard. chat is not hard. historical chat is not hard. when chat is down, your business is at risk. there's other services at my company we pay for that aren't very complicated - we just don't want to host it. paying $5/user/mo for chat that is always up is easier than keeping it up yourself.

your use case is very different, and i wouldn't expect any pay-for-chat service to make any sense for it

Re: Open Sourcers Race to Build Better Versions of Slack

#285
post #278

Earlier quoted context omitted.

I've never needed to open an SSH tunnel to connect to IRC. I click on the Xchat icon, and two seconds later I'm connected. I don't know where you're getting these ideas that using IRC requires consulting the RFC or opening SSH tunnels, because you don't need to do either of those things.

Plain and simple: If IRC was easy enough for joe in marketing and steve in sales to use, they'd be using it years ago.

Only if they had a reason to use it.

Re: Open Sourcers Race to Build Better Versions of Slack

#286

Earlier quoted context omitted.

> Professional Engineer Yeah, here's where you fucked up reading my post. > anyone in any kind of role (senior to junior, technical to non-technical) I'm talking about Joe Frontend, Billy Design Intern, Gary Office Assistant. Maybe you work on teams that are 100% neckbeards that aren't afraid to crack open an RFC to get daily shit done (and waste huge amounts of company resources on things that should be simple), but…

I've never needed to open an SSH tunnel to connect to IRC. I click on the Xchat icon, and two seconds later I'm connected. I don't know where you're getting these ideas that using IRC requires consulting the RFC or opening SSH tunnels, because you don't need to do either of those things.

There's two ways this argument goes awry: "IRC is fine, you just have to be smart enough" and "Only ever use IRC for the things it does well", I thought we were on the other branch there for a bit.

I had specifically included a scenario that is both common for use in my experience, and also pretty much impossible for a normal human using IRC in order to preempt this branch:

> Follow the directions to set it up so changes on this Trello board are posted to #channel

Sure, in extremely limited situations (so many qualifications are required here I won't list them) it's mostly easy enough for a non-technical person to manage.

Normal people (that is, people who value their own time and haven't been warped by daily interaction with software that fails to do what you asked because you failed to include some extremely implicit punctuation) laugh at many common explanations surrounding IRC, just a handful of examples: "IRC doesn't have passwords really so to prove who you are, you have to speak specific commands, like a CLI, at this bot over here, or configure your client to do that for you" "IRC has away status but nobody really uses it, because it's manual in many clients, so you typically 'ping' people and just wait to hear back if they are around" "oh yeah, if you want to get rid of all the join/part/away spam, the option for that is hidden in a menu with a bunch of other stuff, and in this client you have to set it up for each channel separately" "oh, yeah, you can't speak in that channel because you have to get the bot to +v you by direct messaging it 'shibboleth'" "btw here's the list of random-seeming letter 'flags' our server supports and how it interprets what they mean differently from other IRC daemons"

And we haven't even talked about how bad the story is around message persistence or using multiple clients or the "solution": bouncers. Getting all that going is basically a non-starter for humans unless you give in and use a service like IRCCloud that deals with search and synchronization well across platforms (but which you must be aware of in the first place).

I'm pretty technical, I've internalised the arcane knowledge, I've written IRC RFC-compliant bots to get things done (and then made them conform with common out-of RFC conventions in order to work with non-conforming IRCds), but that was all in high school, well before I gained a sense for the value of my own time. I can do it but I still refuse (to the degree that a team's use of IRC would make me pass on an offer as would I pass on a developer interviewee's inability to perceive usability problems with IRC).

Re: Open Sourcers Race to Build Better Versions of Slack

#287

Earlier quoted context omitted.

Ok. It's kind of good to hear the barrier to open sourcing is more legal than commercial. That means it's fixable :) Can I ask you some details on how you went about working with Skype and Hangouts? Did you do the reverse engineering yourself? These are protocols several popular open source projects have been trying to support for years and haven't succeeded. Can I also ask you about your tech stack/languages you use…

We implemented them ourselves, and it took quite a bit of work. Our magic weapon is Erlang, which is a wonderful language for working with protocols, and a wonderful runtime for working with many things happening at the same time. The other magic weapons are the Cowboy webserver and the Gun http client -- both written by Loïc Hoguin. Loïc doesn't work for us, but we've been sponsoring him financially for over two yea…

I was just considering advocating within my employer (Cloudant, i.e. clustered-CouchDB-as-a-Service) to back Loïc too. CouchDB is still stuck in the past with Mochiweb, and while switching that out for Cowboy 1.X would be a nice-to-have, getting our hands on a stable release of Cowboy2 (i.e. "the HTTP/2 version") would let us optimize Couch's replication story immensely. I've just been trying to set up a single trivial Event Stream HTTP/2 loop_handler with the Cowboy2 master, and it's really just not there yet, so we could probably give him a push.

Re: Open Sourcers Race to Build Better Versions of Slack

#288

A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to actually set those up. Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts? Some sort of open protocol. Urgh, I've been…

Edit: looks like someone asked a similar question below. I'm curious though. What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings. I use a nice web gateway (kiwi) on top of an IRC…

> Am I wrong?

Yes and no. Setting up an IRC server is hard. Pretty much all IRC servers use arcane settings and configuration formats. I run an Inspircd and Hybrid servers, and for people who aren't used to it, it's really daunting compared to setting up something like prosody.

Services on top like Kiwi are nice. I run Shout IRC which is beautiful and slack-like, but again requires passenger and node to work, so lots of moving parts just for a web-ui.

Having said that, all of this is perfectly doable, it's just not so easy if you're used to dealing with something lightweight and a little php on top.

Re: Open Sourcers Race to Build Better Versions of Slack

#289
post #164

Earlier quoted context omitted.

Thank you, that PDF is incredibly depressing. By the way, well done on sameroom. I came across your product while working on the stuff I mentioned and it looks like an incredibly useful thing. I really wish you would open source it, though. (Or at least open source some libraries for talking to the protocols you deal with. Especially Hangouts.)

Not sure what is so depressing here. According to the chart, a total of nine listed networks died in 50+ years, this is actually astoundingly low. And all IRC implementations are "interoperable" in the sense that a single client that implements the protocol can connect to any of them, this chart seems to be padding things a lot by calling every IRC server network a "chat service". A number of them also have or have h…

Surely there were networks that went defunct before 2011. That's probably when they started paying attention.

Re: Open Sourcers Race to Build Better Versions of Slack

#290
post #287

Earlier quoted context omitted.

We implemented them ourselves, and it took quite a bit of work. Our magic weapon is Erlang, which is a wonderful language for working with protocols, and a wonderful runtime for working with many things happening at the same time. The other magic weapons are the Cowboy webserver and the Gun http client -- both written by Loïc Hoguin. Loïc doesn't work for us, but we've been sponsoring him financially for over two yea…

I was just considering advocating within my employer (Cloudant, i.e. clustered-CouchDB-as-a-Service) to back Loïc too. CouchDB is still stuck in the past with Mochiweb, and while switching that out for Cowboy 1.X would be a nice-to-have, getting our hands on a stable release of Cowboy2 (i.e. "the HTTP/2 version") would let us optimize Couch's replication story immensely. I've just been trying to set up a single trivi…

That would be great - I can put you in touch if you're not already (andrei@sameroom.io).
Post reply on HN