Should I use XMPP for my startup's messaging system?
10 comments
Full disclosure: I'm the CEO of Chesspark and a board and council member of the XSF (the standards organization behind XMPP).
I highly recommend XMPP. You get a lot of functionality for free: contact lists, presence, access to a huge and diverse library of implementations, and a large community of helpful people. It's also fairly easy to extend, and this can be done at many levels.
It's true that at Chesspark we've spent a lot of time working with XMPP and molding it to our particular task. Much of this is because we liked doing it, and you can see that passion revealed in our various open source projects related to XMPP. For us this has paid huge dividends as our new projects are more messaging than chess related.
Between Tigase, Openfire, and Ejabberd, there are a number of fairly robust server implementations that are easy to set up and easy to maintain. People think of ejabberd as a black box because they are afraid of Erlang, but the fact is that ejabberd code is pretty easy to read and modify. You also have Google Talk available via Google Apps for Domains.
On the Web interface side, things are not as easy, but the XMPP solutions are well tested and have been worked on for 3-4 years (XMPP BOSH predates Comet). I count at least 4 diferent JavaScript implementations you can choose from, one of which is commercial and comes with support. Three of the four (my own is the odd lib out here) include chat application features, not just base protocol support. I now of at least one AS3 implementation which should soon be open source (from Seesmic).
This is a classic build versus buy type of decision. Sure you can build this yourself, but is it really less work than a little learning of the XMPP protocol, perhaps a few bug fixes in an available library, and some custom component work? If we had done our own non-XMPP based server platform, we'd have spent more time solving similar problems but without any external help or tools.
One of the nice things for us at Chesspark is that many of the features we wanted to do had already been partial solved by XMPP extension protocols: group chat for watching live games, publish-subscribe for rating updates and profile notifications, and ad-hoc commands for generic RPC type functionality.
You mention that you'd need extensive modifications, and I can't really help much here without knowing what modifications you're thinking of. XMPP can be extended at many levels. At Chesspark we have XMPP bots that maintain order in the public chat rooms and our client implements the moderation facilities of the multi-user chat protocol. Community managers can privately warn, mute, kick, and ban people. The next step up are components, which can pretty much listen to anything going on in the server and react to it, or handle messages directly from users. These are extremely easy to write, and ejabberd comes full of hooks for you to attach to to implement most things you can imagine. Most of ejabberd's own modules are quite small and serve as good examples. One thing to note about components is that ejabberd supports the component protocol, so you can write these server extensions in the langauge of your choice. At Chesspark, most of our components are in Python, but they will run on ejabberd, jabberd2, Tigase, or almost any other XMPP server that exists. That is the power of the open standard. The last resort is to modify the server internals. We've had to do this at Chesspark a single time to add an API hook for disconnecting users from our ejabberd module.
I think you have little to lose by spending a few hours getting ejabberd or another server set up and seeing what tools and libraries already exist that might assist you in your goals.
I highly recommend XMPP. You get a lot of functionality for free: contact lists, presence, access to a huge and diverse library of implementations, and a large community of helpful people. It's also fairly easy to extend, and this can be done at many levels.
It's true that at Chesspark we've spent a lot of time working with XMPP and molding it to our particular task. Much of this is because we liked doing it, and you can see that passion revealed in our various open source projects related to XMPP. For us this has paid huge dividends as our new projects are more messaging than chess related.
Between Tigase, Openfire, and Ejabberd, there are a number of fairly robust server implementations that are easy to set up and easy to maintain. People think of ejabberd as a black box because they are afraid of Erlang, but the fact is that ejabberd code is pretty easy to read and modify. You also have Google Talk available via Google Apps for Domains.
On the Web interface side, things are not as easy, but the XMPP solutions are well tested and have been worked on for 3-4 years (XMPP BOSH predates Comet). I count at least 4 diferent JavaScript implementations you can choose from, one of which is commercial and comes with support. Three of the four (my own is the odd lib out here) include chat application features, not just base protocol support. I now of at least one AS3 implementation which should soon be open source (from Seesmic).
This is a classic build versus buy type of decision. Sure you can build this yourself, but is it really less work than a little learning of the XMPP protocol, perhaps a few bug fixes in an available library, and some custom component work? If we had done our own non-XMPP based server platform, we'd have spent more time solving similar problems but without any external help or tools.
One of the nice things for us at Chesspark is that many of the features we wanted to do had already been partial solved by XMPP extension protocols: group chat for watching live games, publish-subscribe for rating updates and profile notifications, and ad-hoc commands for generic RPC type functionality.
You mention that you'd need extensive modifications, and I can't really help much here without knowing what modifications you're thinking of. XMPP can be extended at many levels. At Chesspark we have XMPP bots that maintain order in the public chat rooms and our client implements the moderation facilities of the multi-user chat protocol. Community managers can privately warn, mute, kick, and ban people. The next step up are components, which can pretty much listen to anything going on in the server and react to it, or handle messages directly from users. These are extremely easy to write, and ejabberd comes full of hooks for you to attach to to implement most things you can imagine. Most of ejabberd's own modules are quite small and serve as good examples. One thing to note about components is that ejabberd supports the component protocol, so you can write these server extensions in the langauge of your choice. At Chesspark, most of our components are in Python, but they will run on ejabberd, jabberd2, Tigase, or almost any other XMPP server that exists. That is the power of the open standard. The last resort is to modify the server internals. We've had to do this at Chesspark a single time to add an API hook for disconnecting users from our ejabberd module.
I think you have little to lose by spending a few hours getting ejabberd or another server set up and seeing what tools and libraries already exist that might assist you in your goals.
http://orbited.org/ <- python server providing a TCP proxy to the browser.
http://js.io/ <- open source protocols for javascript. Has an XMPP client(at least part of one)
It may not make short-term sense for you to use this.
It may not make short-term sense for you to use this.
Meebo is soon releasing its "Community IM" product. Might want to check it out.
http://www.meebo.com/communityim/
That looks just about perfect. Too bad I don't have the min. # of daily active users yet (20,000).
Edit: I might be able to hold out on this for now and just use that when it becomes available. Looks very promising.
Edit: I might be able to hold out on this for now and just use that when it becomes available. Looks very promising.
I seem to recall that Google Talk had an embeddable IM product as well, aside from their Google Apps for Domains Gtalk service offering.
Definitely don't invest that much time so early on. You will start to get an idea of future needs quickly, and then you can judge whether you will want to or need to make the change.
xmpp is not difficult to deal with, give it a shot and let us know if you need any help, we've done lots of xmpp stuff. -the guys at imified.com
Some thoughts:
Will the cost of maintaining the hand-rolled code exceed the cost of working with XMPP tech (and subsequently benefiting from an existing community and proven reliable code)? Hiring someone for an existing standard, for example, means less legwork documenting and codifying your own system.
What rate of feature growth do you see, if any? Whatever solution you choose now, assumptions will start being made against it in future code, and they will slow down a switch later.
One way you could research this further is to do the bare minimum test case of both techniques in isolation from your other work. You won't have the "but I have to consider x" in the back of your head, doing it that way.
Will the cost of maintaining the hand-rolled code exceed the cost of working with XMPP tech (and subsequently benefiting from an existing community and proven reliable code)? Hiring someone for an existing standard, for example, means less legwork documenting and codifying your own system.
What rate of feature growth do you see, if any? Whatever solution you choose now, assumptions will start being made against it in future code, and they will slow down a switch later.
One way you could research this further is to do the bare minimum test case of both techniques in isolation from your other work. You won't have the "but I have to consider x" in the back of your head, doing it that way.
classic problem. xmpp was designed for this, but we've found it non-trivial (not rocket science either, but non-trivial) to setup/use. ejabberd is solid once it's up and running, but it's a black box once it's going (with exception of some logging).
IM is one of those things that once you start, you'll be endlessly piling on features. sure you can bootstrap IM with what you've got, but think about adding presence, file transfer, status/away messages, rostering, roster add/remove permissions/confirmation/approval.
I helped define the product spec for me.dium's sidebar and associated IM client/roster. massive time-sink, but, IM was core to the experience.
challenge is everyone's expectations around IM these days are defined by Adium, and AOL IM clients, and those are very feature rich products that have taken years to build/get right. that's what you're up against if you start building your own. xmpp tries to bridge that gap.
I'd make very sure you want to walk down this path at all. After doing that, if the answer is yes, then I think you should leverage xmpp and bit the bullets that it winds up firing at you; rather those then reinventing the wheel. you might want to look at openfire as well, and cisco/jabber.com can sell you hardened clustering solutions if/when you need them.
I'm now at http://gnipcentral.com and we do xmpp for message routing (not IM). we've been using ejabberd for awhile (in a very limited manner).
haven't looked at meebo's community IM thing, but that sounds like it might be spot on.
IM is one of those things that once you start, you'll be endlessly piling on features. sure you can bootstrap IM with what you've got, but think about adding presence, file transfer, status/away messages, rostering, roster add/remove permissions/confirmation/approval.
I helped define the product spec for me.dium's sidebar and associated IM client/roster. massive time-sink, but, IM was core to the experience.
challenge is everyone's expectations around IM these days are defined by Adium, and AOL IM clients, and those are very feature rich products that have taken years to build/get right. that's what you're up against if you start building your own. xmpp tries to bridge that gap.
I'd make very sure you want to walk down this path at all. After doing that, if the answer is yes, then I think you should leverage xmpp and bit the bullets that it winds up firing at you; rather those then reinventing the wheel. you might want to look at openfire as well, and cisco/jabber.com can sell you hardened clustering solutions if/when you need them.
I'm now at http://gnipcentral.com and we do xmpp for message routing (not IM). we've been using ejabberd for awhile (in a very limited manner).
haven't looked at meebo's community IM thing, but that sounds like it might be spot on.
Speaking of Adium, they will bend over backwards to support a proprietary chat system from a huge site like Facebook, but they are not going to add support for arbitrary startup's creations. Using XMPP allows your users flexibility in how they access your service. If Adium is how they choose to stay connected, then great. Sites like Identi.ca have XMPP interfaces for precisely this reason, and it didn't take long for Twhirl and others to add support for Identi.ca since it was well documented (via XMPP standard) and easy to do.
Check out http://www.igniterealtime.org/projects/openfire/index.jsp.
Its not exactly what you're looking for, but it might help.
We use this at my office. It is meant for collaboration, but who knows, maybe you'll get some use out of it.
OpenFire has a great config front-end if you don't really feel like tweaking stuff around. The only thing I don't really like about it is that it uses Java, but we've got great speed and uptime with it anyway.
Its not exactly what you're looking for, but it might help.
We use this at my office. It is meant for collaboration, but who knows, maybe you'll get some use out of it.
OpenFire has a great config front-end if you don't really feel like tweaking stuff around. The only thing I don't really like about it is that it uses Java, but we've got great speed and uptime with it anyway.
Start simple, run it as soon as possible and wait for feedback, you can switch to some other solution at anytime if people will like it.
My startup currently already uses a very simple and straightforward daemon (in Python) to facilitate real-time push to web users (uses Flash client-side).
XMPP would tackle all of these things well, since that's what it is born to do. I could run an ejabberd server and go from there.
However, I'd need to extensively modify/configure the server to match the requirements of my startup. It's been done (Chesspark has invested themselves in this), but I worry that I'd spend a disproportionate amount of time trying to mold and maintain a jabber server to match the requirements of the site. (I'm a sole founder.) A few requirements:
- Use the database for user accounts (easy) - I'd like to make wider use of users' contacts throughout the site as part of the site's featureset; the information about contacts must be equally easy to retrieve, edit, and manage without going through the jabber server - I'll need to make sure the messaging system isn't abused as a free-for-all: Messaging should be a core part of the site's experience, and we'll want to have good controls for reporting disruptive users, filtering explicit content, and the like. A lot of that is supported by the ejabberd server, but it could be difficult to integrate sitewide without delving into its internals. - It needn't be complex; the messaging system should just be a simple tool for users to communicate. Facebook Chat is relatively simple in that respect.
Since we already have a push-notification mechanism to our users, I feel like it would be a lot simpler to forego XMPP for now and just roll out a site-specific solution. K.I.S.S. is a strong motivator here; integrating an XMPP server into our site would require a big investment into learning the internals of the server. I could always add a gateway to XMPP if needed down the road.
Granted, this is what XMPP was made for. I've read a lot of Metajack's posts about how Chesspark used it throughout their site, though they've used XMPP as a core part of their architecture.
Should I go with my instinct -- keep things simple and reuse our push architecture to add the messaging system, or should I dive into XMPP and try to mold it to the requirements of the site?