Slashdot Mirror

By making a project open source, you don't just gain hackers adding more lines of code. You also gain the input of philosophers, code evangelists, people with great ideas, artists, and the like.
----

Eric
--

XML is a bad choice for protocol messages. The use of XML carries far too much baggage for a lightweight/automated implementation.

Not necessarily. XML parsers have now been implemented that are as small as 1.5K of code. And Jabber doesn't use full-blown XML with DTDs, automatic validation, and all that; it uses it for the sole purpose of creating a structured data stream.

I've been thinking for some time about how a good Internet-wide IM system could be used not just to send silly chat messages back and forth, but also to be a method for client-server interaction.

The Jabber protocol would be excellent for this purpose. We are exploring such possibilities as embedding XML-RPC or SOAP messages in Jabber to promote client-server interaction over the same stream you might use for two-way human-to-human communication. The existing Info/Query mechanism in Jabber already does this, to a certain extent.

The XML message format requires each piece of software to contain an XML parser and also (from what I've seen) limits the kinds of data you can send back and forth. Why not do what HTTP does -- not care about the content, just specify a header format and let arbitrarily formatted data be attached?

XML parsers are readily available, and, as I mentioned above, can be quite small. As for percveived "limitations" on data types, any text-format data can be expressed as XML and sent through a message extension. For binary data, we use the jabber:x:oob (out-of-band data) extension to pass HTTP URIs for data retrieval, which keeps the data from having to be sent if the receiving client does not support binary attachments.

In addition, Jabber makes the unfortunate choice of not wanting anything to do with crypto on the protocol level; instead, it wants client folk to slap OpenPGP on top of it.

First of all, Jabber already supports SSL connections (via the OpenSSL library) for transparent transport-layer encryption. The only drawback here is that not many Jabber clients support SSL.

That being said, I would like to see Jabber support crypto at a level in between the transport layer (SSL) and the end-user level (OpenPGP). But it's not going to be supported until it can be done right, as it's my belief that poorly-done crypto support is worse than no crypto at all. And I might also point out that competing protocols either use no encryption, or use something that's a total joke in terms of real security (e.g., ICQ). Then, too, there are US export regulations to consider (and we have very few non-US developers at this point that could mount any sort of Jabber crypto effort).

Eric

The preceding was my opinion only, and not the official opinions of Jabber.com Inc. or The Jabber Project.
--

What these companies want is to wrest the eyes and clicks of the countless AIM users into using their advertising supported clients. The "open" here is a misnomer that only means "interoperable" which is far from the same thing. It doesn't matter that the huge, dominating overlord is made up of a number of seperate organizations, it's still a huge, dominating overlord. The word for this type of union is "cartel." If you want a real open standard for messaging, you want Jabber. Jabber is an open standard, it's open source, and most importantly, it just makes sense. There are many reasons why it's better than the current adware messengers, but the best reason is that Jabber is a decentralized network. There's no single, monolithic entity that you must rely on to supply your connectivity. In other words, Jabber is built on the same model of the internet itself.

So download Jabber, but don't sign up at jabber.(org|com). No, instead you should start your own server (if you're able), or encourage your ISP to set up a local server. I mean, what would you rather be known as, "foo82351@jabber.com", or "yourname@yourhost.net".

I would highly encourage you to visit our site Jabber.org for all your development needs, and Jabbercentral for your end user related needs. Even more so we encourage you to download our server and seutp your own system, because we are similar in idea to how email works, anyone can run a server and talk with all the currently existing Jabber servers.

With ~20,000 users between just the public jabber.org and jabber.com servers we're growing extremely fast, and we hope that others will take part in our growth.

--Temas
Jabber ROCKS!

I think we ought to have a broader view of instant messaging as internet infrastructure. Instead of simply looking at it as person-to-person communcations, we should look at it as a system-to-system or person-to-system enabler.

Imagine, I want to access info off of my PC at work from home. I had an IM based service on my PC at work and an IM based client that built queries to the IM service. The client "system" communicates with the service "system" to get the requested info (such as my schedule for the day) all via IM.

Realize that what IM does is allow two "hosts" to communicate anywhere on the net (firewalls be damned). This could be a new standard communications medium for n number of new services. We should fight that the CLIENT API gets standardized (or at least opened). This may not happen, but at least the servers could interoperate and you could use an "open" source system like Jabber for the development of the new innovative services.

I'll take the bait.

What kind of innovation? Microsoft has done a reasonable job at _implementing_ technology (with a little help by stealing or if you prefer buying it from others) and a great job at delivering their goods to the market.

When I think of innovation I think of the guys who originally wrote ICQ, or Napster. And for example, bringing us back on topic: Jabber.

For reasons unknown to me, there are at least two major instant messaging systems owned by AOL: ICQ and AIM. Microsoft has something like that as well IIRC. Instead of those technologies working together, they try to make sure they don't.

Jabber allows people to install *one* IM client and communicate with users of all these other systems, making instant messaging a useful product again. Now that's innovation. And it does require reverse engineering the AIM/ICQ protocols.

Besides, suppose a company is actually good at innovation. Anyone reverse engineering a product will _always_ lag behind.

Of course the answer to the original question would be that the company should be held liable for delivering sloppy work. The Pig Lating example is a bit over the top but illustrates nicely. Any encryption method that doesn't scale with DES,MD5 and the likes should not be allowed to walk around freely in software that is being advertise as secure.

If the DMCA changes that then very soon I will send an e-mail encrypted into 1's and 0's and sue the reader (or maker of his/her mail client or OS) for everse engineering.

Jabber is decentralized in the same sense that email is. Just as every ISP or organization runs its own email server, they can run their own Jabber server. However, your roster (the Jabber term for what That Other IM System calls a "Buddy List"(R)(C)(TM)) may contain users on any Jabber server; when one of the people on your roster sends you a message, or presence information, or whatever, their server contacts your server, which passes it on to you. It's not quite as decentralized as a Gnutella/Freenet setup, but it's a lot more convenient for the end user. And there's nothing stopping you from running a personal Jabber server on your own box (or your site's NAT box, or whatever); if you've got a DNS name pointing to that box, other Jabber users on other servers will still be able to add you to their rosters, and will get your messages and presence as they would anyone else's.

Jabber IDs are expressed as "user@server," just like email addresses; this would make it easy for an ISP to give its users Jabber IDs identical to their email addresses, and with the same passwords for authentication, if desired (assuming they set up authentication correctly). In fact, Jabber IDs may include a third element, the "resource" (making the Jabber ID format "user@server/resource"), allowing a user to log into Jabber multiple times, from different locations and/or different devices.

Since everything in Jabber is done through the server, clients can be very simple. Even so, they can support connectivity to other IM networks (such as ICQ, AIM, Yahoo!, MSN, and IRC) via services known as "transports" that are run on the server side and translate between the Jabber protocol and "foreign" IM protocols. (Incidentally, if you use the IRC transport to access IRC from Jabber, the IP address the IRC people will see is the IP address of your Jabber server. This is both good and bad; good because they don't see your real IP and hence can't portscan you, bad because it makes it easier for server admins to block all Jabber users if they get honked off at us.) An administrator can install a transport, and the users of that server can begin using it immediately, without any changes required to client software.

Finally, in regard to the topic of this article: Jabber can collect personal information about its users, if (and only if) they choose to provide it. (It stores it on the server, and in the Jabber User Directory, in the proposed XML vCard format.) This information can (but need not) include birthdate and/or age. How this will balance with the requirements of COPPA is a subject that has been weighing on my mind for awhile now. My gut reaction is "we just write the server; it's up to whoever runs it to follow the policy," but in some senses, that's kind of a cop-out. Perhaps one of the things Jabber.com should work on is a system to catch all users who have entered birthdates that would make them less than 13 years old (i.e., before July 3, 1987, as of the day I'm writing this) and send them notices and/or automagically delete them. In essence, we would be enabling a Jabber server administrator to do exactly what ICQ is now doing. I know that some people might view this as caving in to The Man, but, as the saying goes, "Dura lex, sed lex." ("The law is hard, but it's the law.") I'm sure ICQ doesn't like the thought of having to take this kind of action any more than I do, but...

For more information about Jabber, visit one of our Web sites, the JabberCentral site, the open-source development site, or the company I work for.

Disclaimer: I'm one of the core Jabber.org developers, and an employee of Jabber.com, Inc., but I don't necessarily set policy or speak for either organization.

Eric J. Bowersox
Software Engineer, Jabber.com Inc. (subsidiary of Webb Interactive Services, Inc.), Denver, CO
Developer, Jabber Project (author, ICQ transport)
--

The protocol and server just hit 1.0; this is a real, working system. Good clients are available for X11 and Win32, and are in progress on other platforms.

Jabber is interoperable with AIM, ICQ, and (soon, at least) IRC and e-mail. Interoperability is server-side, so that clients don't need any changes to support new protocols.

Link: http://www.jabber.org

A lot of exciting things are happening on the jabber front. As I type this, developers are finishing up a proposal to the ITEF to make Jabber a standard. You can check it out at core.jabber.org Also check out jabber.org (general site), jabber.com (for businesses), and jabbercentral.com (for end-users).

A lot of exciting things are happening on the jabber front. As I type this, developers are finishing up a proposal to the ITEF to make Jabber a standard. You can check it out at core.jabber.org Also check out jabber.org (general site), jabber.com (for businesses), and jabbercentral.com (for end-users).

I like the way Everybuddy does it - each user on your contact list can have an arbitrary number of user IDs for any of the supported IM systems associated with it. If the user comes online on any of the accounts it shows the user as online. I think there's a way to set a preferred protocol to use if the user is online using more than one system.

Also see the poster who mentioned Jabber.

Incidentally, their page is at jabber.org.

--
grappler

For example, you could talk to user@aim.jabber.org and user@icq.jabber.org without a naming conflict.

The Jabber universal instant messaging client has an IRC Transport.

Jabber - open source messaging. No doubt somebody else is posting this as I type, so sorry if it's redundant :)

mod_virgule, the engine behind Advogato, is written as an Apache C module, a fairly unusual choice for server-side scripting. My experiences with it have been very positive, as have been the other sites that use it (Skolos, a discussion forum for sexuality issues; Jabber.org, the Jabber developer's website; and a couple of others in the works). Advogato has been slashdotted several times now, and the load meter barely moves. That's one of the really nice consequences of programming in C :)

There are a few reasons why mod_virgule was a more pleasant programming experience than your usual CGI script in C. First, Apache's pool mechanism lets you use memory without having to worry about freeing it. It's almost as convenient as using a garbage collected programming language. Second, the Apache module API contains a lot of functions for regexps, tables, lists, and so on. These are the most important features of Perl that are lacking from raw C. It's nice to be able to write code in C that has a bit of a Perl "feel".

Finally, mod_virgule uses XML extensively in the backend, using Daniel Veillard's excellent libxml for parsing and handling. The use of XML makes the code for the site a lot cleaner.

So, I suggest that you not reject C out of hand just because it has a reputation for being more difficult or time-consuming to program than your more popular interpreted scripting languages. For what I was trying to do in mod_virgule, it turned out to be an excellent choice.

And I'd hardly call the people who code open-source "wannabe programmers" - I'd imagine they're far better coders than you are, seeing as how you're so closed-minded I doubt you ever try and learn new techniques.

This was not an attack at _all_ open source coders. That would be insane. It's simply a comment on that fact that we have hundreds (!) of Instant Messaging clients, and only three Instant Messaging _Servers_ (Jabber, gicqd and KiT) that I know of.

Linux is an excellent server platform, but has not made the leap in _current_ server-side apps, at least for the ones I'm looking for :)

And I do not profess to be a programmer, I know my strengths and weaknesses, and programming is one of my weaknesses.

i think that jabber was going to add napster like file searching...
here is some more info...

nmarshall
#include "standard_disclaimer.h"
R.U. SIRIUS: THE ONLY POSSIBLE RESPONSE

We're working hard on integrating Jabber into Mozilla as a native client. Since Jabber is based on XML and Mozilla's own XML functionality is quite advanced, it should be an interesting combination :)

Unfortunately, it's proven quite challenging to integrate two rapidly developing platforms, so if anyone would like to help and can eat XUL/JS for breakfast, let me know.

With Jabber and Mozilla, you'll instantly have AIM, ICQ, Yahoo, MSN, and others as we progress. Of course, there's no way in hell it will ship w/ the offical Netscape, but it will be part of Mozilla.

When I get the cash together :) I have a nice 'papper' design for a pda/wearable, with 'no particular interface' designed to put info on a display, or use a voice synth, voice recognition may now be achieved through sphynx2, and maybe a home made twiddler clone - for my hand :)

This really is very close to what a werable is, but, that is all I need a mobile pc to do, with the addition of checking email, etc... using a packet radio interface, and using ham radio frequencies, and have IM-ing with jabber maybe even rig it up, so I no longer need a mobile phone, just transmit / receicve the voice data through the system to my home phone :)

A small ammount of AI would be a good addition, using another suggestion, so that you can tell the wearable a persons name, and what you might be engaging in with this person (great for keeping track of multiple girlfriends :)), and it will be able to, at the least, relay back some notes that you have previously left.

In summary, it would make my life easier, and I can think of the more imortant things, like programming, internet & persons of the oposite sex :)

Disclaimer: I work for Webb Interactive (the company that now employs Jeremie), on Jabber-related software.

Eric
--
"Free your code...and the rest will follow."

We don't need more applications... We need better applications. Instead of saying, "I want to write my own web browser," why not contribute to Mozilla instead? Instead of writing "Yet Another MP3 Player," contribute code to one of the more established ones.

You're missing the point on how Open Source software development produces better software. If you think in terms of evolution or "software Darwinism", then the variety of 30 competing projects is a good thing. Instant Messaging on Linux is still a new niche where a lot of experimentation is going on. Eventually, things will settle down and a few successful clients will emerge. If projects like Jabber are any indication, then the end result is going to be software that is better than commercial alternatives...a common theme with OS software.

You do highlight an important challenge: developing reputation managers for Open Source. Something like Epinions.com, but geared to our community. Something to help you seperate the wheat from the chaff.

When using freshmeat, I usually have to scan several entries. By looking at their various summaries, Web pages, and frequently by trying out a few packages, I filter out the projects that don't seem to be very well supported. This usually works, but it is time consuming, and doesn't take advantage of the fact that someone else with similar interests as mine probably just did the same thing a week ago. Collaborative Filtering, which is just a form of reputation management, would come in real handy. In fact, I'd be suprised if FreshMeat wasn't already working on this.

Of course, Mirabilis's whole point was to sell servers to companies that want to have instant messaging in the office. The original idea was to have your *own* ICQ server at work.

> 1. Packaging a finger daemon with the
> chat client, so that people can use
> finger to see who's logged on, ...

if security is a concern, finger is probably not the best way to do this, as it is one of the first things a lot of administrators turn off...

But you're right, it would be good to see a nice, open, and *secure* instant message protocol. I think the Jabber project seems to be on the right track.

The IETF is working on something, but... I wouldn't expect much from them for a while. Your best bet for something that will work, and be guided by technical and not political motives, is probably Jabber.

The structure that AT&T is trying to setup, of allowing connections to other servers, is very much like the free, open alternative that the Jabber team is creating. Although we are not creating a client only solution. We have a server based around a XML stream protocol that allows pluggable transports for different protocols, with clients for almost every platform. This allows for an extremely extensible system. Currently we have betas for AIM (libfaim has not been blocked throughout this entire ordeal of blocked clients), ICQ, and MSN is in the works. I have just completed a group chat (similar to ICQ) module as well.

Although the side of having an IM client that can connect to a lot of others is appealing, Jabber is much much more. We have plans to jabberify many programs (CVS, Abiword, Bugzilla, and more). By doing so the power of these programs increases in many orders of magnitude. Just imagine multiple working on a document in Abiword at the exact same time, or CVS automagically pushing you updates, or Bugzilla yelling at you when you get a new urgent bug? It all sounds really appealing to me.

Being free and open source, Jabber has the potential to be so much to the internet, and help settle some of these annoying arguments that a lot of the corporate players are having. Come visit us on IRC in #jabber on openprojects network or just visit the web site.

The structure that AT&T is trying to setup, of allowing connections to other servers, is very much like the free, open alternative that the Jabber team is creating. Although we are not creating a client only solution. We have a server based around a XML stream protocol that allows pluggable transports for different protocols, with clients for almost every platform. This allows for an extremely extensible system. Currently we have betas for AIM (libfaim has not been blocked throughout this entire ordeal of blocked clients), ICQ, and MSN is in the works. I have just completed a group chat (similar to ICQ) module as well.

Although the side of having an IM client that can connect to a lot of others is appealing, Jabber is much much more. We have plans to jabberify many programs (CVS, Abiword, Bugzilla, and more). By doing so the power of these programs increases in many orders of magnitude. Just imagine multiple working on a document in Abiword at the exact same time, or CVS automagically pushing you updates, or Bugzilla yelling at you when you get a new urgent bug? It all sounds really appealing to me.

Being free and open source, Jabber has the potential to be so much to the internet, and help settle some of these annoying arguments that a lot of the corporate players are having. Come visit us on IRC in #jabber on openprojects network or just visit the web site.

URL: http://www.jabber.org/

--

for whatever reason it seems people remain private and keep to themselves without a who's online option, and a message feature

The new buzzword is "internet presence" - this is the facility provided by ICQ's 'contact list' for example, and soon to be provided by open messaging systems like jabber. You know the idea - whenever you come online your "internet presence" client contacts a server and forwards the information about your change of state to all your contacts that are also online. This is the right way to do things - once the technology is generally available in a non-proprietary form (and a non-amateurish form - jeez ICQ is weak) it will spread like wildfire. You'll see online communities popping up like they never have before.

Of course, once you know someone is online you can do all kinds of things - send messages, chat, send files, news, forums, other things that haven't been thought of yet. Widespread use of internet presence will essentially cause the internet to be reinvented yet one more time.

I guess what I'm saying is: don't feel too bad about the demise of the good 'ol BBS - progress marches on, and what's coming next will beat the heck out of BBS in every way.

I think this is an issue of two companies arguin over who 'owns' their users. what they don't relize is, no one owns the users.

This is one of the things that started development of the Jabber project. We're designing a non centralized system, where users belong to themselves. Servers are not set in stone, but instead behave simularly to email servers. Anyone can bring their IM to any server. Any ISP can setup their own IM server, and provide their users with what they want, without 'ownership' of the user. The user can just as easily setup his/her account on a different server.

But we've taken it a step further. Any of these servers can then talk to AIM, MSIM, etc on the server level. We let you choose.

No one owns us, and we shouldn't tolerate NOT having a choice of what we want to do with IM'ing, no more so then we are limited to what we do with email.

The corperate 'wars' over user ownsership are silly, and bad buisness for them. Hopefully, for their sake, they'll wake up and smell the coffee before IM is a commodity, and their users flood to other providers.

Feel free to jump on at Jabber.org. We're not only developing a new, OSS, IM system, but one that INCLUDES the capability for anyone to run a server, and talk to anyone else running them, AND the ability for these servers to talk to AIM, MSIM, ICQ, Yahoo, etc.. for you..

Hopefully, system such as Jabber>/A> and the IETF effort will assist in effort. The IETF standard should make it so that users can communicate between different services. Right now, Jabber is the closest we have to a workable system that can acknoledge systems outside of it's own.

This is exactly what Jabber is all about, building a whole new IM architecture that is also transparently compatible with existing products.

It still not user-ready, but it's getting there quickly.

I really really do NOT want a browser/email/chat/IM/irc/diskdefrag/screensaver mess. I want to pick the best program for each, so since I won't be using 90% of all that crap anyway, please save me the download and disk space and RAM and stability for something useful. Opera is fantastic at this: it's stable, fantastically usable, and does it's thing superbly(except for a few Javascript, CSS, and PNG annoyances). While I eagerly await something from the Jabber project and am glad to se it get support, I was somewhat dismayed to hear it was being included in the Mozilla project. Mozilla may be great, but it seems it's going to be 25Mb great when it's done.

So far it seems to be just text messaging that they're working on, and no encryption. I've been waiting for them to do encrypted messaging. Encrypted voice would be great also.

All in all, this is great news.

numb

...Mozilla gains market share as Linux does. This is enough of a presence to restrain incompatible web standards I hope

Don't forget that AOL will also be pushing Mozilla heavily, in its netscape 5 incarnation. Also, many teens will get Mozilla just to get Jabber - never discount that factor, it worked for ICQ. Then there is the fact that Microsoft won't be able to engage in much of it's usual strongarming with OEM's and ISP's, with the Justice department on it's tail...

I'm sure there are other factors also, like Mozilla just plain being a better, more stable product, with development that will never stop. The bottom line is that things are looking pretty good for Mozilla at this time.

Eventually, once we have Jabber out the door, we will support this type of cummunication. Check out www.jabber.org

I know this is probably wishful thinking at this point, but it would be cool...

--Jamin Philip Gray
jamin@DoLinux.org

One project that will eventually come out of the Jabber IM project is JNX, which would be expanding certain *nix functionality with XML data storage/routing. This actually goes one step further, and allows any program to transfer data to any other, by sending XML 'streams' of data. With the right transports, one could extend it further by having a 'Configuration Repository' for the system, which could actually store configuration data in something like an XML flat file, or even a MySQL database. Imagine 100 *nix desktop systems, all controlling their configuration via XML and a centralized database. This is some of the things that we will be looking at within the next year or so. www.jabber.org

Our press release is here, and we have an additional page of background information here.

Eric
--
"Free your code...and the rest will follow."

Hey all you /. folks! :)

I am actively helping in the Jabber project, and I am sad to see so many hastily posted comments here on /.! To make some corrections to the posts that I've seen floating around, allow me to submit the following comments:

1) Jabber is not a rip-off of anything. Jabber is completely different than other IM systems. The first thing that sets it apart is that it is open source and GPLed. But what is more interesting than that is the fact that Jabber has the ability to speak to any type of communication protocol that ANYONE would care to develop a module for. The thing that makes this even cooler is that the modules just need to be installed on the Jabber servers. That way a Jabber client (like the one that is going to work WITH Mozilla) can instantly have access to other protocols as soon as the server has been updated - no updating of the clients is necessary.

2) I have to PARTIALLY agree with the posts about Mozilla getting bloated. But I say partially because I don't believe that most of the posters (especially the AC's) realize that what makes Mozilla bloated is the MODULES (not sure what the "official" term is for modules in Mozilla). The Mozilla Jabber client just works WITH Mozilla and may not necessarily be included in the binaries and so forth and I can't imagine it being required in source packages. DaKrushr already wrote a good post covering this.

3) Jabber has hardly anything to do with Mozilla. Yes, we will be developing a CLIENT to use with Mozilla, but that is just one client. We have clients for almost anything you can think of - Java, Windows, X Window using GTK+, a JavaScript one for browsers, MacOS, Linux command line and more! Please realize that the Jabber client that will be working with Mozilla is just a tiny part of what the Jabber project is all about.

Thank you for your time, and I hope that you will look more indepth into Jabber before writing it off in a heartbeat.

If you'd like to ask some questions, feel free (as temas already posted) to pop into #jabber on the Open Projects IRC Network (try carter.openprojects.net).

Eliot Landrum
Leader of Jabber Documentation Team
eliot@landrum.NOSPAM.cx

Hey all you /. folks! :)

I am actively helping in the Jabber project, and I am sad to see so many hastily posted comments here on /.! To make some corrections to the posts that I've seen floating around, allow me to submit the following comments:

1) Jabber is not a rip-off of anything. Jabber is completely different than other IM systems. The first thing that sets it apart is that it is open source and GPLed. But what is more interesting than that is the fact that Jabber has the ability to speak to any type of communication protocol that ANYONE would care to develop a module for. The thing that makes this even cooler is that the modules just need to be installed on the Jabber servers. That way a Jabber client (like the one that is going to work WITH Mozilla) can instantly have access to other protocols as soon as the server has been updated - no updating of the clients is necessary.

2) I have to PARTIALLY agree with the posts about Mozilla getting bloated. But I say partially because I don't believe that most of the posters (especially the AC's) realize that what makes Mozilla bloated is the MODULES (not sure what the "official" term is for modules in Mozilla). The Mozilla Jabber client just works WITH Mozilla and may not necessarily be included in the binaries and so forth and I can't imagine it being required in source packages. DaKrushr already wrote a good post covering this.

3) Jabber has hardly anything to do with Mozilla. Yes, we will be developing a CLIENT to use with Mozilla, but that is just one client. We have clients for almost anything you can think of - Java, Windows, X Window using GTK+, a JavaScript one for browsers, MacOS, Linux command line and more! Please realize that the Jabber client that will be working with Mozilla is just a tiny part of what the Jabber project is all about.

Thank you for your time, and I hope that you will look more indepth into Jabber before writing it off in a heartbeat.

If you'd like to ask some questions, feel free (as temas already posted) to pop into #jabber on the Open Projects IRC Network (try carter.openprojects.net).

Eliot Landrum
Leader of Jabber Documentation Team
eliot@landrum.NOSPAM.cx

The specs I've seen for a few different IM's all seemed to be rather crappy and ill thought out. Does anyone know if any of the IM protocols or proposed protocols are actually flexible, secure, and peer-peer? IMO w/out those three simple things the protocol is doomed as time passes regardless of who has the most users now. IPX seems to have lost to TCP/IP even though it had the majority of the market up to a few years ago. Remember all the IPX enabled multiplayer games? I have not followed it closely but I liked the protocol being used by Jabber which is based on XML and seems to be fairly flexible. Flexibilty is the key in a protocol such as this I think, even if it is unsecure and client-server at conception if it is flexible enough it can easily adapt as time goes on w/out breaking backwards compatibility.

Also I love the idea of having multiple IM's work under one client. AOL, ICQ, Yahoo, MSN, whatever all workable as plugin's to the client program so I only have to know one interface and can communicate to everyone under a single user list. Third, I'd love to be able to store my contact list, history, etc on a server of my choice rather than having to ftp the whole thing from machine to machine every time I need it. Just please spare me the quota idea. This is one reason I continue using ICQ the most, because Yahoo and some others limit the number of people in your contact list. How stupid is that, I am not allowed to know so many people. Well excuuuuuse meee! Arghh but please don't crypt local db files either such as ICQ does, this is causing me huge problems because I need to merge several lists under the same UIN but from different computers into a single list and it is fairly impossible. It's the OS's job to keep unauth'd people from reading my files, if Windows doesn't let Windows users upgrade to Linux as I'll do as soon as I can merge and export my ICQ db's. :P

The specs I've seen for a few different IM's all seemed to be rather crappy and ill thought out. Does anyone know if any of the IM protocols or proposed protocols are actually flexible, secure, and peer-peer? IMO w/out those three simple things the protocol is doomed as time passes regardless of who has the most users now. IPX seems to have lost to TCP/IP even though it had the majority of the market up to a few years ago. Remember all the IPX enabled multiplayer games? I have not followed it closely but I liked the protocol being used by Jabber which is based on XML and seems to be fairly flexible. Flexibilty is the key in a protocol such as this I think, even if it is unsecure and client-server at conception if it is flexible enough it can easily adapt as time goes on w/out breaking backwards compatibility.

Also I love the idea of having multiple IM's work under one client. AOL, ICQ, Yahoo, MSN, whatever all workable as plugin's to the client program so I only have to know one interface and can communicate to everyone under a single user list. Third, I'd love to be able to store my contact list, history, etc on a server of my choice rather than having to ftp the whole thing from machine to machine every time I need it. Just please spare me the quota idea. This is one reason I continue using ICQ the most, because Yahoo and some others limit the number of people in your contact list. How stupid is that, I am not allowed to know so many people. Well excuuuuuse meee! Arghh but please don't crypt local db files either such as ICQ does, this is causing me huge problems because I need to merge several lists under the same UIN but from different computers into a single list and it is fairly impossible. It's the OS's job to keep unauth'd people from reading my files, if Windows doesn't let Windows users upgrade to Linux as I'll do as soon as I can merge and export my ICQ db's. :P

The Jabber project is exactly that. Check it out, there is some work to be done yet so jump in and help out if you're interested!

Check out Jabber, a clean architecture designed to do just that and
support simple/clean/fast clients, and has made significant progress already.

It's an open-source project so it could use any/all help and suggestions!

There is already an open-source effort to create a free instant messaging protocol: Jabber.

It's made a significant amount of progress and has a tremendous amount of support behind it, and works with AIM/ICQ/talk/IRC/etc transparently. Check it out and help get it done if you are interested :)