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.
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.
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.
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.
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.
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.
