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 communications 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 were 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 the way we deploy email 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.
Linux Journal: 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 '98. I worked in an ISP and I was playing around with other chat clients. We were using IRC and ICQ. Excite for a while. It was starting to catch on in the office. I didn't even know about AIM, really. I wasn't in the Windows world too much.
Linux Journal: 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 of my UNIX utilities, all of my logging stuff, a lot 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... and 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 "Well, I could build a back-end server, and make my own protocol, maybe I can convince somebody else to write a client, and then they wouldn't have to update it when I want features. Then I just start adding all the features into the server. Then I can bridge that server to my UNIX things that 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.
Linux Journal: 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 large of 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.
Linux Journal: How many people are involved in Jabber right now?
Jeremie Miller: Our developer mailing list has 600 people right now. I'd say there have been 50 people who have written code of some sort for Jabber. Maybe 20 that are actively doing something on a daily basis. And 5-10 core people who really understand the fundamentals and really work with the core system or clients a lot.
Linux Journal: I sense the interest is growing.
Jeremie Miller: Yes. There are, like six thousand people on the mailing list right now.
Linux Journal: For somebody who understands instant messaging on AIM and ICQ terms, what's the difference between Jabber and those? The reason I ask is because when I talk to people about Jabber, they respond by saying "That's a crowded space. There are umpty 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 email. So anybody can install an instant messaging server and offer their own instant messaging service to their group of users, to their portal site, to their company, running as a local server. An ISP can offer it to their users, just like email. From that point of view, nobody is doing that with instant messaging. For AIM and ICQ, you're going back to AOL for everything.
Linux Journal: 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.
Linux Journal: 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 cheat on their homework.
Jeremie Miller: I don't know. The architecture that 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: So it's more like a MOO messaging application platform.
Linux Journal: So the best way to conceive it is as a service deployed at the enterprise or the ISP, at a server, like email, 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 it's mainframes. Look at it as a multimedia platform. Video. Audio. IM really is becoming the starting point of conversations with behind-the-scenes Jabber-enabled application foundation that will be the start of a lot of communications 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 on to 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 communications 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. It's basically for secure digital signing of legal documents, and transporting those documents.
Linux Journal: 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.
Linux Journal: 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 that you want structured data coming in and out of, you can build a transport for that. We're building an SMPT transport so you can have email incoming 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 out on the Jabber network, which moves it around.
Linux Journal: You can pass ICQ or AIM messages without any trouble, right?
Jeremie Miller: They're just data.
Linux Journal: 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 all 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 it will happen 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, its 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.
Linux Journal: 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 to the people who adopt Jabber, but at the end of the day, we’re actually more excited about all of the ‘other’ things that a system like Jabber is capable of enabling.
Linux Journal: 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 I think that 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 email, but they certainly provide it to a great number of people none-the-less. I think that they should continue to do what they do best, which is provide consumers with the easiest and most consumer friendly way of getting online 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 that 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. But in reality the bulk of demand for Jabber isn't from users looking for consumer-level competitive buddy list. We're seeing demand for sophisticated, real-time XML-based communications 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 in. And does it the right way: with open source code that anybody can adopt and improve. It's inclusive, not exclusive.
Linux Journal: What are some of the fantasy applications you want to see develop 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 on screen at the same time.
Linux Journal: Like with a law firm. Creative documents tend not to be written collaboratively, in real time. But legal documents often do.
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 auctions. 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 that runs 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 in twelve hours if nobody else comes in." We're talking about putting extendability 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.
Linux Journal: 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.
Linux Journal: What is the overlap between the XML world and the Jabber development community?
Jeremie Miller: Everybody in the XML world has their own projects that they're very dedicated to. Some of them are Jabber projects. We're pretty close to the whole 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.
Linux Journal: 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 defnition, the vocabulary of an industry — is a main focus in the XML community right now. So 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 of this. And cross-polination results from that. The best example might be one that came up a couple 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.
Linux Journal: Are any of you involved with the IETF?
Jeremie Miller: I'm on the IETF IMTP list, and I've attended meetings.
Linux Journal: Is the IETF interested in IM?
Jeremie Miller: They're interested, and have a whole group working on an IM protocol. And 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 that 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, where you need live users, Jabber server-to-server communication architecture — where everyone can run their own server, just like email 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 communications 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 transfered by and between companies, or within companies.
Linux Journal: If we're using the router metaphor, are we talking about a product here? Or something that is productizeable, like a Cisco router?
Andre Durand: To the extent it's like an email server, yes. Ten years ago nobody sold email servers. Now we have Software.com, which has built a business out of commmercializing email servers. Just like Netscape and Microsoft have commercialized Web servers. From that perspective, there are ways that 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 email. So the business models might arise around service levels, or professional services, or 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 already in similar spaces.
Linux Journal: 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? Email 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.
Linux Journal: So you're not creating yet another name space here. Addresses will be domain-derived email 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.
Linux Journal: 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 email addresses.
Perry Evans: But if they're working with Jabber, they could use their email addresses. I don't know if you saw the recent PC Magazine cover story on instant messaging, but they estimate that 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 in other places like that. So there will be plenty of pressure for interoperability between directories and name spaces. And 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 much 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 a needed and extremely important to the Internet as a whole, it needs a real-time messaging serverAnd an open source movement 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 lots of 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.
Linux Journal: 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, or 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 a lot out and it changed our view of the issue. Conversation does that.
Andre Durand: So far the only tie we've heard is that an IM would notify you of an email 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.
Linux Journal: One of Linux's virtues as an embedded operating system is that it disappears better than other kinds of OSes. That's what happens in Intel's home Web appliances and set-top boxes, and Cobalt's Qube, for example. The OS kind of sinks into the pavement. It 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 that if we continue to focus on ensuring that Jabber is the right platform for the open-source community, that open-source 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 BBSes to work together. What we lacked was that common protocol to connect them together. We're in a similar position today with AIM and ICQ and the other mainframe-based IM systems. They don't get along, in just the same way as 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.