Hacker News new | past | comments | ask | show | jobs | submit login
Kandan - an open Source alternative to HipChat (kandanapp.com)
82 points by selvan on Feb 8, 2013 | hide | past | web | favorite | 34 comments

It looks like it is browser only. We are currently looking for something like this that also has a standard protocol like XMPP. Actually all we really want is for Google Chat to support rooms for apps/business users.

Full disclosure: I built Candy

You could use Candy (http://candy-chat.github.com/candy) as a nice web UI for XMPP MUC (Multi-User-Chat). It supports basic features but is easily extendable through plugins.

Apologies for not being clear. We all already have and use Google Chat. Failing that there are XMPP clients on all the relevant desktop and mobile platforms.

The one thing that has the lowest utility is a web based interface to chat since it essentially doesn't work well in the background in the same way as an app like Pidgin does.

looks pretty cool - will check it out

Have you looked into Partychat[1]. It is what we use for internal communication. You can easily create multiple rooms and it integrates with gtalk.

[1]: http://partychapp.appspot.com/

That looks extremely close to what we wanted. It even looks like you can run it on your own appengine instance. Thanks for the pointer.

we plan on supporting XMMP soon...

I've worked in offices where Skype or Hipchat were used exclusively. There is nothing that Hipchat can offer for which I'd give up audio and video chat. You can say people are free to arrange a Skype call if they want, but when a text-based chat program like Hipchat is the office norm, no one bothers to use any other medium.

Hipchat is great at what it does, but without audio and video support, I'd never deploy it in the office.

The only advantages this seems to have over IRC is the ability to embed images and videos. Am I missing something?

I've not used it, but generally an advantage with these sort of things is an easy and simple way to have persistent connections, and history without having to setup a crappy bouncer and deal with it's set of problems.

At the company I work at we decided against IRC because of possible difficulties for non-technical employees. Currently we're using XMPP but we're considering other solutions.

What's preventing non-technical employees from jumping aboard on IRC? There's a web client and desktop clients are fairly simple to set up.

The big advantage I see to IRC is how long it's been around. Plenty of clients and setups catering to IRC. And it's not going away anytime soon. Perhaps it's getting a little long in the tooth, as posed by moe at http://news.ycombinator.com/item?id=2069810

Presumably it automatically saves the history for everyone as well and you don't need an IRC client (just a web browser). Also authentication into the room by default.

I've always wondered why is this not a client's responsibility? There must exist a good IRC client that can recognize links. From there, it can fetch videos and embed images.

LimeChat does. Previews images and Youtube videos, also Adium has a plugin for Youtube.

I have too much free time.

Apart from LimeChat, Textual on OS X does that too - but you've been warned, sometimes there are things pasted you just don't want to see ;)

Colloquy and Linkinus will automatically expand images.

If you're looking to use it for anything other than unmodified internal use, be aware that it uses the AGPL license (the "A" at the start being quite important), and may place restrictions on what you want to do, much more-so than the GPL.

I think that AGPL requires you to give source code to the users of the program. If you use a modified version internally then you'll have to give the source code to your employees. That isn't as problematic as sharing with the whole outside world.

Or maybe I misinterpret the license?

No, thats my point, it may only be usable internally, and if modified only if you trust your staff

Demo server pleeeeease

not working

Yes it is...

Only partially. The layout and formatting are messed up in Chrome 24 and Firefox 18 and is unusable.


It's buggy. Maybe just on Chrome 24.0.1312.52 running on OSX?

It looks like it's back again.

Does it support HTTPS out of the box? I notice the demo isn't running on it, which is a deal breaker for an internal communication network.

You may be able to proxy it behind nginx, which does support HTTPS.

Some applications do struggle when running behind a proxy (I'm looking at you Jira) but my experience tells me that it's harder to break SSL support than not.

We're running JIRA behind nginx with https. To get it to work properly we had to edit JIRA's server.xml, duplicate the connector but append (e.g.) proxyPort="8443" and scheme="https". In addition, in JIRA's general settings you should make sure that the base URL is set to use https to avoid the SSL warnings.

I'd prefer for it to not. It's better to use nginx or stud to provide HTTPS on top of an HTTP app.

the demo isn't running https. the demo is the 1.0 release, 1.1 will support https.

Looks really nice though I'd like it more if it would also use XMPP as the protocol. (Or did I miss that it actually uses it?)

Are there any plans to support external authentication/authorization methods?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact