Slashdot Mirror

Jabber.org and Jabber.com (and any other parties would be most certainly welcome) are working together to establish a Jabber Foundation along the lines of the Apache and Gnome Foundations to assist in addressing many of the issues surrounding Jabber being raised here. We've just completed a survey to help us gather some suggestions for addressing these issues and have gotten some great results. One of the many initiatives we're undertaking, in addition to improved documentation, enhanced client development, and extended user involvement, is formal support for the ongoing IMPP work, in particular CPIM, SIP and BEEP. If you'd like more information, email me or info@jabber.org. Peace!

Jabber.org and Jabber.com (and any other parties would be most certainly welcome) are working together to establish a Jabber Foundation along the lines of the Apache and Gnome Foundations to assist in addressing many of the issues surrounding Jabber being raised here. We've just completed a survey to help us gather some suggestions for addressing these issues and have gotten some great results. One of the many initiatives we're undertaking, in addition to improved documentation, enhanced client development, and extended user involvement, is formal support for the ongoing IMPP work, in particular CPIM, SIP and BEEP. If you'd like more information, email me or info@jabber.org. Peace!

Jabber.org and Jabber.com (and any other parties would be most certainly welcome) are working together to establish a Jabber Foundation along the lines of the Apache and Gnome Foundations to assist in addressing many of the issues surrounding Jabber being raised here. We've just completed a survey to help us gather some suggestions for addressing these issues and have gotten some great results. One of the many initiatives we're undertaking, in addition to improved documentation, enhanced client development, and extended user involvement, is formal support for the ongoing IMPP work, in particular CPIM, SIP and BEEP. If you'd like more information, email me or info@jabber.org. Peace!

See http://www.jabber.com/news/release_102400.shtml for a press release from last fall disclosing the partnership between Jabber and VA Linux, Slashdot's corporate parent.

What is particularly annoying is that JabberIM is the client produced by Jabber.Com, the "commercial" side of the Jabber development team. If any client was going to work reliably, one would hope that would be the one.

What is particularly annoying is that JabberIM is the client produced by Jabber.Com, the "commercial" side of the Jabber development team. If any client was going to work reliably, one would hope that would be the one.

I think at this stage of the game, the mass appeal of new PCs are because of "OS-independent" applications, such as ... ICQ/AIM

Whose terms of service and client connection protocols rule out connection from Free clients to their servers. s/AIM/Jabber/g and you'll be fine.

As far as a plain old Jabber server goes, the jabber.com server is probably the most stable you'll find. However, if you're trying to talk to your AOL buddies, you'll have to wait another couple weeks: http://www.jabber.com/support/serverstatus.shtml

Start your own IM network, and make it "standards-compliant."

We already did. It's called Jabber.

I'll be too busy chatting with all of my AIM and ICQ buddies to care.

There are already Jabber-to-TOC and Jabber-to-ICQ gateways that let Jabber users chat with users on other servers, and they're getting ready to install MSN and Yahoo! gateways.

Maybe you should have a look at: Jabber.org and Jabber.com. There was also a nice feature on Jabber in August's (or was it September's?) issue of Linux Journal. Jabber has the potential to integrate all of the above and more.

And we already unify support for AIM and ICQ (and Yahoo!, and MSN, and IRC), with our server-based "transports." Your client speaks one protocol--the Jabber XML protocol--and the server handles the translation. This can make Jabber clients much smaller than so-called "universal" clients; we're working on Java applet clients that'll be small enough to download over dialup connections without great pain.

And Jabber can definitely be used for more than just instant messaging; we've been experimenting with a Jabber-controlled MP3 jukebox program recently. In conjunction with another Jabber-based "remote control," you can control the songs that are played on another computer across the room, or across the continent. You can even have two or more remotes controlling the same jukebox. All the specialized messages required for controlling the jukebox and getting its status are just XML extensions to standard Jabber messages. (It's just a little demo we whopped up, written in Perl; it's not too sophisticated, but it does act as a proof-of-principle.)

Check out Jabber.org, JabberCentral, and, of course, Jabber.com.

Eric
--

But Jabber can do more than just instant messaging. We're actually demoing a little application that consists of an MP3 jukebox program and a separate remote control program, both written in Perl and logging into a Jabber server as clients. The remotes send messages to the jukebox indicating which songs they want played, and the jukebox sends back, in its "presence" message, information about what song's currently playing. And all done via the standard Jabber protocol, extended in a standard fashion, because it's XML. (We wanted to do a Jabber-controlled robot, but we only had four days to rig up a demo :-). )

Check out Jabber.org, JabberCentral, and, of course, Jabber.com Inc.

Eric
--

I can't think why any decent minded person would support the use of a protocol which is used almost solely for illegal, and quite frankly disgusting, purposes.

IRC is an open protocol for distributed "real time" text conferencing and file sharing. This potent idea continually gets reinvented. AOL's Instant Messager and Jabber are the latest incarnations of real time conferencing.

As the original killer Internet application, email has florished as a means of conferencing and file sharing. It propagated to all platforms that supported TCP/IP networking. The problem with email is that it is asynchronous. By default, it provides no notice that a message has arrived at its destination, much less was seen by the intended recipient. IRC is a way to extend the conferencing capabilities of email. You know instantly whether your message was received. For small groups, this method works well.

If AOL's IM improves (for some values of "improves") on real time conferencing Napster, Gnutella and Freenet extend file sharing to be pervasive and searchable. And yes, unlicensed files are traded with wild abandon on those networks too. Hustler magazine is printed on paper, just like currence, the Bible and Neal Stephenson's Snow Crash. I wouldn't go back to using stone tables because the medium can be abused.

Of course, it is easy to pick on the senile old aunt of conferencing technologies. There is no doubt that script kiddies and p0rn abound in seedy, misspelled chat rooms. It is a shame to condemn this important technology simple because of the activities of a few reprobates. If one could judge the whole by its parts, we'd have been Usenet years ago.

You may not choose to use IRC because of the few bad apples, but you'd do well not to quickly condemn all IRCers. There is a lot useful information tucked away in those intangible rooms.

Cheers

...it seems that several folks have taken to using [AIM] as their primary form of interstate comunication between departments/facilities. This forced our upper management to look into creating our own "chat thingie" without the file transfer (this is buisness after all). AOL is a closed standard, preventing us from acomplishing that.

Have a look at Jabber.org for the project's home, JabberCentral for info on clients, and Jabber.com if your company needs custom client or server programming done, or commercial-grade support for your Jabber needs. (Disclaimer: The latter entity pays my salary...)

Eric
--

yes, it will.

this is from the feature list:

Easy setup and configuration for sending and receiving IM's to AIM and ICQ

Find or add Jabber, AIM* and ICQ* users to your friends list

www.jabber.com.
Nuff said.

Eric
--

You forgot Jabber the best one of all. Usable not only AIM but also ICQ, Yahoo, MSN, IRC and it's own jabber protocol. Also, I got this Slashdot article's headline from the RSS Transport. Definitly the jack of all trades in instant messenging. The server is completely GPL'd and clients are finished or in the works for all major OS'.

For more info:

www.jabber.org
www.jabber.com
www.jabbercentral.com

Jabber.org
Jabber.com
Jabber Central

Eric
--

Eric
--

i would suggest jabber instead of this aol or this icq crap. it's open, free (the protocol and most clients + the server), and everybody can set up his own server (like everybody can set up a mail server).
and... of course you can still contact icq or aol people through your favourite jabber server.
the urls:
http://www.jabber.org/ for the open source software.
and
http://www.jabber.com/ for a non-free windoze client (but the offer a stable server...)

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

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

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