Programming Jabber

Reader cpfeifer contributes the review below of O'Reilly's Programming Jabber: if your job (or hobby) includes instant messaging in all its glory, Jabber is a free-beer, free-speech framework for setting up instant messaging systems not bound to a single server in the middle. As cpfeifer points out, instant messaging can mean a lot more than popping an on-screen note to your friend in Des Moines -- machines and programs can use a general purpose communication system like this, with no human middleman required. Programming Jabber author D.J. Adams pages 4555 publisher O'Reilly rating 9 reviewer http://cpfeifer.blogspot.com ISBN 0596002025 summary A detailed guide for developers to understanding and extending the Jabber messaging framework. Examples in Perl, Python and Java. The Scenario

Jabber was first conceived by Jeremie Miller (pic) in early 1998 in an effort to unify the disparate instant messaging networks. Instant Messaging networks rely on the network effect to gain and retain marketshare. The concept is the same when applied to any sort of participatory network whether it's a junk exchange, or content exchange, the value of the network increases with the square of the number of participants.

If this is true, then doesn't it follow that it is in the best interests of the IM networks to establish peering agreements with each other so that their users can directly contact users on other networks without having to install each client?

Hello, Jabber.

When I first picked up this book, I expected to understand the Jabber protocol in sufficient depth to implement my own IM client. Instead, the approach this book takes is that Jabber isn't just an XML-based protocol strictly for IM, rather it is a general purpose event notification protocol that has some very nice message routing and user management features built into it. While i was reading about the messages that Jabber has defined as part of the protocol, I could easily see other applications/devices generating Jabber messages to notify subscribers (either other systems, or people) of events.

Part 1 of the book focuses on getting you up to speed on the basics of Jabber technology: motivation, major features, XML protocol sample and compiling/configuring your own Jabber server. Chapter 2 presents the "10,000 foot view" of Jabber technology. In here you will find a sample client-query request/response flow with full HTTP headers, discussed step by step. The next two chapters are a very in-depth discussion of installing and configuring your own Jabber server. When you dive into a custom configuration of a fleet of Jabber servers (a "constellation" in Jabber terminology), it really starts to hit home that the real problem Jabber solves is far deeper than just IM.

From there, part 2 kicks off with a detailed discussion of the most basic building blocks of Jabber technology: resource identifiers, XML handling mechanism and the set of XML elements/attributes that make up the vocabulary of the Jabber protocol. Each element/attribute is presented with an annotated example and sample client/server interactions where appropriate. Examples can make or break a technical book, and these examples do a good job of illustrating how the element/attribute is used.

The following chapters take you through using standard Jabber features, user registration/authorization, messages, presence, groupchat, components and the event model to enable new applications. One very interesting application presented is enabling developers to receive CVS commit notifications via Jabber.

What's Bad?

I know the /. community is suspicious of glowing book reviews where everything is wonderful and nothing could be done to improve the book, so I'll nitpick. My major problem with this book is that the overwhelming majority of the sample applications are written in PERL/TK. This isn't a problem in and of itself, but I'm not a PERL/TK developer. If I build a Jabber solution, it will be in java, so PERL/TK samples don't do me a lot of good. I think equal time should be given to implementing Jabber using the two most-used languages, as defined by the number and activity of open source projects using Jabber technology.

What's Good?

This book covers everything relevant to Jabber technology, from lowest level inner workings and extensibility examples for developers to configuration and deployment for admins. Most of the book is spent looking directly at the Jabber XML protocol, instead of a specific API implementation. This way, the book covers the technology and doesn't get lost in how one particular API models the protocol.

So What's In It For Me?

If you want to implement an inside-the-firewall IM solution for your company/group/tribe or investigate integrating event notification into an application, this is a great starting point. If you're just curious about Jabber and want to know how it works, then this will give you enough information to get you hooked.

Table of Contents

PART 1: Getting Started with Jabber

• Chapter 1. Introducing Jabber
• Chapter 2. Inside Jabber
• Chapter 3. Installing the Jabber Server
• Chapter 4. Server Architecture and Configuration

PART 2: Putting Jabber's Concepts to Work

• Chapter 5. Jabber Technology Basics
• Chapter 6. Jabber Namespaces
• Chapter 7. User Registration and Authorization
• Chapter 8. Using Messages and Presence
• Chapter 9. Groupchat, Components, and Event Models
• Chapter 10. Pointers for Further Development

Appendix A. The Jabber.xml Contents

Appendix B. The IQRPC Classes for JabberRPCResponder

Index

O'Reilly has posted other reviews of the book on their site. You can purchase Programming Jabber from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Comments

Trend in modern computing

[alapalaya]

machines and programs can use a general purpose communication system like this, with no human middleman required.

This is on of the hottest topic for the near-future computing world.
Anyway the SOAP (+WSDL+UDDI, ie: the Web Services) initiative seems much closer to be the real mover in this environment.
Interesting (but not suprisingly), XML is the basic enabling technology for all these efforts.

Re:Trend in modern computing

[rbeattie]

I think the next step is Web Services combined with some sort of presence protocol to provide the next generation IM or P2P apps.

I mean, if I have a web services "servent" on my machine it can do a lot, but no one knows where I am. A presence protocol (maybe the one in Jabber) would allow people to know I'm here and the services that I support. After that, SOAP messages can carry all the rest of the communication directly from peer to peer.

The question is, is there an advantage to having a Jabber server as a communications middleman (maybe caching XML messages like JMS or MQSeries) instead of just providing presence information and allowing the clients to talk among themselves...

-Russ

Jabber

[Sabby]

I got really excited about Jabber for the longest time. I'm sort of disappointed in it now, since it seems like they're still having problems connecting to AIM and ICQ. The AIM connection is the most vital for me, since our department uses AIM to send short quick messages to each other. Most of the people here are using AIM's own client, but I started to use Jabber so that I could talk to my friends on ICQ. (And promptly signed up for MSN and Yahoo, so I could catch everyone from everywhere.) Now I use Trillian, which only disappoints me by neither providing source code (which I only want for the principle of it) nor supporting Jabber itself (which does kind of bug me).

Re:Jabber

[garcia]

I couldn't see using AIM to send "quick messages" in the sense you seem to be trying to convey.

I use a wireless laptop in the living room to play MP3s from the wired computers in the house. I had to delete IM from the computer b/c stupid college students are fucking addicted to it.

The addiction isn't so much the problem. The poor CPU is only a p133. It can't handle MP3s and IMs. Then the bastards complain that it takes too much time to send messages and to top it off they fight over who gets to send an IM next or see which profile has been updated in the last 4 minutes.

The people that left college and are now working in the real world sit on AIM all day and chat. My father, 55, sits on AIM all day and chats. My mother, working at a funeral home and a church, doesn't chat only b/c there is no Internet connection? there.

Jabber (GAIM, Trillian, etc) would complicate this problem furthur by allowing crazy fools who use IRC, MSN, Yahoo, AIM, etc to talk even more and claim it was for good use.

I say down w/AIM. ;-)

Just a little half-off-topic humor for Thursday.

Re:Jabber

[JabberWokky]

FWIW, when I upgraded to KDE 3, I took a look around and decided to play with new software. I had had much the same experience with Jabber, where it just didn't really work well with other IM systems. For the past three days or so, I've been using Psi, which seems to work quite nicely with Yahoo Messenger and AIM (the latter of which I use quite heavily in both work and socially). It's Qt based, and so it runs on Windows, Linux, OSX and embedded systems, and since it's under the GPL, you can use the Qt free edition. I think there were binaries there for all the platforms.

YMMV, but it's working for me, plus the cross platform nature means that I'll start recommending it to people who have been using Trillian in the past. It's at the "almost there, but not quite finished" level, with two major bits missing - a total lack of documentation (which can get gotten around), and lack of support for group chat - which means the IRC service won't connect (not to mention AIM group chats). I just discovered it, so I can't say how fast work progresses on the project, but it's very much usable for my needs right now. Sounds like it might work for you, too.

My Jabber ID is JabberWokky@charente.de, and that server supports AIM, ICQ, MSN, YIM, Jabber and IRC.

--
Evan

Re:Jabber

[Temas]

Correct. I'm the author of the AIM Transport and it's still in active development. I'm actually in the middle of refactoring it as a completely external component (again). The ICQv7-t transport is also in active development on it's sourceforge site. Besides the blocks on some of the larger public servers things are great, just setup your own =)

Re:Jabber

[tzanger]

I got really excited about Jabber for the longest time. I'm sort of disappointed in it now, since it seems like they're still having problems connecting to AIM and ICQ.

My jabber server has ICQv7 and AIM transports, and also MSN and Yahoo! transports. ICQv7 was a real pain in the ass to set up but is working perfectly. I've never had trouble getting on to the networks and even the "offline messages" that ICQ has had for years works fine now.

So I dunno, go use your own server or use an open server line charente.de for your ICQv7 needs. I really don't know what your trouble with AIM is though. I always thought of AIM as the retarded cousin of ICQ so I never use the transport anymore. (I was using it to get on to the ICQ network when I couldn't get ICQv7 compiled.)

Re:Jabber

[infiniti99]

Sabby,

I think you are looking at this all wrong. Jabber was never meant to be a multi-IM solution. While the transport modules that allow you to connect to other services like AIM can be cool, they are for easing Jabber migration only. Do not come to Jabber with the expectation of perfect AIM compatibility for life. And definitely stay away from proprietary IM systems that you were not previously using (in your case, MSN and Yahoo). No need to make yourself more dependent them.

The reason to use Jabber is to promote it as a standard. The sooner we all switch to Jabber, the sooner the IM war will be over. Then things like transports and Trillian won't even matter.

My recommendation for you is to use Trillian for all of your proprietary IM needs (but please, please, don't use extra services you weren't already using), and keep a Jabber client around for Jabber-only communication.

-Justin

Re:Jabber

[infiniti99]

By signing up with MSN and Yahoo, I've opened up channels to me from people who only use MSN or Yahoo. Believe it or not, there are people out there like that.

I believe it. I guess it comes down to a matter of tradeoff. Is it worth sacrificing possible communication with Yahoo users, in effort to stay away from Yahoo? When I decided to make the move to "just Jabber" a few months ago, I had to sacrifice over half of my contact list, most of which were AIM or ICQ users. I don't advise that people do this unless they are Jabber fanatics (of which I fit the bill :) ). Since then, my list has steadily grown in size, which is good to know.

I'd gladly campaign for moving my department over to Jabber, so we could have an internal server for it

I think this is Jabber's key to victory. Businesses who take IM seriously will want to keep all communication behind the firewall.

lacking AIM/ICQ support, I'd have a harder time selling it to my other coworkers who aren't fired up about it. (Who want to talk to their wife/aunt/father/whatever who are single IM client users). Jabber either needs to maintain that compatbility to take off, not just to "ease migration."

I don't agree. In fact, I think the transports have caused Jabber more trouble than anything else. First, they completely cloud the issue. People generally don't come to Jabber because it is the most advanced IM network. No, they come because of transports. Then, they proceed to enjoy the AOL IP ban placed on the popular servers, and they come to the conclusion that Jabber sucks. Ask anyone why they don't like Jabber, and they will say something about ICQ. I'm serious.

If Jabber was instead promoted as a "next gen" IM system _period_, then everyone would know what they are getting themselves into. This whole interoperation with AIM would not even be in the discussion. I think this would have also caused a lot more OSS people to try Jabber. Instead, most of them write it off as a Gaim-clone.

Check out this very interesting mail from JDEV on the subject of Jabber Advocacy. Be sure to read the quoted portions too, from Julian and Ashvil. Those are the best parts.

So the question remains: would the average single-IM client user want to start using Jabber also? Probably not. I think in order to win we're going to have to work from the inside out. I say we get all the business and OSS people using it first, then go from there.

-Justin

Jabber and Sendmail

[Anonymous Coward]

While on the topic of Jabber. Why not have the sendmail folks and the jabber folks get togethor and unite their work into a single project. Complete with admin tools so that once someone has a sendmail account on a Unix, they by default have a jabber IM account. It would go a long ways towards taking down AIM, MSN, and ICQ.

Re:Jabber and Sendmail

[Raleel]

Check out the smtp transport for jabber...this might provide what your looking for.

I've thought this would be an excellent idea as well. So much in fact, that I've been looking at encorporating it into my esmith box. It would be great...add an account, they get domain access, windows shares, email, webmail, groups, jabber...a real single point of service (ya, I know...take it out and your screwed...there are ways around that).

Re:Jabber and Sendmail

[Error27]

I hearby grant you the "Marketing Genious" award. That is the most brilliant idea I have heard all day.

Really the big idea behind jabber was that ISPs would provide instant messanging to their users. In 1998 that seemed like a great idea but now it seems as if most ISPs could not care less about providing new services. Sendmail is already the most popular email server around and it makes sense for jabber and sendmail to get together. Perhaps more people would provide jabber if it just meant turning it on and providing a .exe on their webpage.

Metcalfe's law that the value of software is the square of the number of users applies here of course.

btw: a jabber smtp transport is a bit of a hack, potentially a useful hack, but it doesn't compare to a full fledged email server.

Jabber + SSL

[cygnusx]

I've set up a Jabber box (an early 1.x release) and played about with it, and it was a *very* good experience. Everything worked as advertised. On the other hand, setting up Jabber with SSL was a confusing process without too much documentation and I eventually gave up. Since SSL is a must for `serious' Jabber use, has there been some progress made on making secure Jabber installations easy to achieve?

Re:Jabber + SSL

[cowmix]

SSL on the server side is a no brainer now.. Most clients also implement SSL too.

More important, IMHO, many clients support end to end security via PGP/GPG...

Re:Jabber + SSL

[dark_panda]

If you're having problems with the SSL support in Jabber itself, you might want to look at stunnel. Set up stunnel on the server to pipe the Jabber ports to SSL, then set up stunnel on each client and connect to the server through the tunnel. Not the most elegant of solutions, but it works in a pinch. (There's a chance you wouldn't even need to set up stunnel on the clients if the Jabber clients themselves had SSL support built-in.)

J

My big problem with Jabber...

[mo]

I read this book looking to use jabber for automated XML messaging and I'll have to say, it has a lot of nifty features that I'd love to use. Unfortunately, it's never getting deployed in my network. Why?
You can't cluster jabber servers. If the main jabber server goes down, you're hosed. In any application that's worth the effort to deploy, having such a single point of failure is a big problem. Additionally, I was kinda annoyed at how jabber leans so much towards instant messaging. I know, I know, that's what it was built for, but this book is trying to pass it off as an "XML messaging" tool, but it's properties often sway back to IM.

In conclusion, if you wanna fool around with a nifty IM robot that doesn't need to be relied on, jabber is a nifty tool. If you wanna do real XML messaging, try something like xmlblaster.

Re:My big problem with Jabber...

[gUmbi]

I believe that jabber has added clustering support to the commercial version (http://www.jabber.com/products/platform.shtml)

Jason.

Re:My big problem with Jabber...

[jeremie]

What your talking about here is a particular implementation of a Jabber server, jabberd, not Jabber in general (people often confuse this point). You can do some minimal clustering with the jabberd-1.4 series, but probably not the kind of reliability that your looking for or that jabber.com has built into their server.

Jabber is an open system/protocol, anyone can build new servers/clients/etc with whatever features and extensions they want, including building it on/with xmlblaster. Jabberd is also an open source project that your welcome to help with (farming/clustering is a frequent need and I suspect that it will be a large part of the jabberd-1.5 development series).

Hey, remember SMTP?

[hqm]

One thing that confuses me about Jabber is that
people seem to forget that good old SMTP solves many of the same problems, and in fact solves them better.

For example, many years of work have gone into making sure that email never gets lost. SMTP mailers just don't lose email anymore. Jabber messages, on the other hand, are not really reliable. If the user to whom you are targeting a message is not online, the server may queue the messages, but the policy is not clear as to how long they will be stored, or if the server is rquired to store them at all.

This makes me worry about the idea of using Jabber to build infrastructure where you
rely on messages to always be delivered.

It seems to me that many of the issues that Jabber
solves have been solved using existing
technology such as SMTP, and mailer and mailing list services built on top of it, like qmail, mailman, etc.

Re:Hey, remember SMTP?

[Raleel]

Actually, you should check out the smtp transport for jabber....it might provide some of the functionality that you require.

Re:Hey, remember SMTP?

[ProfessorPuke]

Right on! Most avid internetters had been performing Jabber-like tasks years prior to the introduction of ICQ or anything similar, with either SMTP, or IRC or "talk". (The latter two aren't as directly applicable to the problem, though)

I definately remember periods of transmitting emails back & forth at 15 second intervals- this was using "pine", a text-mode emailer that doesn't impose as much GUI-created latency as most email clients.

Its a real same that AOL, Mirabilis, et al, had to create their own new protocols rather than slightly extending SMTP to work in this application. The changes could likely be accomplished with optional extensions, preserving backwards compatibility.

First, POP3 would need a "request push" operation, so that a client could indicate to the server that any new emails within the next 5 minutes should be sent to it immediately. Otherwise, the client would need to query the server every 10 seconds, in order to provide the quick response that IM users want.

Secondly, there should be an optional mail header entry for "instant expiration" priority. Basically a way for the sender to indicate that unless the recipient is online right then, the message can be considered as much less important than ordinary emails. This would just provide a way to segregate traffic by its intended use- client software could ignore it if it wants, although often a different graphical presentation is desirable for IMs vs regular emails. (IMs essentially have only Subject lines, not Bodies)

Re:Hey, remember SMTP?

[MeNeXT]

Forget POP3 just extend SMTP.

I'll call it and SMTP client. When it connects to the SMTP server it identifies the user and the users IP. The server forwards all messages to this IP. If it's unable to forward it places messages into a mailbox for POP3.

SMTP client first opens POP3 receives mail. Sends ID and IP to SMTP server. Client displays messages and relays messages through SMTP server.

No central server. Your email is your ID. nice and easy. Some detaisl to be worked out.

Re:Hey, remember SMTP?

[MeNeXT]

It might also stop spam. I know in my last post I mention getting rid of POP3 and then I go and include it. Lets say we replcae POP3 with ETRN. SMTP holds the mail until you connect and sends it to you. Since you are directly connected and are receiving the mail at the same time it is being sent an option may be implemented just cookies in Konqueror where you have the option to reject the message. Your client the refuses the mail which bounces right back to the SPAMMER.

Now if this forces the spammer server to slow down we may hav less spam.

Jabber

[Sabby]

I've played around with the jabber module in Perl, which was pretty easy to use.

Jabber started to disappoint when they stopped supporting AIM/ICQ. I don't know if it's permanent, I don't actually know if it's still not supported. But, since AIM is what I have to use for work (otherwise, I would still just be using ICQ to talk to my friends), I needed something that could stay connected.

I use Trillian now. It still does ICQ/AIM as well as IRC/MSN/Y!, which is why I need something like this, but it doesn't provide source code (which I only really want for the principle of it) and it doesn't support Jabber's protocol. (They're talking about releasing an API for writing plugins. At least it's free (as in beer). (I've got a few of my coworkers switched from AIM to Trillian...) Hopefully Jabber will fix up the connectivity issues (or have ALREADY fixed them up.) gosh, I should download WinJab again and check.

I use it every day

[Raleel]

I have a lot fo friends on different IM systems. Mostly it's AIM, but some on ICQ, Yahoo, and MSN. I use gabber as my primary linux IM client, and myJabber for windows.

Probably the best thing about gabber and myJabber is that they offer encryption. Both can connect to servers using SSL encryption, and gabber has the added bonus of being able to use GPG keys for one to one chats to particular users. This gives me a warm squishy feeling as I communicate over networks that I _know_ are being monitored. The SSL is very nice, because at least I know my communication between the server and myself is at least not totally trivial to break (yes, I know about ettercap). This appears to even affect my aim traffic, as the AIM transport on the server does the actual relaying of messages.

Jabber has a billion other things in it. You should really give it a shot.

jabber: much more than just IM

[Roadmaster]

Jabber's site clearly states that if all you want is being able to chat with your friends in ICQ, Yahoo, AIM, MSN and/or IRC, then Jabber is probably not what you need, and they do indeed recommend trillian as a good choice. If you want a Free alternative, Everybuddy might be worth a look.

The problems with proprietary IM networks come, precisely, from those networks' desire to remain proprietary. Witness the self-blocking efforts AOL, Microsoft, Yahoo and ICQ perform on each other, which, inevitably, hit free clients designed to connect to those networks. Jabber's transports are no exception; if AOL decides to block MSN Messenger by altering its protocol, we're gonna get hit too.

Jabber's ability to access other IM networks is to be seen as a "bonus feature", probably not the main reason to use Jabber. Jabber excels at letting an organization (not necessarily a company, but a group of individuals and/or machines) in need of communication, do just that, communicate, using well-documented protocols, Free software, and self-maintained infrastructure. Granted, maintaining a Jabber server is not too easy (but it's not impossible either), but the knowledge that you're not subject to the whims of AOL, Microsoft and whatnot, plus the sheer number of client software available to suit every user's needs (there's TONS of Jabber clients, I settled for Shaolo on Linux and JIM on Windows) make Jabber an intriguing option for those in need of serious communication.

Re:jabber: much more than just IM

[Darren Winsper]

AOL actively block clients attempting to be compatible, but I haven't seen Microsoft go out of their way to block clients as far as I can tell. There was a time when Everybuddy was blocked, but I think that was due to a change in protocol, not because they were trying to block anyone out.

Could Jabber replace IBM's MQ-Series?

[s390]

I'm serious. IBM spent a ton of money building MQ-Series, which is a hideously complex messaging protocol for inter-and-intra systems communications in and between mainframe subsystems/LPARs and Unix systems (AIX mostly, since this is IBM, after all).

MQ-Series really is complicated, maybe over-complicated, to the point that IBM and customers even have "MQ-Series Specialists" on staff.

I'm not flaming IBM here (h*ll, I used to work for them, and they're a great company to work with), but they do have an unfortunate tendency to build overly complex systems where simpler ones might be a lot easier to use.

Re:Could Jabber replace IBM's MQ-Series?

[Zapman]

Once I read the review, this was my exact question. However, it doesn't seem that Jabber has the promise of not loosing messages that persistant queue's in MQ can give you.

Soneone correct me if I'm wrong.

The promise not to loose a message is of monumental importance... and the ability to run on almost all platforms under the sun is MQ's bread and butter (zOS to NT, SCO to MVS).

Re:Could Jabber replace IBM's MQ-Series?

[s390]

The promise not to loose [sic] a message is of monumental importance... and the ability to run on almost all platforms under the sun is MQ's bread and butter (zOS to NT, SCO to MVS).

But couldn't Jabber do that too? I realize that the public Jabber servers (jabber.com, jabber.org) might be lossy, but an internal Jabber service might be very reliable, and might even talk to MQ-Series on mainframes (zSeries), Unix (pSeries), and Intel (eSeries) systems. Has anyone tried this? I'm not trolling here, as I'd really like to hear what's been tried and what's maybe possible.

Re:Could Jabber replace IBM's MQ-Series?

[Temas]

There is talk about guaranteed msging in the future , primarily with a focus on JAM (Jabber as Middleware). A lot of this is in parallel with the next generation discussions that are happening on and off. So it is in our sites, but we're not sure how quickly it will arrive. Feel free to join our standards-jig mailing list (See our lists) and participate, few views are always welcome.

Re:Could Jabber replace IBM's MQ-Series?

[21mhz]

Jabber, as I see it, comes from the other end of the KISS scale. So, the appropriate outcome would be wide adoption among hordes of enthusiasts, not insanely expensive set-top "messaging servers" that require insanely expensive admin spetsnaz.

More vital question is, whether the IMPP protocol suite, which is being churned out by IETF, can supplant Jabber-based communications. Judging by the committee's pace, they are going to be too late to become the de-facto.

Re:Could Jabber replace IBM's MQ-Series?

[s390]

Feel free to join our standards-jig mailing list (See our lists [jabber.org]) and participate, few views are always welcome.

ROFL... We'll assume you meant to say _new_ views, etc. (37337ist Open Source hackers!) Thanks for your kind invitation.

Re:Could Jabber replace IBM's MQ-Series?

[Peter Harris]

I am eagerly awaiting JAM, not because I need to use messaging middleware yet, but so I can use it like a big cattle prod to repel Progress sales reps when they try to push SonicMQ.

At the moment I am forced to use a taser, but the batteries are expensive :)

Pretty good stuff.

[The Purple Wizard]

I've recently been involved in at least two large-scale projects involving developers in three countries, US, Singapore and India. The timescales were very small; we had to implement one of the systems within 48 hours. A huge coding effort it was, with rapid real-time changes to design specs.

As much as I hate M$ (hey, I AM a /.-ter after all), I just can't de-emphasise how critical MSN Messenger was during development.

Only one problem though:- you'll need intense amounts of concentration to ignore junk messages from friends.

This is one place I'd focus on. You know, perhaps an avatar sort of thing; in your programming (work) avatar, you are online to only a certain people. In your chillout avatar, you are online to everyone. The programming avatar also could have an auto-message feature:- perhaps one that delivers a message to the tester once you finish coding a class or something.

Any open source Jabber-related projects out there working on this?

Re:Pretty good stuff.

[CaseyB]

This is one place I'd focus on. You know, perhaps an avatar sort of thing; in your programming (work) avatar, you are online to only a certain people

More complex event handling in general, yeah. It'd be nice to have a generalized, maybe scripted, event handlers.

"When (user in group "family") (logs in) (after 5:00 pm), (play ring.wav)".

"When (Joe) (changes status to (idle) (between 9am and 5pm)) send msg to joe: 'Get to work!!'".

Re:IM ~ UDP

[MarkusQ]

Jabber, AIM, MSN, and others use TCP. In fact, the only client I know of that ever used UDP was ICQ, but that was an older protocol that is no longer being used

I think his point was that Jabber is like UDP in that you aren't sure that any particular message will get through, but then you don't pay the overhead of making sure.

-- MarkusQ

Jabber is a hack

[ProfessorPuke]

As are all "Instant Message" programs. They are a poorly-designed, short-sighted solution to a problem that should've been addressed elsewhere in the internet architecture.

Part of the problem stems from the fact that IM software addresses 2 applications at the same time, unnecessarily coupling the implementations. These problems could really be approached separately:

• Learn the IP address associated with a globally-unique username
• Send a text message to the interactive operator of a machine with an IP address

The first problem is the much more interesting one- Jabber & AIM already somewhat solve it, but in an unsatisfactory and poorly extensible way. Better solutions would be based on an extension to the normal DNS system- essentially, you want each human to have a resolvable domain name associated with her. With that in place, InstantMessaging is an easy problem.

A person could try to implement "TCP over IM", but it would've been nicer if the systems had been designed for this from the start. Actually, there is a 3rd general-purpose facility that might be needed, for reasons of privacy. There should be a way to send a packet to a "resolvable human name", without knowing the IP address it currently maps through. The (trusted) central server will have to forward packets in both directions. (I think that's how AIM normally operates, except that it doesn't accept generic packets, only AIM-formatted messages).

However, that method doesn't uniformly improve privacy. While it does prevent other users from learning your IP address, it makes it much easier for AOL (or other central server operator) to spy on the contents of your discussions. (You should be using encryption, anyway).

Re:Jabber is a hack

[devnullkac]

Learn the IP address associated with a globally-unique username

Unfortunately, the user identification problem is complicated by the fact that there may be more than one person using a given IP address. Firewalls which implement NAT and servers which have multiple simultaneous logins are quite common and give this complication real teeth.

You could perhaps claim that the task is really to associate an IP address and TCP/UDP port with a person, but you can only realistically use one service per port (port 80 overloading notwithstanding), so you'd have to say that the identification is solely for IM, and so the solution of the problem isn't really useful outside IM applications.

Or you could instead say that the task is to associate an IP address and TCP/UDP port with a person and a service, but now you've got the problem of identifying all services and handling the dynamic nature of port assignment as users become available/unavailable and declare themselves as participating/not participating in the various services. Not impossible, but hard enough that nobody seems to have solved it yet.

Re:Jabber is a hack

[Temas]

I think you're failing to grasp some of the points of Jabber messaging, especially as something more than basic chat. The idea (at least from the Jabber point of view) is to _NOT_ learn the IP address of the other party. You only reference them from their "username". Username is the wrong term though, we user the term JID (Jabber id). The JID format is: username@host/resource. So it is built upon a DNS like system. Once you know another users JID you can interact with it using messaging, presence, or other methods. The power of not trying to interact with an IP directly is it's ability to more cleanly go around firewalls. The client makes a connection outside of the firewall to their Jabber server (potentially through some proxy), and they are then on the entire Jabber network. Applications that are exposed on the network then have the ability to interactively use presence and a clear path to the user for more complete interaction. So perhaps you are looking at this from the wrong viewpoint?

Re:Jabber is a hack

[iabervon]

Extending DNS won't work, because DNS is designed for naming things that don't move around much. Finding a person requires a different design because, if you wait a day to propagate the information of where I'm sitting, it will always be wrong. What you need is a system where my name determines the only machine you ask to get my location, and that machine tells you how to reach me. Standard DNS won't work, because it expects to cache the IP addresses locally or at intermediate points.

Problem one is actually more general: given a globally-unique username, find out (in a machine-readable way) a piece of information about the user. At the same time, given your own password (or whatever), securely set a piece of information about you (also in a way that can be automatic). For privacy, you may want to demand some authentication in order to provide some sorts of information.

Problem two is then: specify a piece of information such that it will suffice from getting a text message to a person that piece of information is associated with.

Re:Jabber is a hack

[ProfessorPuke]

Maybe so. I didn't mean to be so negative, I've been wanting to add Jabber support to my own software. I was unfairly lumping it together with AIM, ICQ, and MSN (to the general public, all instant messengers are the same program with different colored icons).

One problem I have is that, as an external optimist, I assume that "IPv6 is right around the corner". That would mean that no one ever needs to use NAT again, and that a single computer can have multiple IP address for all of its users (or other purposes). And we already have a DNS system to provide mappings from human-readable strings to software-usable network addresses. I feel a little bad (and dubious) about seeing someone try to reimplement that, even if it is the surest way to ensure that the existing DNS features don't get broken.

The final concern I have with this Jabber approach is that its a complete layer above TCP- applications are written to the Jabber API and don't even know that TCP is involved. That's a good thing from the perspective of modularity and OSI-style layering, but bad in terms of evolutionary adoption. Existing software is written for the "static web", and that's where corporate money is going to focus future developement. Without a way to gradually shoehorn into popular internet applications, Jabber support may remain a hobby for open-source outcasts, and not benefit the majority of users.

As a transitionary step, someone could write (maybe someone already did?) a Jabber utility that behaves like a combination of DNS lookup and RPC portmapping- providing a ip address/portnumber in response to a JID string. Many applications could utilize something like that by adding just a few lines after their "hostname()" calls.

Two use cases where evolutionary Jabber ID support could be valuable:

• I'd love to read someone a "JID/filename" URI over a telephone, and have him type it into Mozilla/Konqueror/Internet Explorer and pop up a file I've selected to share from my workstation, without having to play around with "Dynamic DNS" services (which are unreliable, expensive, and an even worse hack).
• Groups of video-game players ("Clans", they were called, back when Quake came out) should be able to create a server for their own use, and get into it by supplying the server admin's JID into their client software. The gameplay can't afford the overhead of Jabber messages (or even TCP) slowing up the running & shooting, so there should only be a brief burst of Jabber traffic at startup to bootstrap UDP communications. (That's an automation of what today's players do over AIM messages).

  John Carmack is friendly to free software- when the inevitable Quake4 developement starts up, someone should offer him a simple Jabber interface as an optional way for players to connect to servers, instead of the corporate Gamespy / MSG Gaming Zone options that you see today.

(Now, if only I knew a way to mix freenet into this equation...)

Re:Jabber is a hack

[sql*kitten]

As are all "Instant Message" programs. They are a poorly-designed, short-sighted solution to a problem that should've been addressed elsewhere in the internet architecture.

You are correct, but it's a limitation of TCP/IP, which is very much a "lowest common denominator" protocol. The NETMBX feature of DECnet on VMS, in which nodes, processes and users are all principals is the most-correct solution I have found. Exactly the same protocol and API are used whether you want to to IPC between processes, instant messaging between users or any combination of the two, for example notification of status of a running process, or sending instructions. No need to worry about RPC, talkd, sockets and SMTP, etc.

Re:Jabber : great concept, awful reality.

[mosch]

I wish there was a way to find out who made a certain moderation, and send a guy named Guido to their house to find out why they did so. Preferably in one click.

Re:Value = N-Squared

[ProfessorPuke]

Actually, I don't think N-Squared is exactly the right function- you're really looking for Metcalf's Law. It states that "The value of a product that interoperates with others of its own type increases as the product becomes more common". This applies to telephones, ethernet cards, internet accounts, and even software like Microsoft Word. It was put forth by the inventor of ethernet in his graduate thesis. For a long overview of the maths, see
http://www.eff.org/Net_culture/ethernet_histo ry_gi lder.article

PS. Some texts will print "Gate's Corrolary" beneath the entry for Metcalf's Law. "If the product is software controlled by a single provider, the provider can discontinue interoperability with prior versions to force all existing users to purchase new products, indefinately"

plus...

[Avery_Zero]

Jabber is not just an IM client, it's also the server/protocol. Thus you can implement an IM solution where it would otherwise be impractical or pose a security hazard. I work for a medical firm, and the security issues with sending patient/sensitive information over a third-party IM network are enough to give people nightmares. They don't scare me, though. cause it's something that I would NEVER EVER allow to happen in my network.

Trillian, OTOH, while it's a great program (I use it myself) is nothing more than a combined front-end client for the existing IM services. Trillian will not help you when you are in a situation where opening a hole in the firewall for IM traffic is just not feasible (assuming that your networked office has Internet access to begin with, and that is NOT a given in the health care field)

AveryZero

Jabber shortcomings - not in the book

[mgkimsal2]

The book, from what I read of it (not 100% - maybe 60%) is handy, but didn't tell me much beyond the jabber documentation already out there.

What seems to be a huge issue for Jabber is user profile integration with databases. There seems to be an unsupported mysql hack, but the key is 'unsupported'. If you look in the Jabber mail list archives, every month there's people asking how to do it, but NEVER any answers.

Another great one that doesn't get answered - which the book doesn't address either - is the format of the user XML files. Each user by default has an XML file, and many people would like to create them programatically. There is no definitive resource which explains what's in a file and what isn't, and how to put one together. I've hacked something, and it works, but only after several attemps, and it doesn't *feel* good. I'm hesitant to try to add anything else lest I break what's working.

Jabber.com has a huge vested interest in keeping some of this stuff not in the public knowledgebase, because they charge (comparitively) a LOT of money for their stuff.

Last time I spoke with them the minimum to get started was $16,000. Their package offers a completely rewritten jabber server (better thread handling), Oracle and LDAP connectors, and a good Java applet client.

NO ONE in the open source community has even come close to having a Java applet client that is workable in a practical sense.

So yes, the protocol is open, and free, but there doesn't seem to be much consensus on tools, except from Jabber.com and they cost.

What I think Jabber as an open source project needs to focus on:

* XML user file definition and/or database support for user profiles
* Good applet client

:)

Re:Jabber shortcomings - not in the book

[Temas]

I like to make sure that all questions asked on our (jabber.org) jdev and jadmin mailing lists get answered. Sometimes the questions will get answered in our groupchat, or in other ways, but an answer is usually given.

As far as I know xdb_sql currently lacks a maintainer, but it's open source so maybe someone will pick it up.

The lack of good docs on the user file definition is valid, but at the same time it's not suggested you edit it by hand due to the aggressive cacheing used on it. We're starting a new docs effort right now and I'll make sure this is on the list.

The basic applet that is on sourceforge (here) is focussed on simplicity, but it does work, and I know people have built more off of it.

As to your concerns with Jabber, Inc., I don't know why they would want to keep any of that stuff secret. It's mostly useless to them since their server ships with a different XDB backend and their web client has a different focus than a pure applet approach.

Re:Jabber shortcomings - not in the book

[tzanger]

What seems to be a huge issue for Jabber is user profile integration with databases. There seems to be an unsupported mysql hack, but the key is 'unsupported'. If you look in the Jabber mail list archives, every month there's people asking how to do it, but NEVER any answers.

Screw MySQL; I want to see LDAP integration! That would rock muh sox.

Re:Jabber shortcomings - not in the book

[mgkimsal2]

Nope - doesn't work 100% of the time for all the features. We've got something working now, but there's strange things that the server adds in some instances which aren't documented - documented clearly, in any case.

Re:Jabber shortcomings - not in the book

[mgkimsal2]

Thank you for your response.

The basic applet is just far *too* basic to be of much use to our situation (and I guess many others). For starters, it assumes you want to allow people to create an account on your server - there seems to be no way to shut that off in the client.

The person I spoke with at Jabber.com told me they'd completely rewritten the jabber server to be high-volume capable, but that they wouldn't be releasing that code. Possibly ever, or possibly just much later. It's an investment for them, and they have every reason *to* keep is secret. If it's open, and people could implement it themselves, why would they pay Jabber.com?

I wasn't wanting to edit the user XML files by hand, but create them programmatically for users.

I've see the jdev lists and it looks like most questions get answered, but I'd gone looking and never found an answers on the xml file structure for user files, but many questions about it.

Again, thanks for answering. :)

Re:Jabber shortcomings - not in the book

[duffbeer703]

Jabber has a desire to stay in business and make money.

This is a departure from the traditional dot-com business model, but it will probaly work out ok.

IPv6

[Ilan Volow]

I've always wondered why we don't just switch the internet over to IPv6 and give each human on the planet their own address.

Re:Problems with the sample chapter

[cpfeifer]

Yeah I biffed the link. O'Reilly's web server is case sensitive so this:

http://www.oreilly.com/catalog/Jabber/chapter/ch 05 . tml

is not the same as this:

http://www.oreilly.com/catalog/jabber/chapter/ch 05 . tml

The correct link is the second one.

wrong

[Milkman Ken]

You can very easily cluster jabber servers. In fact, I have five running:

one for the main server

one specifically for AIM

one for ICQ

one for MSN

one for yahoo! IM

the four IM trasport servers have their own jabberd process. If a transport server dies (as they occasionally do), you can bring that server back up without affecting any other servers.

But you don't have to break up the servers this way. You could run multiple jabber servers, and place bandwidth restrictions on them so that when a jabber server got "full", it would stop receiving connections, so the jabber server above it in the chain would then forward it on to the next jabber server in the chain, or back up if it's out of children servers.

it's a relatively simple matter to setup an init.d script to monitor the health of all the processes, and restart them when and if they fail. I've been running a jabber server on one of our linux boxes for weeks now, and I haven't had to touch it once. I highly recommend jabber for intranets.

Re:wrong

[mo]

I was looking at jabber for a different purpose. I've heard a lot of hype that you can use Jabber for more than just an IM gateway, and Programming Jabber talks all about this. The task I evaluated it for is more like a message passing system for many automated distributed programs. The problem is that you cannot cluster many jabber servers in a high availiablity way such that one jabberd outage doesn't segment your network. In your example, what happens when the main server running jabberd goes down? What happens to the clients connected to it?

Re:wrong

[Milkman Ken]

either you don't understand how jabberd linking works, or I don't understand what you're trying to do. You can link different jabberd servers in any way you want. If you want a HA, failsafe system, put your jabberd's on different switched subnets in a hypercube pattern, and you can lose several servers or subnets without affecting the network as a whole.

You mainly seem to be concerned that since there in a single access point to the system, the whole thing can fail with a single attack on the main server. To a certain extent that's true. The user login data is kept on a jabber server, somewhere, and if that machine fails you lose the ability for certain users to login. I'm not sure if you can replicate user data across several jabberd's (with proper delegation and syncing), but it's probably not hard to implement.

Java Oriented Jabber Book

[Temas]

I've seen a lot of comments disliking the abundance of Perl/Tk usage in DJ's book. Recently Manning Publications released Instant Messaging in JAVA: The Jabber Protocols in print and ebook. It was written by Iain Shigeoka, and is ISBN 1-930110-46-4. It's a good read and goes over the creation of both a client and a basic server in Java, plus a good deal more.

Re:4555 pages

[Big Sean O]

It also contains the NYC Phonebook...

In 18-pt type.

Re:Prebuilt clinets?

[mgkimsal2]

For the record, most of the clients there suck. That's not to say they're all bad, or cast aspersions on the authors. Most of them say 'beta' or 'alpha' or 'version 0.2' - things like that. *MOST* seem to be someone's idea of a programming exercise, and having to wade thru 3-4 clients before finding a decent one isn't a good use of most people's time.

Gabber, GAIM and Everybuddy are fairly standard, but depending on what distro I'm using, they often crash. GAIM is most stable, usually. Having a perl command line client won't count as a 'prebuilt client' for most people. Likewise an Emacs client, while neato, won't cut it for most people used to AIM/Yahoo!. Konverse sounds nice, but I can't get it to run.

Under Windows, Winjab and myJabber seem the most solid/stable, but even they have problems. myJabber has some issue with futzing up if the person you're writing to has an 'away' responder on, and so on. There's so many little niggling things wrong with so many of the clients that it's frustrating to recommend this to people. AIM makes it look so damn simple. :)

language

[geekoid]

"I think equal time should be given to implementing Jabber using the two most-used languages, "

assembly and C?

Re:AIM

[Temas]

I beg to differ. I develop the AIM Transport. I've also worked on libfaim, and was around for the initial introduction of TOC. TOC looked promising despite it's odd ASCII protocol, but we continued work on OSCAR because TOC was considered a side project and not 100% supported by AOL. As luck would have it AOL has proved that decision to be wise many times. They have stopped work on TOC numerous times and have even removed features from it. OSCAR has continued to grow. When AOL started to try and block us (Jabber) we grew fairly confident that their changes were directed solely at Jabber. The blocks always happened after minute changes I made in the aim source specifically, and we were told so in an indirect way. Some ended up affecting other libfaim based projects such as Gaim. Until everything was figured out I was heavily considering a TOC implementation. The problem was that would have caused problems for other programs using TOC if they continued to actively target Jabber. I decided this type of behaivour would be unfair to the other projects, and it continues to allow them to always have a "pure" channel. In the end it has all worked out. We have fully figured out their attempted blocks and everything seems to be moving forward. There are specific IP blocks on some of the larger Jabber servers, but that's life.

Currently I'm actively working on the AIM-Transport (more information). and expect to put out a version 0.10 in not too long.

Re:Jabber : great concept, awful reality.

[cpfeifer]

Problem Number One: The server sucks.

Feel free to write your own. The protocol is completely open and documented.

Problem Number Two: The gateways suck

Feel free to write your own. The Jabber protocol is completely open and documented. The other IM networks you'll have to reverse engineer for yourself. This is not a jabber problem.

Problem Number Four: It's not neccessary.

In this case, fax machines aren't necessary because we already have the post office. EMail isn't necessary because we have phones. Phones aren't necessary because we have the post office.

Ah the sweet smell of progress.

Re:Prebuilt clinets?

[tzanger]

For the record, most of the clients there suck.

I agree wholeheartedly. When I went from Windows (ICQ99b) to Linux, I grabbed LICQ. Then when v5 ICQ protocol was being refused by the servers I went to Jabber and tried locating a client I could use that didn't pop up windows and didn't just have huge chat windows. In short, I wanted something light and fast and unobtrusive, like LICQ or the OLD Mirabilis client for Win32. I settled on Psi.

Psi is small, fast, cross-platform, simple and clean. I LOVE this client. I would strongly urge everyone who is using this client to send Justin a few dollars through his PayPal account to keep him actively developing his client. He responds to bug reports, accepts patches and tries to include feature requests. Open Source done right, I tell you.

Re:Jabber : great concept, awful reality.

[tzanger]

I'd mod you as flamebait, but it looks like someone else already did. Quit spewing FUD.

I've set up a Jabber server over 6 months ago and I'm using a client called Psi. I regularly connect to the MSN and ICQ networks through my server. I have not experienced one problem, much less the disaster you predict.

I prefer Jabber to the mess of carrying a cellphone, pager, checking email and the office phone. Yes I have them all but I only carry the cel/pager when necessary. I tell people to use Jabber or email if the need to get in touch with me, since telco charges are expensive and I'm not likely to be at the office anyway. My email client isn't always open but my IM is. Jabber is excellent for tying things together.

In a similar vein, if someone were to suggest to me firing anyone who suggested Jabber I'd end up firing them for being so small-minded. I've far less use for a person who won't consider new technologies than someone who is constantly on the lookout for the next best thing. Then again I'm the network admin for this company, so what do I know?

Jabber routes messages

[Earlybird]

You don't seem to know very much about the Jabber infrastructure.

The Jabber system depends on the routing of messages -- more or less the same way SMTP works, users are identified by a flexible user@host path syntax, except Jabber doesn't (afaik!) have the equivalent of the MX name server record. When I send a message to bob@snarkfimblepooh.com, it first goes to my own Jabber server, byzantine.no, which forwards it to snarkfimblepooh.com. A message can be forwarded multiple times if multiple layers of servers are involved, such as with external/internal servers or gateways. Jabber can be gatewayed to/from SMTP and other systems, indeed a lot of people, me included, use Jabber to access the AIM, ICQ, MSN and Yahoo! networks.

There is no central/global user name space because it is unnecessarily complex. It's a decentralized system that does separate the two concerns you list.

Coincidence

[ahde]

just yesterday the security bigwigs at the corp i work at sent down a draconian letter about instant messenger programs wasting bandwidth, and more importantly, exposing proprietary information on the internet.

A little over a year ago instant messenger clients were banned "without specific authorization" and were heavily used contraband. Now MSN Messenger is a vital part (and defacto standard) of corporate communications. Unfortunately there is a lot of productivity lost from A) Microsoft's shitty network that doesn't deliver near as many messages as you'd expect, and fails to report errors... and B) lots of information that is generated in impromptu conversations and lost when the chat is done. Then there is also C) the waste of bandwidth and D) the security and privacy issues.

Back in the contraband days I whipped up a quick VB program for our group, and was in the process of converting it to a java applet with direct socket layer communication when MSN Messenger was finally let in.

When the new email came down, I quickly responded with a link to imici.com for a solution and then threw in jabber.org and mentioned it as a free alternative. Any one of the above reasons (A-D) is enough to switch, but maybe not enough to overcome the inertia of MSN un-emoticons.

Re:Instant Messenger is a gross mis-representation

[infiniti99]

Jabber is a PROTOCOL, not an instant messenger

I've often wondered if Jabber should be renamed to something else to avoid the confusion. Currently when most people hear the term, they probably think of JIM (a client) or Jabber Inc. (a company that makes a server).

In a recent JSF conference meeting, someone brought up the idea of changing the protocol name to XMPP (eXtensible Messaging and Presence Protocol). I doubt it would ever happen, but something to think about.

Re:Jabber : great concept, awful reality.

[JabberWokky]

Problem Number One: The server sucks.

Yeah. Just like the server for the web. What's that you say? There are different servers for the web? Ah, must be like Jabber. There's a nice open source jabberd, a commercial Jabber server, one integrated into Oracle, and hey, look! An RFC for standards, just like the web.

But the web, as a concept, sucks because "the web server sucks".

Problem Number Two: The gateways suck.

I must say, I've only been using Jabber for a few weeks, but the gateways on the server I use (charente.de) seem to be perfectly stable. I have greater uptime than Trillian users, and the one time I thought the AIM gateway had problems, two users using the "real" windows AIM client were also booted. I'd say the gateways are at least as stable as the servers themselves.

Additionally, you'll find that the jabber gateways can't block senders, so remember that psychopath who is suing the company and you don't want to even know if he's trying to contact you? Too fucking bad, suddenly his messages pop right up.

Um. No. Incorrect. You can block messages, or you can use advanced presence to appear logged off to certain users or all users. Your perception of that incorrect "fact" leads us to...

Problem Number Three: The client sucks.

The client. *The* client. Ya know, the client for the web sucks too. I wish there was some choice in the matter. Unfortunatly, Mosaic keep screashing on me, and I can't get it to use Java. (You do realize that there are a dozen or more clients to choose from, yes?)

Problem Number Four: It's not neccessary.

I'll agree with you there. However, it's a unifying messaging protocol that binds together eveything from SMS to email to AIM to server alerts with intelligent routing, prioritizing and placing it into very scriptable XML documents.

Everybody already has a desk phone, a cell phone and email. Many people also have pagers, wireless email and such. The problem isn't a lack of methods with which to communicate. Adding jabber will not make your company more competitive, reduce costs, improve communication or improve morale.

Ah, but the idea behind Jabber is to unify all those things. To provide a standard of messaging, so you don't have to check 3 voice mail boxes, 6 text interfaces (email, pager, SMS phone, AIM, intranet), and so on - plus you don't have to worry about numbers or addresses changing. You can globally manage all your communications, and use a single check point, and hopefully eventually wean down your contact points at your lesure.

--
Evan The moral of the story? Shoot anybody who uses jabber, and you'll save yourself a lot of trouble in the long run.