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

[SlightlyMadman]

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.

This is not really true. Yes, the aim and icq transports on the main servers (jabber.com, jabber.org) were taken down. However, if you go to jabberview, you can see a number of other stable servers that have fully functionaly aim and icq transports running. I've been using jabber.earth.li for months now, without a single problem.

I think the issue is that AOL is blocking the specific ip adresses of the major servers. Remember, jabber is also fairly easy to setup locally, running the server and transports right on your box, or setting up an internal server on your network that everyone at work can use, and they can still talk to their friends through the aim transport.

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

[Tadhg]

Jabber works fine with AIM for me (I run my own server). Are you running your own server or are you connecting to one of the large public servers? If the latter, try to find a smaller one to use; AOL don't block Jabber clients per se, they block the larger Jabber servers.

I have some problems with ICQ, but I suspect I could fix those if I wanted to put in the effort (another poster commented that ICQv7 support is hard to set up but works fine after that). Yahoo! IM works fine, and MSNIM is good apart from not showing me as online to other MSNIM users (even though we can exchange messages). Again, I'm sure that I could fix that if I really wanted to.

Perhaps interoperability isn't Jabber's main function, but it's a major attraction for most people and a great way to make people aware of the program. And it works well if you take the time to work on it. The only other alternative for Windows that I know of is Trillian, which isn't free software.

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

[Sabby]

For those who have responded: Thanks very much! I will definitely look back into WinJab, since I just prefer the Jabber solution. The interoperability is important to me, unfortunately. For Jabber to take off, it either needs a larger base of users (hook the moms and pops) or it needs to operate with those IMs which already have the moms and pops hooked. But, I just prefer the philosophy of Jabber better.

Oh, and for the record: I used theoretic.com for my server. The operator (theo) has been so tremendously helpful that I used it, when Jabber.com and Jabber.org were too flooded to be useful for me.

Re:Jabber

[Sabby]

I agree with you, but I disagree with one point. 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. (which I'm assuming you do believe). I never use their proprietary features. File transfer, voice chat, group communication, etc. None of it is my main concern. I want a simple message capability. For Jabber to be useful for me, it must communicate with AIM and ICQ. AOL is the villain here, I already know that. I've been so utterly tempted to boycott Time Warner/AOL due to their handling of the situation "Other IM's cannot connect to our servers, it means lost revenue." (Well, a boycott could mean even more lost revenue.) But, I also need them for work. (Manager is an AIM user.)

I'd gladly campaign for moving my department over to Jabber, so we could have an internal server for it. BUT, with it 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."

Re:Jabber

[Sabby]

Heh. Everyone keeps talking about setting up my own server. Keep in mind that, despite being a programmer, I'm a guy running Windows 98 at home and Windows NT at work, who just wants to talk to coworkers and family members.

The JabberView solution sounds good, though. If there really is a good server out there with the capability, I'd switch to it. (I was using theoretic.com before.) I know that my coworkers might not ever switch, even the ones using Trillian. WinJab isn't pretty. Someone really needs to go visit the Trillian developers and convince them of the beauty of Jabber, so that they can add to the effort. Their client is "pretty" and their interoperability is rather solid.

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

[Peregrine]

The SMTP-t program simply acts like a smtp server. It handles the incoming mail, then maps the recipient email address to a jabber jid. The message is then forwarded onto the jabber account. The Theoretic-SMTP module goes one step further and extracts any attachment and places it in a storage area, then passes on the details of how to collect the attachment. This means that the basic text is sent quickly, and any attachments can be collected when wanted - a boon for dialup users.

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.

Review

[Monkey-Man]

I think this review says it all: "Quite simply, Programming Jabber rocks! When reviewing the book, I often found myself reading along, having a good time and getting excited about Jabber instead of looking to see if something was wrong or missing." --Jeremie Miller, Founder and Lead Developer of Jabber

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

Re:Jabber + SSL

[MassacrE]

Its a bit more interesting to have end-to-end encryption - encrypting the client to server connection doesn't guarantee that messages are protected at any other hop in the path to the other client. You also have to trust the server installation(s) and administrator(s).

Finally, if you don't have a registered ($) SSL certificate for the server, it becomes (AFAIK) impossible to protect yourself against man-in-the-middle attacks.

Prebuilt clinets?

[burts_here]

Are their any pre-built clinet all ready out thier? Please don't tell me to wirte my own, cos i have an amazing ability to:
1- fail to get the fundimental concepts (of anything)
2- write hooj crappy code that just loops and burns
3- I have been diagnosed as having an attention span of a small nat.
oh and i would use google to look for some but my companys web access is going a bit screwy at the moment and google has dissapered...

Re:Prebuilt clinets?

[Glove d'OJ]

Look at http://www.jabbercentral.org/clients/ for a list of clients. There are clients for:

* Flash (1)
* Java (6)
* Linux / Unix (16!)
* Mac (4)
* Mozilla (1)
* Newton (1)
* that Windows thing (21)

I believe they even have a gateway for RIM/Blackberry.

I concur that Jabber rocks.

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. :)

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.

Problems with the sample chapter

[comp.sci]

I experienced some problems when trying to go to the sample chapter 5 of the book. the server gave me a 404 and I did a quick search for the page and had no problems opening it with another link, but at exactly the same address. Maybe the admins check my webbrowsers vars and check if I came from slashdot. For me it works to just copy the adress into another browser window: [www.oreilly.com/catalog/jabber/chapter/ch05.html] I hope I could help

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.

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...

[zsa]

AFAIK, you can't cluster Jabber servers in the sense of lots of Jabber servers virtualized being a load balancer. At least not with the current reference implementation.

You can distribute the load, with users logging in to different servers and the jabber servers will route messages appropriately.

So yeah, if one of those servers goes down, the users who login to that server are hosed. Pretty much modelled on SMTP.

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).

Re:My big problem with Jabber...

[Chagrin]

Just don't think that this will stop me from beating his ass.

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?

[loply]

Email and Jabber are usually used for different things. Fact of the matter is, for inter-office comms, its just as quick to find the person and tell them as it is to start an email client and wait for the whole process to deliver their message, then wait for them to check mail etc etc. Jabber = *Instant* messaging.

Re:Hey, remember SMTP?

[zsa]

Last time I sent messages to an SMTP server, it couldn't even spell "hello" correctly.

Jabber is very similar to SMTP, but it also provides "presence", the notification that someone is actually logged in on the other end. SMTP is more "fire and forget".

Probably going to bring us a whole new dimension in online marketing, God forbid.

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?

[jordanda]

It seems to me that the essence of these IM applications is that they help people find other their friend's IPs when they change, either by logging on/off ala the modem era or changing computers. This problem has definatly already been solved.

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.

Re:Hey, remember SMTP?

[gadbois]

SMTP used to have exactly this capability via the RFC 821 SOML (send or mail) command. The command was deprecated in RFC 2821.

The only server I saw that implemented SOML was Zmail in Genera. It was pretty cool.

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.

M$ would be proud...

[zentigger]

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

...since this has been the general philosophy of Outlook for years now. This of course has also been the largest single security hole for years now too!

I think I still like being the human middleman, thank you very much!

Value = N-Squared

[FFtrDale]

...the value of the network increases with the square of the number of participants.

Where does this intuitively-obvious statement come from? How do we know that it's squared? I believe that it's true in general: that value increases geometrically as N increases. Who has run the numbers on this phenomenon, and where can we go to find descriptions of epiphenomena related to it?

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?

It seems that when people are investing resources (money, effort and time), it's seeing the actual numbers that will convince them. Anybody got references at hand?

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"

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.

Re:I use it every day

[Bartab]

This appears to even affect my aim traffic, as the AIM transport on the server does the actual relaying of messages.

Realize, of course, that the jabber server knows your AIM login information as well. This expands the situation from "Somebody may be sniffing my traffic -right-now-" to "I hope the server doesn't log my AIM login information so they can't login as me anytime"

Irrelevant if you run your own Jabber server, but that's not so common.

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.

Re:jabber: much more than just IM

[t]

From what I've heard is that MSN is having a hard enough time not dropping connections of people using the real MSN apps. Besides, the M$ pattern is to wait till their competition is nearly dead before they start "innovating".

t.

Re:jabber: much more than just IM

[test007]

I noticed Webmin having a module for configuring a Jabber server (at least in the Mandrake 8.2 distribution I use). This should make it easier for any intermediate Linux user to actually setup a Jabber server.

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?

[zsa]

This is interesting, particularly since the middleware area is full of so much BS and vendor lock-in.

I'd like to see if it's possible to wedge Jabber protocol adaptors in front of existing messaging systems. So the existing messaging layer could handle routing and Jabber provides the protocol definition.

From a portability perspective I'd look at JMS-compliance instead of MQ specifically. There are a lot of JMS implementations, including some open source ones (OpenJMS, Joram, Object Cube).

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?

[Temas]

Doh... yes new. We like lots of views, especially new ones ;-)

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

[zsa]

(Note to self: use "insanely expensive admin spetsnaz" at next staff meeting. :)

Yeah, I think the IETF effort is "too little too late". The IMUnified effort is apparently dead as well, since the last press release on their website is from mid-2000.

Is it just me, or does it look like none of the big mass-market IM players (AOL, MSN, Yahoo) really want an interoperable IM protocol? AIM has the market share, so they don't want to change anything. MSN has a desktop monopoly and want to do to AIM what they did to Netscape. Yahoo probably thinks they have a chance to dominate with a proprietary protocol if AIM and MSN can just tear each other to shreds...

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:Pretty good stuff.

[daserver]

How about creating two accounts? I know it doesn't solve the problem perfekt, but it works with all IM today :)

Re:Pretty good stuff.

[Peregrine]

One possibility is to use the filtering ability in mod_filter, so you put all your friends in one group, then make a filter which autoresponds a message to them letting them know that you are working at this time.

Jabber : great concept, awful reality.

[mosch]

Jabber seems like such a good idea at first, you may find somebody in your corporation saying 'hey, let's run a jabber server internally instead of using desk phones, cell phones, email or our shoes.' Let me be very clear about this, if somebody says this, even if they make it sound good, they should be fired on the spot.

Problem Number One: The server sucks. Once you start using jabber, you get the joy of watching your client disconnect for no apparent reason, quite regularly.

Problem Number Two: The gateways suck. Jabber has a cool concept where it can provide a gateway to other instant messengers, such as AIM. They crash. A lot. 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.

Problem Number Three: The client sucks. First of all, it crashes (have you noticed a pattern here, yet?), and secondly it has a terrible concept of what should happen to window focus when an incoming message arrives.

Problem Number Four: It's not neccessary. 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.

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

Re:Jabber : great concept, awful reality.

[cos(0)]

I think that you're exaggerating -- my client, Psi, never crashes, and I almost never get disconnected from the server, although it has happened once or twice to me, after I was idle the whole night.

It's my opinion that running Jabber in a company is a great idea -- it organized properly and good clients are chosen, it could be a godsend.

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:Jabber : great concept, awful reality.

[ginxd]

You must have been doing something wrong, i leave my client running for days and it NEVER disconnects. Also - id like to know how the server sucks? did you write it? Maybe you should buy the book so you can understand Jabber better, because it sounds like your talking about ICQ, which really gets up my arse.

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: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?

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.

Jabber message routing

[zsa]

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.

There was a "jabber as middleware" (JAM) intiative going on last year. Not sure if it's still active. My understanding is that it intended to morph jabber into a middleware message router which would have connectivity to the desktop.

What's always confused me about this approach is that there are already plenty of messaging systems out there. It might make more sense to shim a Jabber protocol adapter in front of an existing JMS implementation.

Re:Jabber message routing

[delta407]

There's no need to "morph jabber into a middleware message router" -- it already is. The core of jabberd is an XML routing engine called EtherX, which is pretty cool stuff.

Basically, the Jabber instant messaging protocol is a bunch of messages that are routed across EtherX, much like TCP routes over IP. To make use of EtherX as middleware, just use libetherx, connect to an EtherX router (i.e. a Jabber server), and talk XML back and forth. The presence, authentication, and messaging aspects of Jabber are independent of routing.

Re:Jabber message routing

[zsa]

So I can tell my boss he can safely drop his plans for MQ? ;)
It's accurate to say that, by definition, Jabber already contains the core functionality of a message router. That's a great starting point, but it's kind of like having an engine without the rest of the car. More work needs to be done.

AIM

[Hemos (editor)]

There's a lot of discussion about how Jabber hackers stopped working toward AIM integration.

The problem as I see it is that when most developers of these alternative IM clients try to hook into AOL's chat network, they do so the wrong way. AOL has a public protocol, and a private protocal; so, unless you want to worry about spending an hour or two every night working around the latest block that AOL institutes against your illegal hook into their private network, just use the public one that's documented and encouraged by the AOL folks.

So, Jabber people -- get AIM integration working via their public network rather than just dumping the whole thing because you can't hack their private area. The only downside is that users can't view others' away messages, which isn't really that big of a deal (if they're there, you can talk; if not, you'll see they're away but not necessarily why they're AFK).

I say this only because many of the comments so far are along the lines of "I used to use Jabber until AIM stopped working...". I for one would like to use Jabber as well and encourage them to rethink their approach to TOC and OSCAR.

An All-Linux Think Tank > Lycoris Review Part 1 of 2 Is Now Available

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.

IM != UDP

[delta407]

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.

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

[Asprin]

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.

Isn't that what LDAP is supposed to do?

Re:Jabber is a hack

[dekraved]

The solution to the first problem is already established in Session Initiation Protocol. Its idea of a network of servers being used to find a person operates similarly to both Jabber and DNS.

SIP blends naturally into IM and Presence as seen in this draft and this one.

Re:Jabber is a hack

[delta407]

Unfortunately, the user identification problem is complicated by the fact that there may be more than one person using a given IP address.

In fact, with Jabber, multiple IP addresses may be using the same username. Look into the concept of resources.

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

[p7]

What he was proposing was to split the message system from the addressing system. I believe his goal would be to make a mass database of unique ids. Essentially take all the IM user databases and merge them. Everyone that is a member of the database would run the directory daemon, which will register an address with the directory. Maybe the daemon would be queryable for services available. When I run a instant messenger using this database, I would just enter the unique ID for my target. The IM program would use that id to determine whether the target was online and where to find them. Now the IM directly queries the targets directory daemon to see if it is advertising a compatible protocol for the two to talk. The only port that is important is the directory daemon port. I believe this was the intent of the first post. With this one database we could possibly find out exactly what ip address and port the target wants to communicate using and all protocols and services they will respond to (they may even be pointing you to a proxy so their real address isn't available or can't be addressed using the internet). Could be really cool if someone set this up.

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.

4555 pages

[Anonymous Coward]

...really?

Re:4555 pages

[Big Sean O]

It also contains the NYC Phonebook...

In 18-pt type.

Shhh

[21mhz]

Please, everyone, don't tell CNN about Jabber.
If the journos learn that it's a new haven for "HACKERS", where they *gasp* can use encryption, our asses will burn.

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

Not Jabber's fault.

[Big Sean O]

If I understand correctly, AOL is the one that is keeping Jabber from connecting. It's not any lack of capability in Jabber. AOL is afraid of a distributed open-source, ad-free alternative to their IM dominance.

Jabber clients are quite good. The fact that O'Reilly has a book on it means that it's probably robust enough for a production environment.

Jabber could be right for you if:

• You're on an Intranet (why send your chat out to the big bad internet),
• If you have any concerns about a giant corporation monitoring your chat ("All Your Bytes Are Belong To Us"),
• You want to prevent 'extra-curricular chat' (you can close off the server to just your staff),
• or if you're paranoid about security (it does SSL).

Plus, no ads.
---------

Re:Not Jabber's fault.

[t]

If I understand correctly, AOL is the one that is keeping Jabber from connecting. It's not any lack of capability in Jabber. AOL is afraid of a distributed open-source, ad-free alternative to their IM dominance.

I find statements like this quite amusing. The fact is that AOL pays $$$$$ for the servers, in return they expect you to view ads. You come to /. and for that free access you have to view ads. What is so hard to understand?

t.

Re:Jabber? What a POS

[ginxd]

adv for jabber: 1. open source 2. modulised 3. secure 4. logically well defined protocol 5. easily expandable language 6. based on xml 7. NOT OS specific 8. supports MORE chat protocols adv for trillian: 1. it looks good

Not too spam-prone

[21mhz]

Probably going to bring us a whole new dimension in online marketing, God forbid.

Actually, designers of anything IPM-like in the recent 5 years are well aware of the spam problem. Jabber, by default, won't accept messages from anyone/anything beyond your roster. The only
threat I can think of is that servers start sneak text ads inside vital message fields (any extensions can be easily ignored). But then, you can always change a server or roll your own, because the Jabber network is totally open.

He's too busy with Python...

[Big Sean O]

to go around breaking legs...

Not that hard..

[dmouritsendk]

If I build a Jabber solution, it will be in java, so PERL/TK samples don't do me a lot of good

Dont read the syntax, read the semantics ;)

(May i suggest maybe looking at Dr. Robert Sebastas exellent book "Concepts of programming languages"(isbn: 0-201-38596-1))

Re:Jabber? What a POS

[Strog]

You talking about the server or a particular client?

There are dozens of clients for you to check out if you don't like a particular one. Trillian is great if you are on Windows but what are you going to do on any other platform?

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:IPv6

[styxlord]

I am not a number ... I am a free man!

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.

Re:wrong

[hpavc]

you would do this via some xdb_auth_* mechanism such as sql or ldap.

i assume the clients could be blind to the fact of which jabberd process they were connected to if you used xdb_auth_sql and a system such as cisco distributed/local director.

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.

My main problem with jabber

[jacobb]

I used jabber extensively for a while about a year and a half to a year ago. Only on my Windows partition, however.

Well, apart from WinJab being clunky and having memory leaks, etc....
My problem with jabber was that both the ICQ and AIM transports were always broken. Occasionally one would work, but it would usually break in less than an hour!

I hear that they've taken the main server's transports off - can anyone tell me the performance of other servers' transports that I've heard about. How about the best small, simple windows client.
I'm looking for something that starts up immediately, is small, elegant and doesn't vacuum up my memory.

Cheers!

(OT) Inter-Machine Communication

[whterbt]

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

Imagine the possibilities - we could have a global network of computers and other devices that communicate through a common protocol! Oh, wait...

Reminds me of the "TCP over HTTP" April Fool's RFC.

language

[geekoid]

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

assembly and C?

Re:Jabber is worse is better?

[21mhz]

Does this mean Jabber is "worse is better?"

See for yourself.

I understand it...

[Big Sean O]

In fact, I don't blame AOL. They're top dog because they got there first. I don't have a problem with that.

I just thought I'd correct the impression that "Jabber sux because it can't do AIM" when the truth is something different.

FWIW, I don't use AIM, but it's not because I don't like the ads: I don't use AIM because I don't have any friends. =(
-----

MS is good-time charlie now...

[Big Sean O]

When they're doing everything known to man in order to jack up their IM marketshare. "Jabber, you bring 50,000 more users? Come on in, the water's fine!"

Just wait until they start to get numbers like AOL and watch how picky they get about who they play with.

The more games I see various corporations play, the more thankful I am that there are open source alternatives.
-----

Re:My big problem with Jabber...:LINUX HA

[bernz]

Check out the linux High Availability project and most specifically their HEARTBEAT software. Basically, if any server running heartbeat goes down in a variety of different ways, a secondary or tertiary or n-ary machine takes over the tasks specified. It can work with any service that you place in /etc/rc.d so I don't see why Jabber wouldn't be part of that.

Instant Messenger is a gross mis-representation

[Robotron2084]

"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.

I wish people would stop thinking about Jabber as simply an instant messenger, in the same way Microsoft has realised that MSN Messenger isn't simply an instant messenger. The data exchange of .NET is instant messaging, and Jabber epitomizes the open source equivalent.

As things move on from static HTTP GETS to dynamic sockets, companies will look for products that can easily push and pull data asynchronously to servers. And Jabber excels at this.

Jabber's modular framework allows for the simple server-side creation and client-side discovery of whatever xml namespaces you'd like for whatever programs you make. As in the book, you can receive CVS commit notifications, stock quote notices or send and receive email with Jabber.

Re:Instant Messenger is a gross mis-representation

[Robotron2084]

Erm... don't know where it went, the last paragraph should be:

Jabber's modular framework allows for the simple server-side creation and client-side discovery of whatever xml namespaces you'd like for whatever programs you make. As in the book, you can receive CVS commit notifications, stock quote notices or send and receive email with Jabber. Map your jabber components onto xml tags in the config file using TCP sockets, command line progs and XML-RPC. Then clients are able to discover features on the server using the Browsing service.

Jabber is a PROTOCOL, not an instant messenger.

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:Instant Messenger is a gross mis-representation

[Robotron2084]

Good point, although I'm not too keen on changing Jabber into another acronym.

When I was trying to explain what Jabber was in a faq it became clear to me from the site that it's not an easy thing to get across. Their older site didn't have a concise explanation anywhere except that it was an instant messaging and presence platform, which don't cut it in my opinion.

I must say though, I keep re-writing this sentence trying to find a reason besides aesthetic taste not to rename it, but XMPP sounds much more descriptive than Jabber. At least it might help to categorize the Jabber protocol as an XMPP protocol, and create the category in the process.

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.

I tried to do the db stuff once...

[willis]

I tried to change xdb_sql for a training project at the company I work for -- it was very, very difficult, and although it sortof worked in the end, I wouldn't doubt they threw away my work.

Because the XML is extendable, it's a pain in the ass to place inside a "useful" database (i.e. queryable for the extensions). My team and I looked at the docs for quite a while, but the message flow (and the configuration to send the xdb packets over from the "main" jabber server to the xdb server) was very unclear. A lot of my time was spent comparing log files and making very minor changes in XML structures.

There's a java xdb out there that I ended up hacking with to make my stuff almost work, but it was rough going, too. I think the real technical problem (besides coping with Jabber's formats, etc) is difficult -- mapping XML queries ->SQL queries, XML->relational format, and relational format->XML are all very difficult operations, with no real proven way to work with yet.

It does seem like xdb is the great missing point in the OS version of jabber -- perhaps that's on purpose to encourage large users to go for the commercial version. It's easy enough to edit config files, etc, for a server for 10-100 people... but when you're talking about firmwide/production usage with thousands of users (and batch migrations, and failover, etc) having a db at the backend becomes really important.

Besides my xdb troubles, though, I was pretty impressed by the system. The clients aren't the best, but the protocols looked like they had some serious promise....
Best of luck to those tackling xdb, though!

willis.

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.

Jabber : what a pain !

[Reez]

I had to work on Jabber with other guys, we were paid for that. I wrote the first version of xdb_sql. But working on Jabber was such a PITA that I left coding and never looked back. Sound coding standards are a must for any ambitious project. So give jabber hacking a try ... You'll see what I mean. At least, when you stop, what a relief ! :)

Re:Jabber? What a POS

[Reez]

against jabber : bad server implementation