51 Comments

Summary:

The instant messaging world should prepare for a major quake — thanks to Facebook, which seems to be all set to launch a new connection interface that would allow Facebook Chat to work with any kind of XMPP client. The news of this development was first […]

facebookchat.gifThe instant messaging world should prepare for a major quake — thanks to Facebook, which seems to be all set to launch a new connection interface that would allow Facebook Chat to work with any kind of XMPP client.

The news of this development was first reported by Mickaël Rémond on the company blog of Process One, a Paris-based messaging startup. “It now seems the launch is close as the XMPP software stack has been deployed on chat.facebook.com,” writes Rémond, who is a leading expert on instant messaging and ejabberd and is an active member of the XMPP Standard Foundation.

About a year-and-a-half ago, Facebook had announced that it would build “a Jabber/XMPP interface for Facebook Chat” and that “users will be able to use Jabber/XMPP-based chat applications to connect to Facebook Chat to” communicate, check their friends’ profiles, and set their statuses.

Extensible Messaging and Presence Protocol, or XMPP, has surely become the de facto standard for messaging and presence. After a big push from Google Talk, XMPP is going to get the next major push from Facebook. The world’s largest social-networking service, with over 350 million subscribers, is about to launch the XMPP connection interface. That will allow users to use Facebook Chat with any XMPP client — whether on the desktop or mobile. A good example of how this works is Adium, a popular open-source IM client that allows you to communicate with disparate IM networks. The latest version of Adium supports Facebook Chat.

Why is this news disruptive? Simple: Until now, in order to use Facebook Chat to communicate, one needed to be logged into the Facebook web site or mobile service. However, if the chat can be accessed on any device regardless of whether you are logged into Facebook’s web site, the usage of that IM is only going to increase. This would, in turn, mean tough times for older IM networks such as AOL’s AIM and Microsoft’s MSN.

To understand why independent Facebook Chat on the web (and on the wireless networks) is disruptive, just take a look at its amazing rise. It was prototyped in January 2007 at a Hackathon and become a real project in the fall of 2007 with four engineers. In April 2008, the service went live for consumers and was available to 70 million Facebook users at the time. As of September, nearly a billion user messages were being exchanged every day with 1GB traffic at its peak, according to a presentation made by the Facebook development team at a conference in Edinburgh in September.

howfacebookchatworks.gif
  1. But I’ve been using Facebook chat for quite a while now on my mobile using Palringo, that’s not logged into the web page or the mobile site is it?

    Share
  2. This might turn out to be a bad thing for facebook as people will no longer need to login to facebook to chat with friends. The point of having facebook vs. other independent services is that, it gives users single place where they can go and socialize.

    Share
  3. I love the fact that push-based/pubsub protocols are coming to the forefront. I must say it’s somewhat baffling XMPP has been the leader of the pack. Their strength is a strong developer community starting from the old Jabber days. From a protocol design perspective it’s a bit of a disaster, though. To start with, why is it XML? I understand text-based protocols are easier to understand and all of that, but we’re talking about a protocol that’s specifically used to transport small messages. In that context, header size matters a whole lot. With XMPP, it’s common for the headers to be bigger than the message.

    HTTP is also text-based, but it’s a completely different story because HTTP message bodies tend to be far larger than the header size. XMPP piles on top of it XML — not only is it text based, but it chooses to pile a whole bunch of XML on top of that. Yikes!

    I really wish developers were more versed in writing binary protocols. It comes back to the age-old lesson: usability always wins. Even on that score, though, PubSubHubbub is even simpler, less, verbose, not a new protocol (all HTTP), etc etc. See:

    http://code.google.com/p/pubsubhubbub/wiki/ComparingProtocols

    I find this all a bit disheartening for some reason, even though it’s overall good news!

    Share
    1. … sounds like wrapping APIs in SOAP when AJAX (then JSON/REST) became more than enough

      Share
      1. Agreed — PubSubHubbub will hopefully do to XMPP what REST did to SOAP. I don’t think XMPP’s quite as bad as SOAP is (better in some respects, worse in some respects), but it’s in the ballpark.

        Share
      2. Agreed as well

        Share
    2. My feelings for you are complicated. You make a couple of good, or at least argument-worthy, points (XML+HTTP might be overkill, there are better text-based protocols than XMPP) and yet, you manage to get a really, really bad one in there (that we should start writing binary protocols). Not sure whether to consider your arguments or whether to repeatedly smash my head against my keyboard and monitor while screaming “BINARY PROTOCOLS”. Hmmm…. ;)

      Share
      1. My feelings for you are not complicated. You seem to be attacking my position that binary protocols make more sense when protocol payloads are small. You’re argument against that position seems to be something about smashing one’s head against a keyboard and that my point is “a really, really bad one.” Strange argument.

        Note that all the really slick, super efficient new protocols out there are binary: avro, protocolbuffers, thrift, etc.

        If you have an articulate response to my point, I’d love to discuss it. My perspective could easily be wrong. I have a lot of experience with protocol design, however, and that’s my feeling about XMPP. Not sure what yours is.

        Share
      2. Woohoo, we’re nested too deeply here for me to reply directly to you. Cool.

        > Strange argument.

        You’re a smart person, and I suspect you know better than to think that I was suggesting that “this makes me want to smash my head on my keyboard” was actually an argument against your point. It wasn’t. That’s just how I feel about binary protocols, or at least the instinctive desire to resort to them.

        > “Note that all the really slick, super efficient new protocols out there are binary: avro, protocolbuffers, thrift, etc.”

        Well-designed binary protocols are more efficient, at least for that very narrow definition of “efficient” whereby bandwidth usage is the only consideration. I’ll happily give you that point, because I’d never argue against it.

        My point, if I have one, is that efficiency is overrated. Yup, you might be talking a kilobyte or maybe even two of protocol overhead per message for an application like this. That is surely the end of the world; the two people who are still using 56k modems might, just might, notice messages taking a fraction of a second longer to send, if those gains aren’t swamped by latency anyway.

        > You seem to be attacking my position that binary protocols make more sense when protocol payloads are small.

        Well, payload *sizes* aren’t important (extreme example: how much more efficient would IRC have been if it had used a binary protocol? How much less robust would the implementations have been if it did?). There’s a case to be made for either text or binary protocols regardless of payload size. I do insist that someone demonstrates that a text-based protocol, even a bloated one like XMPP, causes *noticeable* inefficiencies, in the real world, that outweigh the many, many benefits of protocol transparency, before we resort to using binary protocols.

        I probably disagree with you less than it might seem. :) Even though XMPP makes me twitchy too, it still seems like a good choice in this case, if only because it’s so widely implemented in IM clients…

        Share
      3. A couple quick points:

        1) Binary protocols don’t only save bandwidth. They typically also save CPU and memory.

        2) These protocols are rapidly becoming a part of the core Internet fabric. As such, they’re starting to see massive volumes of data passing through them, and this going to grow as companies like Facebook make greater use of them. As such, performance is a vital concern. Better protocol design would save everyone a great deal of time and money, with ultimately better performance for the user.

        3) Binary protocols are not more error prone. You could certainly make an argument either way, but binary protocols tend to be more explicit in what they allow for each byte. To me, they’re less error prone.

        4) The only upside I see to XMPP being text based is that more people can write XMPP applications. When it comes to XMPP servers processing the kinds of volume Facebook and Twitter and processing, though, you’re talking about highly skilled engineers that could just as easily write binary protocols as they could text-based protocols. If they’re not good enough to do that, we don’t want them writing our XMPP servers. On the client side, I think what you’re saying makes sense. It should be easy for people to write clients, and not all of them should necessarily be comfortable with writing binary protocols. So it’s certainly a tradeoff. To me, though, we should just go all the way and design the best Internet possible now.

        Share
      4. 1) Citation needed. Prove that it’s an issue on modern computers. I’m sure Facebook and Google will give you a call when they run out of CPU cycles.

        2) See “citation needed” above. Like anyone’s going to notice a few kilobytes of XMPP transactions above the shitstorm of multi-gigabyte HTTP and BitTorrent traffic that most . Show to me that it’s a real-world issue. Then we can talk.

        3) That’s where you show me that you’re an excellent protocol *designer*. You work out the rest. ;)

        4) Don’t sniff at the value of anyone being able to implement XMPP. Yes, if you’re working at Facebook or Twitter, you could probably make some really compact binary protocol and have all your engineers understand it etc etc. Great stuff. Not get that out into real-world implementations, built by amateurs who have better things to do, and that won’t count for shit.

        Share
      5. by the way, “that most” above was part of a stray thought that I didn’t finish, and didn’t copyedit. oh well. :)

        Share
      6. I really don’t mean to show any disrespect to the hard work of the XMPP protocol designers. Like I said, the addition of XMPP is a huge improvement over the existing Internet and opens up many exciting possibilities. I do think it could be better and that some of those initial design decisions could have been better, however. Again, I could be convinced otherwise and admit to being frequently wrong, but that’s my view.

        As far as a “Citation needed” about modern computers running out of resources as a result of these issues, I think that’s a non-starter. For the volumes of data we’re talking about, you’re clearly in the realm of running many many boxes to get the job done. If you have to run fewer of those boxes to get the job done with a more efficient protocol (again, less CPU, memory, bandwidth), you just save money, electricity, space, etc. So I guess I’ll just cite common sense, which to me is always the best citation!

        Share
      7. I suppose you write your protocol parser in assembly language, too. Cool.

        Share
    3. OMG, will I really receive my messages a millisecond later because they send my 100 bytes of XML header?

      SCNR… :-)

      Share
    4. “With XMPP, it’s common for the headers to be bigger than the message. ”

      Last time I checked, XMPP didn’t have any headers in the HTTP sense of the term… Are we talking about the same XMPP ?

      “HTTP is also text-based, but it’s a completely different story because HTTP message bodies tend to be far larger than the header size.”

      Guess what ? It takes quite some time to setup a TCP connection. And I guess you already know that the connection gets teared down and re setup many times in an HTTP based architecture.

      “XMPP piles on top of it XML — not only is it text based, but it chooses to pile a whole bunch of XML on top of that. Yikes!”

      Did you get the XML flu or something like that ?

      “I really wish developers were more versed in writing binary protocols. It comes back to the age-old lesson: usability always wins. Even on that score, though, PubSubHubbub is even simpler, less, verbose, not a new protocol (all HTTP), etc etc.”

      This sentence doesn’t really make much sense does it ? You start by praising binary protocols, and then start talking about PubSubHubbub which let me remind you is not binary, but rather a set of hacks built on top of the venerable Text based HTTP protocol…

      Please can you quit talking nonsense ?

      Share
      1. Thanks for letting me know HTTP is text-based and what I’m referring to as headers are really more properly called wrappers in XMPP land. That added a lot to the conversation — really getting to the heart of the matter. It’s also useful to know you’re unaware of persistent HTTP connections. Thanks for all of that, really.

        Share
      2. Ali and Lewis Collard,

        Text based protocols may seem easy but often leads to unnecessary complexities. For the sake of human readability, protocols that start out simple at first eventually gets bloated and overly complex. Just look at the WS-* protocol stack if you want an example. And not to mention characters being garbled because the creator of some homepages didn’t bother to define the charset.

        While we have problems like endianness in binary communications, text encoding is no simpler and can also be ambiguous which causes hidden headaches and sometimes nasty security holes too. I guess you must prefer something which seems easy at first but is hard to validate until runtime. Script kiddie mentality.

        Share
  4. is this just about clients? or will facebook users be able to chat with gtalk, etc.?

    Share
    1. yes this is indeed about the clients mostly. I am sure it would allow facebook chat to be embedded in different applications.

      Share
  5. Who cares? Facebook chat is already implemented in Digsby.

    Share
    1. i’m pretty sure the implementation used by digsby is a https screenscrape of some sort.

      Share
    2. yeah Digsby rocks

      Share
  6. and in Pidgin for god knows how long

    Share
  7. [...] and could breath new life into Instant Messaging but for a really good answer one just has to read what Om Malik wrote about the news to understand why Why is this news disruptive? Simple: So far in order to use the Facebook Chat to communicate, one [...]

    Share
  8. [...] more from the original source:  "Facebook Pokes XMPP. MSN, Yahoo & AIM Better Watchout" and related posts Comments [...]

    Share
  9. Everyone who uses Facebook chat in Pidgin, Adium or Trillium will know exactly how great news this is. Facebook has had issues with connections and multiple logins. (Running an IM client logged into chat, while trying to access Facebook.com in a browser). Basically, you’ve been plagued with disconnection problems, missing messages, duplicate messages, and errors while sending.
    Facebook chat moving to XMPP is going to be AWESOME. All of our favorite universal chat apps will probably run flawlessly now. This is great news.

    Share
    1. I completely agree, Jason.

      Share

Comments have been disabled for this post