Peter Saint-Andre - interview

From LXF Wiki

Talking up a storm

Not content with uniting the instant messaging world, Peter Saint-Andre thinks Jabber can go a lot, lot further.

Although it came out of the no-frills world of instant messaging, there's a great deal more to Jabber than just writing words in a box: over the last 18 months, Jabber has hit the big time. It's the protocol behind several open source IM clients (including Gaim and Kopete) and Google's instant messaging service, Google Talk, while Apple has embedded Jabber support within iChat and LiveJournal has launched a Jabber service. For Peter Saint-Andre, the executive director of the Jabber Software Foundation, this is just the beginning. Graham Morrison caught up with Peter in RL (that's `real life' readers) to ask him about Jabber's potential and why open standards are important ­ all without a single pun on rapid, indistinct talking.

Linux Format: Could you tell us how you got started with Jabber?

Peter Saint-Andre: Well, I'm not the guy who invented Jabber. The guy who invented Jabber's a guy named called Jeremy Miller. He lives in Iowa ­Cascade, Iowa, which is about 45 minutes outside the metropolis of Dubuque, Iowa. He was tired of running four different IM clients and not having interoperability.

LXF: When was this?

PSA: This was 1998 when he really started working on things. So he decided to write a server. He was not a client developer of any kind, so he wrote a server in C and released it on 4 January 1999. It went out on Slashdot and a lot of people got interested. It wasn't just a server project ­ 'cause you can't do anything with just a server, right? ­ and other people started to write clients, libraries and other components that they could do. Part of the intent was to have a server that was very extensible and modular so that people could write gateways. So people wrote a lot of gateways to things like Gaim and MSN and other things.

LXF: Was it important to have that openness right from the beginning?

PSA: Much of the original impetus was to develop these gateways and to talk to other systems, and that was really the philosophy of freedom of conversation that was behind Jabber: we shouldn't have to wait until someone decides that we can have a conversation; we should be able to have a conversation on our terms, right? So freedom of conversation was really a big idea in Jabber from the get-go. There was a two-pronged approach that Jabber has always had. We'll have these gateways on the server side so we can talk to MSN and AIM and all these other kinds of people. And then we'll also develop open technologies that we can use ­ that anyone can use ­ so you can download your own server, you can run it yourself, ISPs can use it, companies can use it behind the firewall if they want to. We'll let people do with it what they please. You know, NTT does stuff [with Jabber] and a lot of the ISPs run it now, big ISPs: service providers like France Télécom and Orange over in the UK.

LXF: They use Jabber?

PSA: They use Jabber, yes. They probably have some sort of server-side gateway that they've written.

So what happened was, Jeremy wrote the server and then a lot of people started to write clients. We have very much of a client­server architecture, it's very much like email. You have an email client ­ Thunderbird or Outlook or whatever ­ and then there's an email server, which could be Exchange or Postfix or something like that. So when you have a client­server architecture you need protocols to determine how the client talks to the server and how the servers talk with other servers, right? In the email world that was defined very early on, through the Internet Engineering Task Force. We didn't have that in IM; IM was just these closed systems, these closed silos: "Oh, you're on AIM" But who knows what AIM is, right?

LXF: Yeah, everyone had to reverse-engineer the protocol.

PSA: Right, and that's what the gateway developers did. But at the same time we also developed our own open standards for these wire protocols. Over time the focus in our community has become more on these protocols.

LXF: Solely as standards, or with the intention to implement them?

PSA: As standard protocols that we've defined. So actually I wrote the documents that we've published with the Internet Engineering Task Force so we have RFCs that we can develop. When Google Talk decided that they wanted to use Jabber for IM, they didn't have to buy anything from anyone, they just wrote their own implementation.

LXF: Did they get in touch with you at all over it?

PSA: Oh yes, they were in touch. And LiveJournal did the same thing. They said: " You know, these other servers that are out there are not quite what we want. We want to write something that's very modular and extensible and kind of shouldn't have a lot of stay and is very pluggable and is written in Perl" , because they have a lot of Perl guys. So they have a lot of different servers. There are servers in Perl, Python, Java, C, C++, Erlang...

LXF: All reimplementations of the same protocol?

PSA: Yes, alternate implementations of the same system, same technology ­because we have good protocols.

Then we have lots of clients. You know, Apple's iChat: when I'm chatting with you in IM, it's iChat, because iChat has support for it. The Google Talk client does the same thing. You can connect any Jabber client to Google Talk, because it's using open standards. You might have clients on phones: there's this one called Chatopus, which is on the PalmOS.

LXF: So iChat hasn't taken any of your code at all ­ the developers just wrote their own code according to your protocol?

PSA: They are implementing our protocols, which are all standards now, and they just wrote their own implementation.

LXF: Is Jabber the client­server application, or is it more the standards and the protocols?

PSA: It's really more the standards and the ecosystem, because we have a lot of code out there that people can use, but we also have a network ­ there are thousands of Jabber servers running on the internet. Google Talk is a big one, and so on and so forth, but there are little ones in Russia, there are people running small servers in Australia, and there are servers all over the world.

LXF: How do the servers communicate with one another?

PSA: Because we have open standards. We have technologies for, "OK, how does my server talk to your server when I want to initiate a connection and we do this reverse DNS lookup to determine that you really are who you say you are?" which is one of the reasons we don't have spam on our network. And we also have very good internationalisation... we're not all ASCII people; we're not all in the US. There's plenty of people with other character sets. We have full support for that, both for messages that flow along the wire and also for addresses, which is really kind of cool, because people in Japan find it really nice. The problem is that email has been around for so long that it's very hard to retrofit these improvements, but we went back and fixed all that when we developed our protocols.

LXF: Is that partly why you prefer Jabber over email communication?

PSA: Yeah. Well, there's no spam. We don't have spam. And so when someone communicates with me, they're not some unknown entity, they are a known entity on the network. Partly that's because we're not as popular as email is yet: there are only probably 30 million Jabber users or something like that, so we are not the low-hanging fruit ­ it's much easier to attack the email system. We don't have to be perfect, we just have to be better. We don't strive for perfection because it's just not worth anyone's time to strive for perfection.

LXF: When you first got involved did Jabber have this broad scope?

PSA: We have built more extensions over time. Originally all we really had was instant messaging, built on a substrate [base] of pure XML routing.

LXF Right, so the messages were all embedded in XML.

PSA: Because XML is extensible we can send other payloads over Jabber; we can send SOAP. We can send event notifications for blog updates. We can do all this kind of stuff, so over time we've built out more of this kind of infrastructure of the kinds of data that we can send. That could be geolocation, it could be information about what tune is playing in iTunes or on your computer, those kinds of things. We can push out that kind of information and build out a richer experience. But... originally we built up this kind of substrate of the XML messaging, and then over time we have built out a lot more extensions to that, to be able to do more interesting things.

LXF: How have you personally seen Jabber change since you started working on it?

PSA: What I see, and if you look at history, is people want things faster and faster. You probably remember the old TV ads for Fedex, when it absolutely, positively has to be there overnight. Well, come on ­ that's so eighties now! The trend over time is towards faster and faster communications.

LXF: Another thing to change is people like Apple, Google and Sun now have their own Jabber servers! Are the Google guys putting much back in

PSA: Well, again, we're working on standards, so one of the things that companies seem to appreciate about our community is that it doesn't force them to open up their source code. All we're doing is saying, "Hey, here's the standards." They actually did provide a library, like a very OpenBSD-style licences library that does all the Jingle stuff. So you can just embed that in your client, you can embed it in an application, and a lot of people have already done that. They have given back in terms of code as well, but my ma effort is concentrated on helping Google to define our standards so that anyone can develop against them.

LXF: Who came up with Jingle ­ adding VoIP support to Jabber?

PSA: What happened was, I was going back to some early mailing list posts recently from 1999 and people were saying, "Where's the voice chat?" It wasn't really a priority for us at the time, because we were working on ITF (1723) and trying to standardise the core technology. Then a guy named Joe Hildebrand and I kind of came up with some versions and how we could do the voice chat, and then we published another version of it and the Google guys said, "Hey, this is pretty similar to what we're doing ­ let's pool our efforts and develop a standard together and let everyone connect" We're working to iron out some bugs in there and make it something that's easier for us to use in the long term.

LXF: I imagine it's not that important that the user knows that iChat is using Jabber, or Gaim is. You'd rather that were left to the people who ­

PSA: Right. When you use email you don't need to know about SMTP and IMAP; why should you need to worry about that stuff? That's the point that we're trying to get to.

LXF: What are the big projects that are extending the XML inside Jabber and using it for their own purpose?

PSA: We have one project with the Google Summer of Code ­ actually two projects, because one is with something called Inkboard and they're doing whiteboarding, but we've also got all the voice and video happening. So those are some of the big things that are happening right now. There's this thing in the UK called TrackM8, and they're using Jabber geolocation extensions in order to find out where lorries are on the highways and the ports and stuff like this. They run their own servers, so these trucks check in with the server every once in a while, like every half an hour or so, and if the truck's in the wrong place, maybe it's been stolen or something.

There's a company in the US that presence-enabled [sic] the network diagrams of their networks, so you can see if the Cisco router's up or down, and chat with the Cisco router. What do you do when you chat with the Cisco router? "Hey, what's your uptime?" "What's your throughput?" Things like this. It's nothing to do with instant messaging at all, it's all these extensions for being able to do whatever you please. I don't know if I even know what some of these things are, because people are just developing them on the edges.

LXF: Do you think that Jeremy knew Jabber would become this big buzzing technology that it is now?

PSA: We always knew that there was a possibility for that. Part of what I see as contributing to the success of open source projects is just persistence. I don't know who said that 90% of life is just showing up ­ I think it was Woody Allen, right? We've just kept at it. We've kept working at this since 1999, going to keep working on it for years to come, because there is a lot of potential. I mean, you think about some of the systems that you use maybe like Plazes or Last.fm, or maybe some of the other Web 2.0 things, and they could all be using Jabber for some interesting stuff. Sending out geolocation updates, like, "Hey, Peter's in Portland today!" If someone could subscribe to that and get a feed of where I am, or the tunes that I'm listening to on Last.fm, why not push that out and have a real-time feed, so people could say, "He's listening to Aretha Franklin right now; I'm a big Aretha fan, let me chat with him about Aretha!"?

What I see coming is much more of a real-time internet. It's not a static web any more. Yes, we've got RSS and I can know that you've just posted something five minutes ago and those kinds of things. But why can't I know that it says that you just blogged about something, why can't I know what you're listening to right now or you're watching a movie I like? If you want to and we're share that out in a selective fashion with your friends, that is just another catalyst for communication, a catalyst for interaction. You may not want to share everything that you're doing, you may not want to share that you're in a certain group or on a certain website or something like that, so there needs to be filtering and control and you need to be the one who has control over who gets to see what. We've got very good technologies for doing that. We can publish all that information in a sort of selective fashion, and you can provide more context to people for what you might be interested in talking about.

LXF: And that's the way Jabber is going? Opening up into all these different avenues?

PSA: I think so, because we are sort of a substrate for all those vast communications. And Jabber is not like the MQSeries and fancy middleware systems. It's just IM; it's pretty easy, simple stuff to deploy and to use and it's not something that you have to conform to. There's such a great possibility for sending around all sorts of information. If you were a sales manager wouldn't you love to know that this big sale just came through and not have to wait until it goes into some reporting system? So I think people are going to want that information faster and faster because they can make better decisions. LXF