More on Google Talk and passwords

On catching up with the articles that appeared on Slashdot over the Bank Holiday weekend, I was particularly interested to find a link to this Live Journal entry. It’s by someone who shares my concerns about Google’s failure to open Google Talk to other Jabber servers. Interestingly there’s also a paragraph in which he mentions that one advantage of Jabber using distributed servers is that you don’t end up with stupid usernames like johnsmith12345. Sound familiar?

Unfortunately a lot of the Slashdot comments seem to miss the point entirely. Many of them were keen to let Google off the hook either because Google Talk is still in beta, or because of their claim that they will federate (Google’s choice of terminology) with other selected instant messaging services. So let’s deal with these justifications one at a time.

It’s still a beta program, they’ll probably add server-to-server connections in future

Google tends to leave the beta label on their services far beyond the point where most people would consider them production ready. Gmail is perhaps the archetypal example which has been in beta since its inception in April 2004, despite no obvious new features having appeared for several months now. So the fact that Google Talk is in beta doesn’t necessarily mean that it’s not considered feature-complete.

Unless Google specifically say that they’ll be adding proper server-to-server connections according to the XMPP specs, any speculation about whether or not it will be added in a later version is purely that: speculation.

There’s a section on Google’s developer pages that says they’ll be federating with other servers

The beauty of Jabber is that anyone can run a server. A company could set up a server to allow their employees to message each other without having to worry about trade secrets leaving the company network. Conversely that same server can relay messages to the rest of the Jabber network to ensure that the employees can still chat with their friends, customers or suppliers who use other Jabber servers. It doesn’t matter whether the company has five employees or five hundred, they are all equal to the other servers and users of the Jabber network.

Now whilst Google may be prepared to federate with some of the larger Jabber servers, will they really want to federate with every five user company that requests it? Unless they’re prepared to federate with everyone, they’re still fragmenting the Jabber network into those users who can communicate with Google Talk users and those who can’t.

But let’s give them the benefit of the doubt and assume that they will federate with everyone. This in itself sets a dangerous precedent: if Google can restrict their peering to authorised servers, then why shouldn’t every Jabber server apply similar restrictions? Why shouldn’t the five-hundred user server of Big Pond Ltd. also require every other Jabber server to specifically request that they be allowed to communicate with them. And where does that leave the five user server of Little Fish & Sons, whose administrator now has to ensure that they have federated with every Jabber server they are ever likely to have to talk to?

The XMPP protocol is open and available to everyone for a reason. The reference Jabber server will pass messages to other servers in the network without requiring a prior agreement for a reason. Google Talk ignores these reasons and chooses to go it alone, creating yet another closed system.

Whatever may happen in later releases is purely speculative at this time. Requiring system administrators to specifically request that their servers be allowed to communicate with Google is not only impractical and arrogant, but also places one foot on a potentially slippery slope.

Whatever the Slashdot aplogists may think, this is a problem, and it exists right now. Come on Google, prove the “it’s only a beta” crowd right, and fix the problem. But please do it quickly, before the instant messaging world fragments even further.