When I first heard about Jabber, it blew my mind. I've always thought that what we call ``instant messaging'' is based on notions of real-time communication that are both rudimentary and ill-conceived. They all look like stuff that big, controlling companies foist on zillions of consumers for the purpose of hooking them into a proprietary environment where they can be zapped with advertising. Worse, they are not Net-based. They might run on the Net; but they are, with the single exception of IRC, private affairs. Until Jabber, there was no way to deploy instant messaging on the Net in the way we deploy e-mail or web servers. Nothing was truly open, and nothing was open source. Jabber is all that and more.

Not long ago, I had a chance to sit down and interview a few of Jabber's prime movers:

Jabber is still newer than new, which is to say it isn't out yet, although you can download it from Jabber.org and play with it--or better yet, jump in and help develop it. I've had fun talking with the Jabber people, and invite open-source developers to do the same. I'm very interested to see if you agree that this is an extremely auspicious movement: something on the scale of a Mosaic, a Sendmail, an Apache or maybe even a Linux.

Doc: Jeremie, was this your idea in the first place?

Jeremie Miller: Yeah. Basically. I don't know if it's really unique, but it's turning out unique. It started back in early 1998. I worked in an ISP, and I was playing around with other chat clients. We were using IRC, ICQ and Excite for a while. It was starting to catch on in the office. I didn't even know about [AOL's] AIM, really. I wasn't in the Windows world too much.

Doc: You were a UNIX guy?

Jeremie Miller: Yeah. But I found that more of the people I knew were fooling around with AIM, and I ended up having a need--to have all my UNIX utilities, all my logging stuff, much of the UNIX environment--wanting to use this new ``buddy list'' interactively in real time. I wanted to be able to use this buddy list as a channel to feed my stuff through. Later on, I saw there were open-source libraries to get back into ICQ and AIM and stuff ... so I thought about it for a couple weeks. The question was, ``What's the best way to do this?'' I didn' t want to build my own client, because I can't do GUI stuff at all. I can only do back-end server stuff. I thought I could build a back-end server and make my own protocol, then maybe convince somebody else to write a client, and they wouldn't have to update it when I wanted features. I just start adding all the features into the server. That way, I can bridge that server to my UNIX things I want to add in--some logging announcements and any sort of little things I want to push up into it. I can have that server bridge over into pagers. I can have it bridge into ICQ and AIM, so I can talk to my friends using other clients. And it just grew from there.

Doc: Tell us about the XML side of this.

Jeremie Miller: I've always been a big advocate of XML. I've written a few articles about it. As soon as I found out about XML, I kind of saw it as doing to the IT industry or to the Internet the same thing that silicon chips first did for the computing world--moving from the transistor into ICs. It's almost the same kind of phase. XML feels like that big a change. It's morphing all the underlying structures, speeding everything up, enabling everybody to structure data in a way that other people can understand. Even if you don't understand some of the pieces of the data, you can at least look at the data and see the structure of that data. So XML was always part of that server I was building in the background. And I was using XML to push it onto the client. Like I said, it was nothing really unique. It was just the right mix of putting XML in there and the desire of wanting to put all these things into a server. Then when I open sourced it--it just took off from there.

Doc: How many people are involved in Jabber right now?

Jeremie Miller: Our developer mailing list has 600 people right now. I would say there have been 50 people who wrote code of some sort for Jabber. Maybe 20 are actively doing something on a daily basis. And 5 to 10 core people who understand the fundamentals and really work with the core system or clients a lot.

Doc: I sense the interest is growing.

Jeremie Miller: Yes. There are about six thousand people on the mailing list right now.

Doc: For somebody who understands instant messaging on AIM and ICQ terms, what's the difference between Jabber and them? The reason I ask is because when I talk to people about Jabber, they respond by saying, ``That's a crowded space. There are umpteen million AIM and ICQ clients, and it's a very client-dominated world.'' Is there room for another one? What's the difference? I'd like to know how you explain the difference in kind between these systems.

Jeremie Miller: I look at instant messaging as a wide-open space. It's not crowded at all. From my point of view, there is nobody there. That's because when I look at Jabber, I look at it as the same architecture in the background as e-mail. So anybody can install an instant messaging server and offer their own instant messaging service to their group of users, their portal site and their company. An ISP can offer it to their users, just like e-mail. From that point of view, nobody is doing that with instant messaging. For AIM and ICQ, you're going back to AOL for everything.

Doc: So when you're looking at an AIM client, you're looking at one server, in Vienna, Virginia. It's a mainframe.

Thomas Muldowney: Yeah, it's a mainframe. That's one reason they also take a very limited view of what instant messaging as an application ought to be.

Doc: Is instant messaging the right word for what we're talking about? I've heard that AOL sees it as a way to get advertising in front of thirteen-year-old girls who get together to talk about boys and discuss their homework.

Jeremie Miller: I don't know. The architecture we're building includes instant messaging. But it's just one piece. What we're doing is pushing structured data--pieces of XML--between clients, between servers, between different software agents. We're pushing XML data around the network.

Thomas Muldowney: It's more like a MOO messaging application platform.

Doc: So the best way to think of it is as a service deployed at the enterprise or the ISP, at a server, like e-mail, news, name service ...

Perry Evans: Yes. But you need to put another virtue of XML into this picture as well. When you put structured XML in the middle of a live conversation, you can do so much more with it. You can build applications around it that mean much more than just the text itself. This is really a whole new platform. There's nothing like it out there, and it's way outside the scope of what you can do with AOL and its mainframes. Look at it as a multimedia platform with video and audio. IM is becoming the starting point of conversations with a behind-the-scenes Jabber-enabled application foundation that will be the start of a lot of communication types we haven't seen before.

Andre Durand: In just the past few weeks, we've been seeing applications coming to us from people who have grabbed onto the label ``Instant Message'', because in their minds, they believe their application begins when someone starts a dialogue. But quickly, the conversation turns into, ``How do I route XML documents?'' So the fact that Jabber routes instant messaging communication via XML documents becomes the most meaningful aspect. Because at its heart, Jabber is a way to route XML documents. One example: XFDML, XML Forms Definition Markup Language, is basically for secure digital signing of legal documents and transporting those documents.

Doc: So there is a server component to this that we just don't have with the familiar IM applications.

Jeremie Miller: Right. There's nothing else like it--except all the familiar services we know in the Internet world. That's why it's such a natural fit.

Doc: Are there any special protocols?

Jeremie Miller: No. The servers and clients talk with an XML-based protocol, and all the servers talk to each other with an XML protocol. It's just XML. From the server side, once we have that structured data, the server uses various different transports that we're building. The ISQ name transport is one. You can have a pager transport that moves messages onto the pager network. You can build transports into your own custom setup. Anything you want structured data coming in and out of can have a transport built for it. We're building an SMPT transport, so you can have e-mail coming into it. So, on the server side, you're taking all the old protocols, or any other protocol, turning it into structured data, and putting it out on the Jabber network, which moves it around.

Doc: You can pass ICQ or AIM messages without any trouble, right?

Jeremie Miller: They're just data.

Doc: Are you afraid of AOL here? Recently, AOL has punished its own users, along with Microsoft, for attempts to make two instant-messaging systems interoperate.

Thomas Muldowney: Actually, everyone in the Jabber community finds it quite amusing. The fact of the matter is, Jabber caters to a demand that will never be met until an open, distributed system and development platform like Jabber exists. Our basic view is that interoperability is inevitable. It will happen through an agreed-upon specification or through an open-source, Internet collaboration like Jabber. We're very supportive of both. We don't know if AOL will block Jabber or not, and as an open-source development community, it's none of our business if they do or don't. We are providing the world with a long overdue, open system for developing and operating a platform for IM communications and applications. It just so happens that Jabber was built for and is ideally suited to bridge the proprietary IM networks, such as AOL's AIM network.

Doc: So you're not afraid that AOL will change the game underneath you in some way with their clients.

Thomas Muldowney: AIM compatibility in Jabber is a very small part of what Jabber is all about. I think it is a nice feature and certainly a convenience for the people who adopt Jabber, but at the end of the day, we're actually more excited about all the other things a system like Jabber is capable of enabling.

Doc: So you think it's in AOL's interest that Jabber proliferate?

Andre Durand: I think it is in the better interest of the Internet community at large, and if AOL broadened its thought process, it might see that an Open Source community is ideally suited to take IM technology where it has never gone before. AOL didn't invent the Internet browser or Internet e-mail, but they certainly provide it to a great number of people. I think they should continue to do what they do best, which is provide consumers with the easiest and most consumer-friendly way of getting on-line and experiencing the Internet. I don't think AOL has to own the protocol to continue to dominate the consumer side of the IM market. In fact, I don't think AOL does themselves any favors in terms of Internet goodwill when they block others from attempting to provide consumers with interoperability. Ultimately, interoperability will prevail; there is simply too much pent-up demand for it.

Perry Evans: The important issue is that Jabber is not trying to be an IM service the way AIM and ICQ are. It is not threatening AOL's core business strategy of aggregating communities and adding value to those. It's providing a system alternative for a bunch of new applications that AOL is not spawning themselves. AOL doesn't want to be in the enterprise. It doesn't want to interface as a system. So in many ways, Jabber is filling in a void, where IM as AOL conceives it just doesn't play. AOL is trying to create communities through IM, which is fine. Jabber is not trying to control the user, like AIM or MSN is trying to do. Jabber is just much more compatible. Again, it's like e-mail, but as a service, it is open to many, many more extensions and applications.

Andre Durand: It's easy to overlook the fact that Jabber represents something much larger than IM. It's much more expansive. IM has many narrow associations. And if you stay narrow with those associations, it can't help looking like an alternative to AIM and ICQ, but it's additional to those products. In reality, the bulk of demand for Jabber isn't from users looking for a consumer-level competitive buddy list. We're seeing demand for sophisticated, real-time XML-based communication applications, where Jabber is a real-time router of XML documents. Within that architecture, there is a tremendous amount you can do.

Perry Evans: Jabber looks at the Net, sees the need for a service and fills it. And does it the right way: with open source code that anybody can adopt and improve. It's inclusive, not exclusive.

Doc: What are some of the fantasy applications you want to see developed on Jabber?

Jeremie Miller: Mine is a text editor that lets multiple people work on a document at exactly the same time--where messages flash saying, ``you're doing that right'' or ``you ought to look over here'', right while people are typing and seeing it onscreen at the same time.

Doc: Like with a law firm. Creative documents tend not to be written collaboratively, in real time, but legal documents often are.

Thomas Muldowney: You could have a live FAQ where different people are responsible for different questions.

Andre Durand: There is no reason now for delayed actions. You can do them in real time with Jabber. The commodities market, for example. Any market where buyers need to find sellers. The whole offer/bid scenario could be controlled by an application running on Jabber.

Perry Evans: We've talked a lot about extending a static database like a classified into essentially a live auction service. Which is to say, when somebody is interested in buying a product, they can open up a live communication option; but because you've got a document structure in the middle of that, you can choose to push that out to a bulletin board and say, ``Does anybody want to bid against this?'' Or you can put it into an application that says, ``I'll accept your offer in twelve hours if nobody else comes in.'' We're talking about putting extendibility into static content and building it around a real conversation--but going much further, because you've got this intelligent recording of the conversation over XML that allows it to be part of a community collaboration, an application process or any number of other things.

Doc: Tech support strikes me as a huge potential application for this. I've had a tech support issue that's spanned the last several days, and a number of different trouble tickets along the way. It would have been nice if both the tech support guy and I could have looked at the history at the same time, while we were having a phone conversation.

Perry Evans: The XML world is coming up with all sorts of standards, including customer profile standards. So you can put your profile, at your discretion, in the middle of a communication between buyer and seller. The fact that you can put a document of any kind in the middle of a conversation just has all kinds of implications. This is a lot of what the XML conversation will be about over the next few years, and I am sure Jabber will be the cause of a lot of it. There is this whole unseen dimension of structure and context, and XML is just starting down the path of applications that include interaction around documents in the middle of that conversation. This is a really powerful area of functionality that we're only beginning to imagine.

Doc: What is the overlap between the XML world and the Jabber development community?

Jeremie Miller: Everybody in the XML world has their own projects they're very dedicated to. Some of them are Jabber projects. We're pretty close to the XML world, though. A lot of people in that world know what we're doing and vice versa. But mostly we see XML as our building material for something that works in a new application space.

Doc: You're really building out Net infrastructure here.

Jeremie Miller: Definitely; the fact that Jabber is open source has a lot to do with that.

Perry Evans: So does the fact that it's a whole new service that the Net needs. And it's a service that brings different development worlds together. People haven't connected yet between XML trying to build standards of vocabulary and the world of process applications that are more conversational and interactive. It's like, let's make sure the vocabulary is right before we start talking. So DTD--document type definition, the vocabulary of an industry--is a main focus in the XML community right now. There are people working on the DTD for, say, the chemical industry, where everybody standardizes on the way things are described before they really work on the interactive applications. But Jabber is over here working on the interactive side, and cross-pollination results from that. The best example might be one that came up a couple of days ago. Somebody from Commerce One submitted a proposal to IETF for XML-based messaging. That's really at a layer above what Jabber does, but it's a first sign of a major vendor in the XML community starting to say they care about messaging and think it's the next big thing.

Doc: Are any of you involved with the IETF?

Jeremie Miller: I'm on the IETF IMTP list, and I've attended meetings.

Doc: Is the IETF interested in IM?

Jeremie Miller: They're interested, and have a whole group working on an IM protocol. They're working away on it; they argue a lot.

Andre Durand: It's not an immediate issue for us. We're XML-based, and we're delivering structured data between different points. They're designing a protocol specifically for instant messaging. And basically what is on the wire between the clients and the servers. We're going to fully support that protocol the moment it's available.

Jeremie Miller: It's different than what we're doing, but I'm involved with it, so I can understand how it's progressing.

Andre Durand: Because this whole area is new and not built out yet, it's really hard to explain. Yesterday, I was talking to some investors, and I had to pry their minds away from the default assumptions about instant messaging. So I spoke to a big vision of Jabber as infrastructure for real-time communication. The analogy I used was Cisco routers, which are software/hardware instruments for routing IP packets. Jabber is a server that routes XML documents in real time. From that perspective, to the extent that there are applications in the future that have a need to base their information flow on XML documents and have a need to be real-time, where presence is important and where you need live users, Jabber server-to-server communication architecture--where everyone can run their own server, just like e-mail today--Jabber can be viewed as a real-time router. On top of that, anybody can build value-added XML-based applications, most of which will be on the communication side, where instant messaging is the application that users think about today, but with implications that are much, much larger and cannot be understood in IM terms. We see a world where XML documents become the main form by which all structured data is transferred by and between companies or within companies.

Doc: If we're using the router metaphor, are we talking about a product here? Or something that is productizable, like a Cisco router?

Andre Durand: To that extent, it's like an e-mail server, yes. Ten years ago, nobody sold e-mail servers. Now we have Software.com, which has built a business out of commercializing e-mail servers, just like Netscape and Microsoft have commercialized web servers. From that perspective, there are ways companies can commercialize a Jabber server. You can also turn a Jabber server into a service, just like Hotmail created a service around web-based e-mail. So the business models might arise around service levels, professional services, value-added services or selling some premium version of the open-source Jabber software itself. Those business models have all been tried by other companies in similar spaces.

Doc: What's in the name space, and how does it look? I know AIM clients all use the AOL name space, which has zillions of names in it, requiring everybody to have a license plate for a name. My AIM handle is Zdilmidgi. Very memorable. That's because DSearls and DocSearls and other names like that are already taken, ironically by me, back when I had AOL accounts in the eighties. There simply are no more ordinary names. That's a real IM issue, from the client's perspective today. What are you guys using--e-mail addresses?

Jeremie Miller: Exactly; it's the only way. It's what most people recognize as an identifier for another person. We're just leveraging that.

Andre Durand: Multiple Jabber servers will exist in the .com world and use the same naming conventions. There's no conflict there.

Doc: So you're not creating yet another name space here. Addresses will be domain-derived e-mail addresses.

Andre Durand: As a system it could do that, but as a service it can't. AOL doesn't have the option, because AOL is a system with one server and one giant name space.

Doc: But ``giant'' is the word for it. How many AOL customers are there, each with their own IM handle? Plus, all those users who aren't AOL customers, but have AIM clients activated along with their Netscape browsers. Those aren't e-mail addresses.

Perry Evans: But if they're working with Jabber, they could use their e-mail addresses. I don't know if you saw the recent PC Magazine cover story on instant messaging, but they estimate there are 50 million IM users today, and there will be 180 million in the year 2003. Well, the next 130 million are not all going to come from AOL. A lot of the growth in IM will be inside enterprises, in embedded devices and other places. So there will be plenty of pressure for interoperability between directories and name spaces. Inside enterprises, what Jabber has to offer makes enormous sense. An enterprise can operate and control its own IM services. It doesn't need to rely on AOL's mainframe in Virginia. I think AOL fundamentally recognizes all this, which is why it supports the IETF interconnectivity program. So two years from now, this will be more of a moot point.

Andre Durand: We have decided to stay away from the consumer-level market for IM services. There is no point in raising red flags. The main use of Jabber is to create bridges between IMs and a distributed, open platform for IM-based applications. It's obvious that this is needed and extremely important to the Internet as a whole; it needs a real-time messaging server, and the open-source way is the right way to do it. When we see applications built on top of real-time communication, there is plenty of upside for AOL in the consumer space where it likes to play.

Perry Evans: It's important to get up at the 50-thousand-foot level and see that XML is just beginning to come into the Net in a serious way, and that many things can sit on XML-based real-time smart communications--voice-integrated and video-integrated technology, for example. We're so early with all this stuff. But when you look at Jabber, it's easy to start imagining these things.

Doc: Real time e-commerce could be huge.

Perry Evans: Right now, we've got very primitive buyer-seller interactions supported on the Web. With Jabber, you can see all kinds of possibilities. It might start on the Web and jump to the phone, go the other way, or involve both at once. There are all sorts of scenarios, all interesting. You can get instant-message phone alerts. Voice mail identifiers and voice-to-text conversions...

Andre Durand: Lots of tie-ins.

Thomas Muldowney: We were talking about this stuff in the ``Voice-Over IP for Linux'' Birds of a Feather session at the last Linux World. We found out a lot, and it changed our view of the issue. Conversation does that.

Andre Durand: So far, the only tie-in we've heard about is that an IM would notify you of an e-mail or a voice mail. But what we start to see is that maybe IM is what belongs underneath all these things, and potentially performs a much more key role in integrating these applications. You can use it to initiate a voice-over IP session or a video conference session.

Perry Evans: We're looking right now at all the social standards we use in conversations that initiate business. ``I want to make a reservation'', for example. ``Give me a quote.'' ``Are you available?'' ``When will you be back?'' ``Do you have this in stock?'' Many of these exchanges can be automated. This lends itself to XML automation. It's structured data. Pop it up in a menu, drop it in a calendar, all live, followed by an automated confirmation. Webb's business is putting commerce behind these kinds of things. That's why we wrapped our arms around Jabber when we saw it. That was the missing link. It goes beyond both instant messaging and text exchange. It's the structure we need to build applications. We know everyday commerce is going to be conversational, and will often start with either a voice call or an IM window. But the weaving of these things will occur around XML-based standard exchanges. Community interactions expand outward from there. ``I want to get delivery service to this neighborhood, and I'm looking for ten other people who agree with me and guarantee a market.'' Putting document structure into the middle of all this, fitting into the intuitive way these kinds of conversations happen--this is all conceivable now, with Jabber services making it possible.

Doc: One of Linux's virtues as an embedded operating system is that it disappears better than other kinds of operating systems. That's what happens in Intel's home web appliances and set-top boxes and Cobalt's Qube, for example. The OS becomes invisible infrastructure. Do you see the same thing happening with Jabber?

Andre Durand: We do. It might. Personally, I love the idea of ``Jabber everywhere''. We're seeing that happen already. Clients are being built for all kinds of operating systems and all kinds of devices. I think if we continue to focus on ensuring that Jabber is the right platform for the Open Source community, that community will take Jabber all kinds of places, including the embedded world.

Perry Evans: We see this as very foundational. It's something that can snowball real fast once people start to see what they can do with it.

Andre Durand: You know, before I was involved in the Internet, I was very involved in the BBS industry, such as it was. Of course, nobody ever got all those boards to work together. What we lacked was a common protocol to connect them. We're in a similar position today with AIM and ICQ and the other mainframe-based IM systems. They don't get along, in the same way the old BBSes didn't get along. You're not able to do any creative things with IM itself, because each kind of IM is isolated and stand-alone. The world of possibilities can't open up there. The industry isn't built for it. But Jabber brings XML into the middle of this thing, and lets us insert documents in the middle of conversations, and suddenly everything is possible. It's just like the Net. It gives us the foundation for creative tie-ins.

Doc Searls (doc@ssc.com) is Senior Editor of Linux Journal, co-author of The Cluetrain Manifesto and a member of the advisory board for Jabber, Inc.