MadMode

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.