

Should I use XMPP for my startup's messaging system? - shutter

The [web] startup I'm working on will need a user-to-user instant messaging system of some sort. A system that allows users to have lists of contacts, and then send messages back and forth, with a little presence information. It will need to be web-based, but relatively simple (like Facebook Chat, for instance).<p>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).<p>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.<p>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:<p>- 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.<p>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.<p>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.<p>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?
======
metajack
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.

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

------
diggydo
Meebo is soon releasing its "Community IM" product. Might want to check it
out. <http://www.meebo.com/communityim/>

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

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

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

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

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

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

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

------
known
<http://www.ajaxim.com/>

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

