Thanks for asking these questions. I gave myself a head smack for not including some of this info on the page itself. I'll add in, but answer here:

1. Absolutely runs in a browser and we're doing all we can to make it a first-class citizen. The idea is that you can bring ad hoc members to the team without them having to do any setup.

2. We're starting to build out native apps with deeper integrations (ie, the Mac notification center). We're starting with the commercial desktop and mobile platforms, but as a big fan of Linux I'm eager to have a native client there, too.

3. Right now it's a hosted service, but others, too, have brought up the sensitivity of team data. Reminds me of how Memoto received feedback that eventually brought them to incorporate an option for local storage rather than pushing images to their servers automatically.

4. At this early stage it's a custom protocol, but that was the fastest way to stand up our interface layer. I do think it would greatly help adoption to be XMPP compatible and we're digging in to the potential of that. Video / audio (which is used to complement the chat) is based on WebRTC.

Running in a browser is great for getting started, but anyone who's a web developer will have their browser tank and take down every web-based app with it. For this reason it's always nice to have a native client option. Propane (http://propaneapp.com/) is great example of a simple native client.

Secondly, please, please bundle in XMPP so that writing agents for this kind of app isn't an exercise in sheer frustration.

IRC compatibility at the last is fantastic, and it's a simple protocol. Flowdock offers this (and is a similar service).

my workplace uses Hipchat, and they appear XMPP based. You can access it using your IRC client with bitlbee as a bridge (I just set this up this past weekend - I don't know why I didn't do it sooner). Not as simple as direct IRC compatibility, but something I can live with.

I imagine it's easier for them to build custom features on XMPP (since the protocol supports custom messages/actions) rather than IRC (where you'll have to build your tool around IRC's paradigm of chat-rooms and text only chat).

+1 on the self-hosted. A wishlist in silk accompanied by a 2-ton brick of a deal-breaker. You'd think the most solution-starved demographic for chat would be those behind a corporate firewall...

If we keep building for behind the firewall, then software for firewalls will continue to live. The only way to kill behind the firewall software is to stop building shrink-wrapped software.

Why kill shrink-wrap you ask? Because building and then promptly forgetting about software is a thing of the past. Now we have amazing tools that allow us to build even better solutions. Things like analytics, a/b testing and the cloud are the future for software. Why continue to build in the past?

would love to explore this but only if i could host it on my own server.