On Google, Jabber, and Jingle and good and evil in IM and IP networks
The 14 December jingle announcement gives a hint into google's approach to adding voice to their Google Talk offering. Actually, it gives quite a bit more than a hint; it comes with a jingle spec and an open source library implementation.
Google Talk has had pretty good "do no evil" karma since it started. The dominant commercial IM services (AOL/Yahoo/Microsoft) are each a world unto themselves. Your AIM screen name is just jim47 or whatever, not jim47@aol.com like an email address, and while clients like trillian and gaim can connect to them all, that's not something the big three encourage. Google Talk uses gmail addresses and the Jabber/XMPP protocol, which has the same network topology as email. While google isn't opening their service to actual server-to-server federation until they get a better handle on some operational issues (think: spam), they are using open protocols and they actively support gaim development.
Apple's iChat uses Jabber at some level too, though I haven't worked out the interoperability issues in practice. I think the last time I tried was before the Tiger release of OS X, when the Jabber support was much more under-the-covers.
The popularity of multi-protocol clients like gaim and trillian surprises me: after all, you can't have one chat room with AIM and MSN messenger users connected. Evidently this just not a big deal. "IRC and instant messaging are very different paradigms," says the Adium X: IRC Howto. I guess I'm just too old school to get it; in the internet relay chat usage that I'm used to, channels (aka chat rooms) are the norm and private channels are the exception. I gather IM is the other way around. I have played with Jabber's support for bridging to other networks, but I have yet to find a reliable combination of:
- a jabber client with bridging support that I can figure out how to use
- and either
- server software with bridging support that I can figure out how to use, or
- an existing service with bridging support that I can use and trust (since my credentials pass thru their service)
The Jabber protocol has lots of pieces and extensions an such. There's a whole JEP process, in addition to the XMPP process where jabber technology feeds into the IETF. I don't quite have my head around the whole thing. I discovered that there are older and newer protocols for doing chat rooms in jabber that don't mix well. I wonder which of them, if either, the IETF has endorsed. An XMPP summary shows JEP-0045 for Multi-User Chat but no RFC. And I don't see XMPP among IETF Working Groups any more. I wonder what's up. The xmppwg mailing list archives show pretty recent activity.
The $2.6Bn aquisition of skype by Ebay shows the value of networks of IM and voice users. Skype has a novel topology based on the same p2p designers that did Kazaa. As I understand it, they mostly use the p2p network for firewall traversal, which is the biggest problem, in practice, with deploying consumer voice chat. They keep the protocol details to themselves, though, and they have the only implementation, as a consequence. They have a centralized user directory too.
In my visit to the 62nd IETF in Minneapolis, MN, I learned what a sore spot firewall traversal is in Internet standardization. "Just use IPV6 and don't waste your time with those kludges" goes the one side; "but NAT works today" goes the other. Ugh. And since W3C started working more actively with developing countries, I hear more about the political aspects of IPV6. In the 1st world, we can dismiss claims that IPV4 addresses are running out as technically overblown, since we can afford to pay for the management fees and the NAT boxes. But the scarcity is a real economic issue in the developing world; plus it concentrates power in a way that engenders distrust.
Back to network topologies... the fact that Jabber has the same topology as conventional (SMTP) email means that it's subject to the same sorts of spam issues. I wonder if anybody has considered the IM2000 approach of redesigning the mail system as a pull delivery rather than as a push delivery system, so that recipients no longer bear the costs of receiving and storing unwanted messages. In an IM2000 world, senders have to hold still long enough to deliver a message, which makes it much easier to hold them accountable for nastiness.
Here's the lay of the land from my perspective as putative leader of the Jabber community:
1. XMPP (RFCs 3920-3923) is the IETF's formalization of the core Jabber protocols (mainly designed within the open-source Jabber projects back in 1999), where formalization involved updated security bits (TLS and SASL) and some improved internationalization coverage (BTW, all Jabber addresses are fully i18n-friendly and can contain virtually any Unicode character -- coming to email in 2020 or so).
2. XMPP extensions are not defined in the IETF for many reasons, not least of which is that we'd be wasting IETF bandwidth on things like avatars and other application-specific functionality. This is why the xmppwg list is quiet -- we shut down the XMPP WG once we were done with the core specs.
3. We define XMPP extensions through the Jabber Software Foundation's JEP series. This works well. No need to send every last XMPP extension through the IETF, faster document updates, etc. So all the traffic and activity is at the JSF these days, not the IETF.
4. Groupchat (a la IRC) has never been the main focus of the Jabber community. We have only one groupchat protocol, defined in JEP-0045. It is backwards-compatible with an older, less featureful protocol we put together in 1999. JEP-0045 has not been approved by the IETF (it's a JEP, not an Internet-Draft or RFC), but I can tell you that there are multi-user chat rooms up and running for all IETF working groups over at the ietf.xmpp.org chat service, and they get a fair amount of use.
5. Jabber/XMPP does not primarily provide gateways to the consumer IM services, we're too busy building out a better technology for IM, presence, and real-time request-response functionality.
6. Jabber/XMPP is fundamentally a technology for streaming XML. I know I know, it seems odd from the W3C perspective (Tim Bray told me once that "I wouldn't have done it that way"), but it works well for a wide range of applications beyond IM, including workflow systems, network management, content syndication, gaming, even transports for XML-RPC and SOAP.
7. Jingle is a set of XMPP extensions for doing multimedia signalling / negotiation over our streaming XML channel. We go out of band (typically using RTP) to do the heavy lifting of the voice/video/etc. transport itself. Not that dissimilar from how things are done in the SIP world, except we require authentication and effectively prevent address spoofing, thus avoiding many of the security problems related to SIP.
8. Jabber/XMPP most definitely does not have the same spam issues that SMTP has, despite having a similar (client-server) network topology. We *require* authentication to get on the network, we *require* servers to stamp "from" addresses on all packets (no address spoofing here), we *require* servers to at the least perform reverse DNS lookups before accepting data from other servers (or do TLS with certificates), etc. Plus we have an extremely diverse client ecosystem (no obvious attack vector), a pure XML transport (not friendly to binary worms and viruses), a very retricted set of allowable XHTML formatting (an official XHTML subset that we worked on with some W3C guidance), and so on. We do not have spam on the Jabber/XMPP network (thousands of servers, millions of users, growing organically since 1999). We don't have viruses or worms or other malicious content either.
9. Yes, Google is indeed opening their Google Talk service to federation with the rest of the Jabber/XMPP network. They wrote their first release without server-to-server support. It's coming soon to a public network near you.
10. Yes, iChat natively supports the Jabber/XMPP protocols in Tiger. The pre-Tiget support was only in Rendezvous (now Bonjour) mode. In Tiger, you can connect to any accessible Jabber server if you have an existing account. And yes, that includes connecting to Google Talk. Open standards are good, no?
That's the short version. Email or Jabber me via stpeter@jabber.org if you have more questions.
Hmm... so the lack of federation in google's service is not about spam, OK.
I wonder if firewalls are much of an issue for jabber... I suppose they're not much of an issue for email, which suggests they shouldn't be for jabber. But I still wonder if they require any special attention in jingle. I'll have to take a closer look.
Dan, the AdiumX IRC howto URL has changed: http://trac.adiumx.com/wiki/GettingOnIRC
Can you arrange for a redirect? I'm sure I'm not the only one who has linked to the old location.
I have no control over the adiumx.com domain, but I dropped them a ticket.
Jabber works nicely in iChat on Mac OS X Tiger. But, I use both PSI (which is cross platform) and iChat.
iChat doesn't have much interface for setting up a Jabber account or registering with gateways (services) into the other IM networks, but is a nice interface for chats. PSI has interfaces for all of the Jabber configuration stuff (plus a way to read/write raw XML in Jabber streams).
It works as the Poster Jay says
See here jabber.org.au
and here Allforces for Transports and Gateway info.
Ralph
I believe Jabber has great potential. It has a way to communicate with other networks but as the Jabber web site explains, it is meant as a transitional only solution, one that will fade away with the other poor privative protocols of course.
I believe Jabber has potential to replace every other network of IM out there, it has the potential to replace IRC. The specifications for chat rooms is very good, there aren't very good implementations yet, but we are getting there.
I believe it has the potential to replace email with the email-like messages you can send. It would be nice to have one homogeneous way of communicating with everybody. Of course, clients should be changed for jabber to be useful in place of an email client.
Furthermore since Jabber's protocol is so extensible (much more extensible than that of other IMs, email and IRC) there's a big chance of getting new unexpected extensions/usage in the future.
I have stopped using any other IM network than Jabber years ago and I written a short article about why we should all use Jabber.
Yes, jabber has great potential. And yet, I see a wikimedia board meeting on IRC, Ubunutu doing its business on IRC, gnome, debian, and so on. Where is the equivalent of freenode for Jabber? or why doesn't freenode support jabber?
See also: JabberChickenEgg in the ESW Wiki.
Dan, I think you have outlined the biggest "problem" with Jabber: it is a philosophy of one on one chats, group chats don't seem to be in focus. And as communities we tend to see all in a room/channel, trying to meet all the others. I moved over to jabber with some fellows of mine and we set up a group chat to hang out, still after two years the majority of messages goes through the group chat, not private messages.
The jabber folks at least gather in jabber. I think Jabber's momentum won't come from chat-rooms like IRC, it'll come from one-to-one messangers. When it gains enough momentum there, it'll be able to get enough momentum on chat-rooms to replace IRC.
Interesting... Sep 2005 discussion of bridging irc.freenode and jabber.org.
I wonder how the security issues would work.
In fact, I don't even know how the jabber MUC protocol works. Does anybody have a nice comic-book level explanation? Some slides, maybe?