Follow Slashdot stories on Twitter


Forgot your password?
The Internet

Jabber As The Coming IM Standard? 190

deran9ed writes: "Rocky Mountain News just posted an decent article regarding Jabber. "That makes Jabber the "best candidate for becoming the de facto standard" of the instant-messaging industry, Kobielus said, in much the same way Linux has been to the Unix operating system and Apache has been to Web servers." Article is written rather well for a change with comments on concerns of companies, and their employees use of other IM protocols (AIM, Yahoo), a brief history of Jabber, and its authors, etc. Read on" One thing's for sure -- AOL hasn't made any friends by periodically kicking off all non-official clients from AIM, and companies would like to know that won't happen to them with a custom client.
This discussion has been archived. No new comments can be posted.

Jabber As The Coming IM Standard?

Comments Filter:
  • by Anonymous Coward
    Can Jabber send and deliver encrypted IM's with PGP or a similar scheme? I would gladly pay for a PGP-enabled IM client, and I imagine Fortune 100 companies would too.

    (Yes, I just finished reading Cryptonomicon)

  • AOL was the first great internet startup: they went ipo even before it was fashionable, and unlike other ipos, theirs has returned a profit -- the sort of profit only kings dream of.

    They're successful. We should be happy for them. But instead, we're moaning about how we want a piece of the pie. Well it's their pie!

    I have seen the face of tyranny. Tyranny is when a man cannot sleep at night for fear that ruffians will set fire to his cottage and loot his stables. That's what's happening to AOL as we speak: freeloaders are claiming that they get to use AOL's servers for free just because they want to! Imagine the nerve!

    In Sicily, they call it a mafia. In Ireland, it's parliament. But in the United States of America, it's free software? Free software is supposed to be about giving away your property as you see fit, not stealing others' property on your own behalf.

    Jabber cannot be allowed to discredit free software. We must cut the cancer out at its roots, lest it poison the entire apple tree. If it's freedom that people want, then it's freedom they shall get in all its righteous fury.
    • Not freedom from want.
    • Not freedom from need.
    • but Freedom from the rule of the mob!

    Make no mistake about it: if this can happen to AOL, then it can happen to you. No one is safe in a world where the blackguards run free through the countryside raping and pillaging. Today it's Virginia. Tomorrow, it could be your backyard.

    Don't say I didn't warn you.
  • While this may only be minimally related to the what LL says, here's a "for what it's worth": Stairways Software (now Interarchy [], a putrid shadow of its former self) had a now-dead product called Combadge [] that used existing e-mail infrastructure as the basis for an instant messaging system. It was never hyped very well, was limited to the Mac and was written by Stairways's most incompetent programmer (Andrew Tomazos), but it did show potential.
  • Wrong. AOL turned on their checking for AOL clients and folks have updated the Jabber AIM transport to respond correctly to those checks
    (by allowing the user/implementer of the server to give the server access to a copy of the Windows executable). So it can still AIM, just not throught the gateway. Download the server, set your own server up. Then you can go through that to AIM.
  • by jeremie ( 257 ) on Monday April 16, 2001 @08:58PM (#286921) Homepage

    This story links to (which is fine) but if you're looking for the open source project you might want to hit []. The open source project is where it all started, and is just one of the many commercial efforts working to help jabber be a better tool for the business world and enterprises.

    We're still a young project and have many hurdles to leap yet, so if you bump into anything you'd like to see improved with jabber, it's open source and we welcome any/all assistance :)

  • RFC1459 [] specifies a cross platform instant messaging protocol. Included is the ability to send/receive files, create chat groups, and "instant message" another user directly. It's really cool. Maybe these newbies should try it sometime and quit reinventing the wheel. What's next on your drawing board? A platform independent way of sending text and graphics over a packet switched network where users click on "links" to go to other "pages"? ;-)
  • And this story is about Jabber. Your point? Jabber uses decentralized servers, and the DNS namespace for servers, simular to email..
  • *ROTFL*

    Have you ever actually read the RFC before? The IRC protocol is an old, outdated hack. At least the developer had the foresight to say it wasn't gonna scale:

    9.1 Scalability It is widely recognized that this protocol does not scale
    sufficiently well when used in a large arena. The main problem comes
    from the requirement that all servers know about all other servers
    and users and that information regarding them be updated as soon as
    it changes. It is also desirable to keep the number of servers low
    so that the path length between any two points is kept minimal and
    the spanning tree as strongly branched as possible.
  • As opposed to your email, where, if your server goes down.. Umm, And if their server is down.. Umm.. 8-P
  • Nope, not even close. IRC is a chat network. There is no such thing as presence notification, etc, which are pretty much required for instant messaging.
  • Well, there are a few requirements to being considered Instant Messaging. The first requirment is that of an entity. In order for an entity to communicate in realtime with another entity, they must exist, and be reserved and enforced by the protocol itself. None of the original IRC specifications came even close to this requirement. Not just authentication, but the ownership of an entity, to be reserved exclusivly for a given party, and enforced server network wide.

    Yes, I can give you that IRC is an example of an rudimentary IM system. There are many examples of IM systems. But it was not meant, nor was it designed, for IM. It was designed and continues to work as an open 'groupchat' implementation. It was build around a subscription model, in that users subscribe to a given 'channel'. While this gives the appearence of Instant Messaging, its more like 'Instant Chatroom'. Standard SMTP email systems could also serve as an IM system, simply by using SMTP email headers, and allow servers to translate headers to be used for presence.

    And yes, I do expect ICQ to be able to see AIM, which is specifically the way the Jabber network works. By use an open namespace, any given system can be segmented simply by a URL. This means that an entire closed namespace can be represented by one open namespace. Yes, you still need to have an account in that closed namespace, but that is a compromise due to the limitations of the external systems.

    And I'm not downplaying IRC at all. Jabber specifically includes a transport that gateways jabber users to IRC servers. This was one of the very first transports, and was the original groupchat interface used before the transports for groupchat had been written.

    IRC has its place. But its not for user notification and instant messaging.
  • Well semantically speaking... Linux isn't even strictly POSIX-compliant. It makes a good attempt, but it's not 100% and never been certified.

    Otherwise I agree that GNU/Linux is not UNIX.
  • In Gabber: Services -> New blank message... and give your own address as recipient. Works fine. I don't know how it works in other Jabber clients, but the point is, yes, you can IM yourself! =)

  • by Genom ( 3868 ) on Tuesday April 17, 2001 @08:41AM (#286930)

    Check out:

    • licq [] - a nice qt-based client
    • gnomeicu [] - a nice GNOME client

    There are others, but these are the 2 best I've found. I seem to prefer licq, but that's a personal preference. YMMV.

  • It's been almost a decade since the last holdouts (Prodigy, MSN, AOL, etc... remember when they weren't just expensive ISPs?) figured out that making email for the entire world dependent on a single server farm might be a bad idea... or at least, at the time I'd assumed that they had figured it out. Now I realize that they were forced to accept internet email standards because no single one of them controlled a majority of the market, and each of them dreams of catching the next big technology and entrapping it on their own LAN. My email address is; why should my instant messaging address be in a flat namespace (AIM, pre-internet AOL email), or god forbid even a flat numerical namespace (ICQ, pre-internet compuserve email)!?

    Does managing a technical company kill your long term memory?
  • And you still feel like encryption is worth something? I thought the book did a fine job of pointing out the futility of using crypto.

    ** Martin
  • In practice UDP is not actually extremely scalable unless you implement your own congestion control.
  • by zin ( 7049 )
    I don't know if this has been mentioned yet, but I have a clue as to why AOL doesn't allow other clients.

    First. The network that RUNS AIM is actually pretty complex. You can't count on other clients from maybe making mistakes in messaging formats that might really mess up something or perhaps writing a client that could actually do some harm. The best that AOL can do is to keep these possible threats of their network is to keep them from connecting.

    ADS. Aol puts em in their AIM client. Now if you don't have to use their client to IM then you don't have to look at their ads. I have no problem with looks at the ads it's just I don't like having to look at the ads of 3-4 IM's clients at once.

    Just my humble opinion....
  • Usenet and email are decentralized and asynchronous. When you're sending email or posting to Usenet, nothing is checking to see if the recipients are logged in.

    With instant messaging, you can't get around the thing that distinguishes real-time chat from email: the real-time status monitoring. When you log in to a real-time chat system, you need to announce your presence to a central hub that reports your status to the other users who need to see your status. You can't do that with a decentralized system, at least not one with more than a couple thousand concurrent users. Multi-hop referrals or separate regional or ISP hubs each with their own members' login status are far too slow and bandwidth-intensive to work on a large scale.

    A useful public instant-messaging system covering countries with tens of millions of people and thus hundreds of thousands to millions of concurrent users needs that central hub; otherwise your client is spending all of its time querying and processing data from any number of far-flung regional hubs.
  • You have, say, 35 people in your buddy list, scattered across 20 servers. This isn't unrealistic given that on Linux, a Jabber server can only handle 1024 simultaneous users, at least according to's own FAQ. So now, for the duration of your session, your client is communicating every few seconds with each of 20 servers to check your friends' online status. With a protocol that's robust, but not lean.

    Your client communicates with the central JUD server every time you want to look someone new up. Without the central JUD server, the whole thing balkanizes into separate small, free-floating islands and there's no ability to add or contact people not on your home server to your list until it comes back, though you can keep talking to the people already on your list.

    Your topology calls for many small, independently-run servers, which is going to be slow and unreliable; on any given day, any one server can shut down, die or disappear and its user base will be orphaned since there's no replication and failover of login services going on. Some are on mom-and-pop ISPs or run by nonprofits on a virtual server, some are big, fast systems. Some are in North America, others in the EU, and others in Egypt or Thailand. A server in Egypt will provide fast, reliable services to users in Egypt, but if they're on an American's buddy list, the Egyptian users' entries will drop in and out of the "logged in" status category as packets get lost in transit or connections sporadically time out, and vice versa.

    Jabber has a design that can scale, yes. But I maintain that it cannot scale to AIM/ICQ/MSN/Yahoo size, and that's what a public IM system needs in order to be useful.

    A more reliable topology might involve fewer, larger Jabber servers, each with a substantial portion of the user base--which gets right back to the question of how large servers get paid for.
  • by hatless ( 8275 ) on Tuesday April 17, 2001 @05:36AM (#286937)
    Fine, Jabber has a faint outside chance of becoming a standard protocol for private instant-messaging systems, and might eventually compete well with things like Lotus Sametime and Microsoft's conferencing server.

    Granted, this isn't all that likely since both Microsoft and Lotus can already integrate their instant messaging well with H.323 videoconferencing and with T.120 application-sharing and whiteboarding tools, and seamlessly tie in to directory services (not just for authentication) in ways that also make it fairly simple to link companies' and organizations' realtime messaging/collaboration together without relaying each other's messages. Fact is, Jabber is a good 2 or 3 years behind its competitors in the intranet space in terms of features. They're even miles behind the ICQ Groupware server.

    As far as public instant-messaging goes, it wouldn't be fair to say Jabber has no chance of catching on. But those chances are slim. Let's say that for some reason it does. Who is going to run and pay for the giant Jabber servers sitting in the middle of everything? An instant messaging system that can support millions of concurrent users will not run on a single donated 4-processor box running Postgres or MySQL. It won't run on two. It's going to take a server farm or two with millions of dollars in hardware, millions of dollars in commercial database licenses, and millions of dollars in engineers' salaries to tend to it. Please remember that while the messaging itself is peer to peer, the login and buddy-status monitoring services are not.

    How, exactly, is this going to be paid for if the clients are open-sourced, access to the servers is unrestricted, and advertising can be blocked? A tip jar?
  • Ive been digging around a bit, looking for an ICQ clone for Linux, and the ones Ive found so far are mostly crap Java applets/applications. Is there a fairly stable, decent quality ICQ clone for Linux?
  • Sure, you're a *NIX whiz, but have you ever hacked a pen?

    In 1st grade.

  • yes, in fact, several clients support GnuPG encryption. WinJab [] for Windows and Gabber [] for GNOME are two excellent free software options.
  • by [-ET-] ( 9993 ) on Monday April 16, 2001 @08:48PM (#286941) Homepage
    (For those confused, JabberIM is the Jabber client available from It is one of many Jabber clients available.)

    Most of your complaints can be fixed in the Preferences dialog. :) Check this out:

    >* Concurrent connection: If I open two JabberIM
    >on different machines, they will battle for the
    >control of the connection!

    To differentiate between connections, the clients need to have different "resources." You probably didn't set one of your instances to have a different resource, so they are trying to fight over the same resource ("JabberIM" by default). Jabber will happily let you use as many connections as you want at once.. as long as each client has unique resources.

    >* Or the messages pop and hide my work, or I
    >never see them... I can't wait a few seconds
    >before reading the mail like I was used to on ICQ
    >and MSN.
    >* If a new user send me a message while I write
    >to the other, the new window will capture my
    >keystroke. Very annoying when you say : "I love

    Both of these can be fixed with a quick trip to your Preferences. Simply tell it to not gain focus for new messages.
  • GNU/Linux isn't UNIX and doesn't claim to be UNIX

    GNU's NOT UNIX was intended to be a joke. GNU only claims to not be "UNIX(tm)" to the extent that claiming to be Unix would get them sued. Looks like a DUCK(tm), walks like a DUCK(tm), quacks like a DUCK(tm) - it's a Duck.

    The word "Unix" has been virtually completely disassociated with the tradename "UNIX" in the vernacular. That's why OpenVMS is UNIX, and FreeBSD is "real Unix", and Linux is a "Unix-like system", and UNIX System V Release 4 is "SCO UNIXWare", and I can make xeroxes from a Canon copier, and there's no congantive dissonance involved.
  • by elmegil ( 12001 )
    If Jabber actually had a client that was easy to install and use, this would be good news. But every time myself or my wife have tried to get a Jabber client of any stripe to work (keep in mind, I've had about 14 years of Unix experience, and also done home Windows maintenance for most of that time) IT HAS FAILED UTTERLY. I'm sticking with ICQ until Jabber folks can actually produce useable software.
  • 1) Make jabber not suck.
    2) Make jabber clients not suck.

    I mean, look at the options. Gabber, which is horribly unstable and has awful trouble building on non-linux systems, Jarl, which is good but not too current, WinJab, which is way ugly but featureful, and JabberIM, which is simple but lacks functionality. It's very hard for programmers to take full advantage of jabber, since the full protocol is horribly documented, and the server itself is in pretty poor shape as far as transports are concerned.

    I hear a lot of talk about jabber, but I see very little to back it up. I've used it periodically, even to the exclusion of better free clients (gaim, supports all the protocols jabber does but actually works), but the quality of the transports and the complete lack of portability of the transports and server are very frustrating. I even tried to write my own client, but ran into the documentation roadblock myself, and confirmed the problem with authors of other jabber clients.

    Jabber has great potential, but it needs a LOT of work to realize it, and I think the articles in OSS rags touting it as some kind of IM panacea do more harm than good.

  • no, *they* forgot about it. I live here, I know what bloody time it is...
  • But, calling it an industry standard is probably taking that a bit too far.

    Says who? Linux is shipping on more servers than any other UNIX variant. More software is being developed on Linux than on any other UNIX variant.

    No, it's not the standard PC platform, but the previous comment doesn't indicate that it was... He just said that Linux is the industry standard UNIX. It may not be the most powerful or mature, but from a lot of people's point of view, it's the standard.
  • I'm not sure exactly what you are saying, but Jabber is most certainly *not* dependent on one server. It is designed to be installed in the same way as e-mail servers, so ISPs should install Jabber themselves. That's one of the main reasons why a JID (Jabber ID) is in the form of an e-mail address. Jabber is a distributed system and very similar to P2P (only the client connects to a server that takes care of talking to other servers for you, so it's one step removed from "pure" P2P).
  • There can be a lag sometimes. The servers do not keep an open connection with each other at all times, so there is some connection overhead if you are the first to do a connection between the two (or the connection dropped and had to be remade). There does seem to be slightly more lag when talking through another server, though, but I've not noticed it as long as 20 seconds. Usually only 1 or 2 in my experience. Perhaps it was a fluke. :-)
  • See my earlier post in this thread.

    The effort fragmented, and the working group rewrote its charter to limit its purpose to defining requirements. Their RFC's about the Common Profile for Instant Messaging (CPIM) have been published, and they should be closing down soon. The IETF instant messaging effort is now mainly split into two camps with subtly different aims.

    The SIMPLE [] working group is adapting the Session Initiation Protocol (SIP) to serve the traditional purpose of instant messaging.

    The APEX [] working group is developing a BEEP profile to serve as a general-purpose, low-latency, Internet-scale application messaging and presence protocol.

    Both are good ideas, and neither one is enough by itself. The SIMPLE group is likely to get something up and workable quickly, but it won't be all things to all people. The APEX group, on the other hand, may take longer, but it is doing some remarkably good work and there is already a fair amount of BEEP implementation code published under a BSD license at sourceforge. See the new BEEP Home Page [] for the juiciest news.

  • The IETF is in the process of proposing not one but two standard protocols for "instant messaging" applications. (Why two? It's a long story, and it isn't over.) I recommend reviewing the charters of the APEX [] and SIMPLE [] working groups, as well as the appropriate drafts.

    RFC 2778 and RFC 2779 are good background information too.

    It seems to me that the direction the Jabber project should take is to consider both of these protocols to be "transports" and, er-- assimilate them. Yeah... that's the ticket.

  • You might want to check out gale []. While it does not use PGP, it does support strong encryption of messages sent using it.
  • The Jabber protocol is cool not because of interoperability but because they've whipped out a pretty fast XML router. Jabber is as complex (actually less so) then Gnutella and look at how popular Gnutella is getting with the mom and pop crowd. The protocol is fairly basic and easy to work with and allows you to add features onto it later. Jabber is a good framework to build on rather than a release product like AIM. Jabber will make a big splash as soon as someone puts all the good ideas into one easy to use package.
  • What in the holiest of holy fucks are you talking about? Did I not say Jabber is an XMl router? There are plenty of limits with what you can do with it, the fact that it's XML makes little difference. I could do everything Jabber does with a simple IRC server. Like I fucking said, Jabber is a framework someone can easily put to their own use, the key to its success will be someone putting it to a very popular and profitable use. All you've done is name a few of the things you can do with an XML router. Congratulations jackass.
  • I hate to be nit picky like this, but shouldn't that be third millenium? 1-1000= 1st, 1001-2000= 2nd, 2001-3000= 3rd
  • More likely Jabber will go the way of QDOS and PowerPoint.. it will be *ahem* acquired and merged into MSnN by Redmond..
  • And I quote..."Think about it," Durand said. "This is like the opportunity to commercialize e-mail, but bigger." I can see it now, pop-up ads from your instant messaging client! How sweet is that? I worked for the parent company two years ago and everything they touch turns to shit. Jeremie Miller should never have gotten into bed with these bozos. I hope the opensource project can make it though.
  • Jabber also runs on Solaris 2.7 and 8 and FreeBSD.
  • I've just tried this with GtkYahoo and weirdly enough it works!

    And you can make yourself a friend so that you'll always know when you're online!

    Messages sent to you just come right back. No chit chat though! <sigh>


  • Okay, fair enough. But in the real world, interoperability will be king.

    Jabber will only thrive by letting people chat with their friends whatever other client they use.

    But there are thousands of people using Jabber every day to chat....

    It's good that Jabber can exist on it's own without the gateways, but AOL has (around) 30 million members; that a lot of friends to force to change over from AIM to Jabber.

    Not only do I think that the gateways is what will make Jabber king but that they will be strictly necessary for Jabber to be king. I hope it works out that way too.


  • I guess that SSL is useful for loging on but of course it not end-to-end

    The Jabber servers manage connections to the real servers (like Yahoo! []'s or whomever) and I don't think any of them support SSL (I only really know about Yahoo! as I work on GtkYahoo []) and it (the Yahoo! server) definitely doesn't.

    Still it's better than nothing.

    Of course this is a handy point to note. Jabber is not an IM service in it's own right. It's a conduit for other IM client / server models so it cannot replace them can it?

    No matter how much you want to replace the AIM servers you can't if you want to continue chatting with other AIM users (who aren't using Jabber, I guess).

    Also things may have changed but the last time I looked Jabber couln't handle HTTP tunneling. Both Yahoo!'s own client (and there are Linux and FreeBSD [] versions) and the CVS copy [] of GtkYahoo can. Can other IM clients do this?

    I would say that the guys at Jabber seem serious about helping the Open Source projects they interface with. Libyahoo [] (the protocol library that GtkYahoo relies on) was recently dual licensed as GPL/JOSL so that they could continue using and upgrade the libyahoo code they were using in their servers and keep it in line with their development and licensing needs.

    If you're serious about helping Jabber, help out with the protocol libraries like ours or libicq [] etc. The more protocols that Jabber can transparently conduit for clients the better. Heterogeneity (sp?) is the key.


  • Now, I'm a full convert on the usefulness of Linux. I've got it running on two different platforms in my house right now. But, calling it an industry standard is probably taking that a bit too far.

    Huh? Besides Linux being the most widely used Unix, it has the most market share of an Unix. Plus, all the commercial Unix vendors are adopting technology from the Linux community. Solaris, for instance, can run Linux binaries. HP, Sun, IBM, and other commercial Unix vendors have created the GNOME foundation and are adopting GNOME as their standard desktops.

    Linux is NOT the standard desktop operating system, but it is THE standard Unix variant. And it is now #2 in server sales, next only to Windows NT/2000. Linux server sales, in fact, have eaten into Microsoft's server OS sales, making it a real challenger to Microsoft on the server platform. Get with it ... Linux is becoming a powerhouse on the server!!

  • by MidKnight ( 19766 ) on Monday April 16, 2001 @09:15PM (#286962)
    .... That makes Jabber the "best candidate for becoming the de facto standard" of the instant-messaging industry, Kobielus said, in much the same way Linux has been to the Unix operating system...."

    Now, I'm a full convert on the usefulness of Linux. I've got it running on two different platforms in my house right now. But, calling it an industry standard is probably taking that a bit too far.

    It may become a defacto standard one day, but in my opinion we're still quite a way off (and Linux has a lot of growing up to do) before we reach that point.

    {{donning fire-retardant clothing}}

  • by LL ( 20038 ) on Monday April 16, 2001 @08:48PM (#286963)
    Simplicity (TM) and interoperability are good but is that sufficient to convince the average person to substitute to change their ICQ/AIM/whather just for a slightly better interface? The mail system which is *THE* killer-app of the internet relied on divying up the system into 3 components
    • - mail transfer agent (MTA);
    • - mail delivery agent (MDA); and
    • - mail user agent (MUA).
    Because the three components are somehwat independent and substitutable (e.g. sendmail/qmail, pine/elm/eudora) different palyers can upgrade without breaking some critical day-to-day use. Looking at the Jabber, it tries to be the polygot of IMs which while laudable, does make it a little unwieldly to offer alternatives and competition in the form of low barriers to entry tis'good (TM). For example, stuff like Elvin [] which is content-based messaging looks intriguing.

    Perhaps some thought should be given to aligning the components in an analogous fashion. Has someone looked into comparison of the key attributes of the different IM system to see whether a similar structure could be nominated? For example, I would hazard

    • - message session agent - handshaking/setup
    • - message resolution agent - figuring out namespace conflicts
    • - message distribution agent - multicast/AIM/etc
    • - message client agent - the GUI thingy-a-bob

    In fact spliting channels into a separate session control and others is what is suggested by BXXP [] framework.


  • by ywwg ( 20925 ) on Monday April 16, 2001 @08:38PM (#286964) Homepage
    man, do they have templates for trolls these days?
  • Having buddies on 20 different servers does not mean that you have to "poll" all those servers to receive presence. You are notified when their presence changes by the person's server.

    There are efforts underway already that remove the 1024 connection barrior on linux.. and using these methods, it's possible to scale a LOT more users. But like the other poster said, Jabber is about "everyone" running an ISP, so we don't need one single "farm".

    I don't see how this topology differs at all from the email topology?? Please elaborate.
  • It would be nice to hear your definition of Instant Messaging, otherwise any discussion on whether IRC fullfills it or not is jsut empty lip-slapping.

    However, I feel I have to remark that a primitive presence-protocol was defined in the RFC 1459, May 1993, "The ISON command was implemented to provide a quick and efficient means to get a response about whether a given nickname was currently on IRC." This is a polling presence-mechanism, and was extended in 1995 to allow more fine-grianed identification. On October 1997, the increase in user-counts and decrease in memory-prices led to the official roll-out of the WATCH system, which implements passive presence notification, on DALnet IRC network. This extension has since then been adopted by most major IRC networks and clients.

    I personally consider IM just a subset of chat/IRC. Now I'm fully aware IRC protocol has significant problems with authenticiation (To some degree solved by development and integration of Services around 1997), segmentation of the IRC community (But you don't expect ICQ presence to work on AIM etc. do you?) and scaling. However, it yet remains to be seen what a major company running a centralized server-farm for IRC could've accomplished; most of IRC's scaling-problems are due to decentralization using 1980's architecture and assumptions.

    However, I think the kind of single-eyed software-patriotism as this thread suggests is only harmful to the open-source movement as a whole. It wasn't even automatically clear that IRC was under an open-source license, and there was a strong movement to hold it under a properitary license. Luckily, perhaps, open-source won then - but had they known many in the open-source movement would later disown and ignore this important pioneer, I think they'd thought twice about it.

  • Well, it's getting a bit off-topic from the original discussion...

    But still I can't help but remark that messaging between "entities", that is nicks and nick-lists was the initial application of IRC (Which was built as a more convenient replacement of talk). The subscription channels, first as numbers and then as the present named channels, appeared only much later. There are still many people who never join channels, just wait for people on their notify-lists to pop up or the other way around.

    I'm not sure what you mean by "reserved and enforced by the protocol itself". IRC protocol is pretty militant about that, and has had support for password-protected logins back from day one as it were. Persistence of entities is a problem that was solved by the different services-systems half a decade ago.

    I'm not saying IRC is the best protocol out there and a model for the future of Instant Messaging, but it is very hard to find examples of anything that all present Instant Messagign systems do that IRC didn't do already five years back - including crashing, ofcourse ;)

    And yes, SMTP could've served as IM as well, had somebody written up an aplication to broker out presence requests and notifications and guaranteed real-time delivery, but nobody did.

    -Donwulff (And let's not even talk about, er, talk...)
  • /* Re:AOL is a success story for the ages (Score:1)
    by tpv (tpv@users_sourceforge_net) on 04:27 AM April 17th, 2001 EST (#127)
    (User #155309 Info)
    Sharing is about a mutual agreement for the benefit of all.
    This is much closer to free-loading. */

    Says *who*?

    I have an AOL account and have had one for 5 years now. Sure, I only use it sparingly, but surprisingly enough, I *have* found uses for AOL's services that I like and don't mind paying for the account. However, I also use BeOS and Linux quite often and it's quite inconvenient to lose "AIM" functionality when using my "alternative" OS's, so I use BeAIM, GAIM, whatever. (I must admit, though, that all of the replacement "AIM" clients on alt os's are not as robust and fully functional (I really dig the "seamless" file transfers, although they could be implemented better...), but hey, for basic chat, it's cool. I've heard there's an "official" release for Linux, I'll be sure to download that one day and give it a whirl. Too bad no BeOS port..

    Now, where does this lead to? I also agree with the original poster: It's AOL's servers, it's AOL's bandwidth, it's AOL's services, therefore, if AOL wants to limit access to their stuff to ensure quality service for their PAYING customers (or just because their Assholes), then so be it. I've got IRC and I've got ICQ, and goddammit, if worse comes to worse, I've got email and a fucking telephone.

    Personally, I don't see why someone hasn't produced an alternative system that's not reliant upon AOL, ICQ, YAHOO, MSN, etc. I know P2P has scalability problems, but how hard would it be to implement a P2P chat network? What issues would be involved? As Neal Stephenson once said, if you don't like the choices presented, get off your ass and makng your own! (well, loose paraphrase).

    Take it light and enjoy.

  • We currently strongly encourage the use of PGP/GPG and it is implemented in WinJab, Jarl, and Gabber clients. The protocol has support for it, and is being widened soon to encompass more public key methods. The server also supports SSL connections, this is supported by many clients as well.
  • Which attack and anger are you talking about? One of the main reasons I've seen people deploy Jabber and throw spite towards AIM is security. The companies need to be able to control their users actions to some extent and having the messages float around on some other network doesn't help that very much. A Jabber server can be configured to only allow internal usage, and then possibly proxy traffic to the outside world in a concentrated and controlled manner. Even more so components could be built to log all traffic and store it in a safe and encrypted manner. This would be quite a chore of packet sniffing a network and reconstructing to do this if you let your users have access to the AIM network. Even more so if you then let users have access to any network they want.
  • is not advanced by clients like Jabber. Much the opposite, actually. They have a ways to go yet.

    IBM uses Lotus Sametime internally, and you can bet it's encrypted. But it's easy to use daily.

    Other IBM/Lotus customers also can use Sametime securely, within their business. But it doesn't do AIM, Jabber, etc., at least not yet...

    What's not implemented yet is a universal chat facility that discriminates between internal versus external conversations, I so openly admit.
  • Coincidentally, a piece I wrote for Newsforge about this very topic just went live in time for this story: 931237 []
  • We (a few Jabber developers interested in security) are working on using the W3C proposal for encrypted XML and content to allow for the end to end encryption of messages (of any type) between users. This support should allow for easy encrpytion of any future additions to the protocol, as well as what's already there.

    A very rough draft of the proposal can be found at t

    Please remember it's very rough, and a little out of date - it will be updated within a week or so.
  • Too bad no one's heard of it.

    My ICQ# is in the 200,000's.

    When I started using ICQ, nobody else had heard of it either.

    Amazing what's happened the past few years, eh?

    "Everything you know is wrong. (And stupid.)"
  • what makes Jabber the not-so-best candidate is lack of users. Users are what make something the facto standard, and even though Jabber may not be proprietary like the others, unless they figure out a way to increase their user base (preferably at the expense of the others'), they will not become the de facto standard.

    Whether they become an official standard is a different issue -- maybe that's what they meant. Whether that will help them is another issue still.

  • How does it work with Usenet, with Email?

    Generally, ISPs will run their own local server with logins for their own customers as a value-added service, and allow anybody remote to message them.

  • As mentioned before, the server (jabberd) builds and runs cleanly on FreeBSD and Solaris, and actually scales much better on either of those than Linux.

    This isn't "fringe" this is a platform-agnostic open source project that will compile and run on any supported platform with little or no effort.

    The only thing 'linux-centric' about jabberd is the insistence on using gmake. (The 'gabber' client is a whole other story, I've never gotten recent versions to run anywhere.)

  • Unfortunately, the applet code is stagnant, and does not support the 'new' group chat protocol or many other useful features of jabber.

    However, the new "web client services []" shows some promise.

  • by Nonesuch ( 90847 ) on Monday April 16, 2001 @08:52PM (#287002) Homepage Journal
    Jabber has come a long way in the last six months, but it's downfall is likely to be the scarcity of legible documentation. What little there is can be found on []

    It's a real struggle getting a server compiled and running with even the most basic of functionality, and many of the most interesting value-added features have little or no documentation.

    There is an active development community on the JDEV mailing list [] and ' []' channel, but like so many other open source projects out there, 90% of the developers are busy writing cool features, with really only Peter Saint-Andre (aka 'stpeter') putting any real effort into documentation.

    A lesser problem is what some call 'fascination with the technology', and is a cause of the lack of users- most Jabber users are developers and admins who are more interested in playing with the new technology for it's own sake than as a way to communicate. Basically, 180 degrees from the motivation of the average AIM user.

  • While 'Instant Messaging and Presence' is the first application of Jabber, they have a much more ambitious goal- at it's core Jabber is a threaded XML router that just happens to work really well as a chat server.

    There are already several Jabber-related projects only tangentially related to instant messaging, and there are many other interesting applications for XML routing on the horizon.

  • by jeffsenter ( 95083 ) on Monday April 16, 2001 @09:10PM (#287005) Homepage
    I don't understand why Microsoft doesn't just build an Instant Messanger into their OS's like they did with IE and make that the standard by brute force. Conceivably Microsoft could agree to an IM truce with AOL and have their Windows/MSN IM work with AOL and ICQ. Then that would be the standard. The Bush administration wouldn't go after such an action on anti-trust grounds and that is the only possible deterant I can come up with. Dominance of IM also further isolates non-Microsoft OS's.
  • I tried Exchange 5.5 Chat Server, it blew hard core.

    I tried Win2K Server, it blew hard core, I rolled back to NT4.

    Thanks for the tip, but I haven't been impressed with the Exchange Group's Mac support, and I'm sure that their Linux and MacOS X support is non-existant. I do actually have a heterogenous environment, so I don't know if it works as well.

  • Yeah, groupware is hidden and hasn't been updated since 1998, the last time a new "beta" game out. It doesn't do what it should. It has a special groupware client that is a stripped down version of their client from '98, and it isn't clear if you can run the real client and connect to it.

    It seems kind of awkward in it's handling of things. We were playing with it for corporate use, mostly so people could swap messages/URLs and startup Netmeeting conversations.

    Unfortunately, the system was never polished. I couldn't figure out a way to strip down the listed helper apps for installation, and doing that at each desk would suck. It became a backburner project before I could do anything useful with it.

    ICQ had plans to be a business. AOL gobbled them up, and AOL has never had much interest in moving out of the consumer space.
  • by alexhmit01 ( 104757 ) on Monday April 16, 2001 @09:29PM (#287009)
    IM compatibility is nice, and necessary, but isn't the secret to Jabber.

    Jabber needs real clients (i.e. Win32 and Mac) that don't suck, and people are comfortable with. It needs the power of ICQ with the simplicity of AIM. It also needs moron proof servers.

    This is the key point. The majority of computers are still in the corporate sector. We all use ICQ and AIM for communication, and nobody is happy about it. Some companies have tried to block AIM as a security risk (you can send corporate information out without any log of it), but found that it became key to the company's communication.

    A real system where I could communicate externally but have a special internal system would be helpful.

    Now, the real solution, IMO, is a Open Source/Corporate combo. In that scenario, there is a freely available public product that is really good. However, there should be a commercial (but inexpensive, IT budgets have gotten tighter) product that works with an internal server that is easy to install. Additionally, include an Admin kit so companies can configure what is allowed.

    For example, if I could only allow people to send URLs and text externally, but files internally, that would be a useful collaborative tool. That let's them communicate/goof off/whatever, while not exposing my company except internally. This would also take the load off my e-mail servers.

    Additionally, the corporate version should allow the corporate server to communicate on behalf of the clients. That way, I can block ICQ/AIM at my firewall, but allow the corporately supported client through.

    Do that, and Jabber takes a REAL foothold. Make the corporate version license access to AIM/ICQ servers (cobranded perhaps) so there isn't a risk of it breaking.

    Corporate America is NOT happy with AIM/ICQ. ICQ Groupware dying was a shame. There needs to be a real solution, and there is money to be made in this space. AOL with it's FCC agreement would likely jump at this, they could get revenue to cover costs. The Open Source community gets Jabber to NOT be harassed, and corporate America gets a real communicative tool.

  • I can't understand why everyone is always mad about AOL for what they're doing with AIM. It sucks, yeah, because I would like to use whatever client I want. But, guess what, it's their network. The advertisements are part of AOL's plan for making money off of having an instant messaging system that is accessable to even those not signed up with AOL, the ISP/BBS. AOL knows a few things: (i) It's their network; (ii) they want to support their network in some way that allows them to keep it cost-free and fully operational; (iii) they benefit from having instant messaging work with a broader audience than just AOL users. Reason (iii) is why they want it cost-free: they get to give broader connectivity to their users. That's the sole reason for AIM's existence. And it's a damn good reason. The side-effect, of course, is what we're mainly concerned with: we get AIM. Seems like a pretty good upshot for both parties. AOL, however, realizes that the operation of the AIM network has its own costs and that because AIM is now out there for everyone, it's not attracting users to AOL. Their (be it half-baked, stupid, or ill-conceived) idea for how to support the network without costing them profits elsewhere is to run advertisements on the thing.

    As a user, that seems like a small price to pay for something that benefits the Internet as a whole. The attacks on AOL and the concerted effort to subvert their attempts to make the AIM network self-supporting are mean-spirited and misdirected. This is a good, free service. It's a damn shame that people are preventing AOL from making the network self-supporting.

    Now, admittedly, AOL is no angel. And I don't like their tactics or choices any more than the next guy. But it is their network and they not only have every right to do what they've been doing, but they are right to be doing it. If the open source community doesn't like how AOL is running things, the alternative is not to use their network without their permission and against their wishes. The alternative is to create our own.

  • The difference, of course, is that AOL lets you do one, but not the other. And it's their servers, so they have every right to make those restrictions. If you think being on the Internet means that anyone, be they AOL, Slashdot, Microsoft, a university, you, or me, has to let others use their servers, you've got a seriously warped view of things.
  • I'd be more inclined to tinker with Jabber if the server weren't tied to Linux. Sure, there are some fringe projects trying to run the server on other platforms (most interestingly, Java). But what is really needed are some other stable platforms for Jabber servers.
  • I've tried confincing some people at my office to open the firewall for Jabber. I figure, rather than specific holes for each of AIM, ICQ, etc., why notopen one whole for Jabber instead of one for each IM platform? Alas they refused. The next alternative for me would be some sort of HTTP tunneling to get through the corporate firewall. Alas, I have found no support for this, although I've seen tidbits that some people are investigating it.
  • As others have stated here, to be a defacto standard, you need a majority of users -- or at least, the largest piece of the pie. Jabber doesn't presently have that.

    In fact, the driving forces of Jabber seem to be in conflict with this. The OpenSource guys seem bent on adding amazingly cool features and pushing that Jabber is more than IM. The commcercial arm seems relatively silent but appears to be amed only at corporations.

    To become a defacto standard, they need users. To get users, they need to focus on Jabber proliferation -- both client and server. Add features the common IM man wants, make it more usable than the native IM clients and servers, etc.

    First, attract users to gain visibility. Then add features to show what else you can do.

  • by burris ( 122191 ) on Tuesday April 17, 2001 @01:04AM (#287027), the open-source project, was founded in 1998 by Iowa software developer Jeremie Miller as the first open-source platform for instant messaging.
    Apparently IRC doesn't count since it is a chat system.


  • For example, if I could only allow people to send URLs and text externally, but files internally,

    ...there would be no difference. Nothing prevents you from HTTP POST uploading a zipfile to your Geocities account (a firewall prohibiting HTTP POST would be a royal pain in the) and giving somebody the link.

  • dumbass. get squid, and block direct access to port 80 at the firewall.

    This would disallow all access to the World Wide Web. "So use a proxy." Users would just POST their files to Geocities through the local web proxy. "So disable POST on the proxy." And disable the dynamic Web entirely. Bad idea.

  • by yerricde ( 125198 ) on Tuesday April 17, 2001 @10:16AM (#287030) Homepage Journal

    For me the real killer is not having a client that will tunnel through the strict http firewall

    You may want to try this Jabber applet for the Java platform [] unless your strict http firewall actually parses the incoming data and does not allow binary Java applets to cross the wire.

  • One IM is much like another, but there's one thing about Jabber which is extremely annoying. You can't IM yourself!

    This is silly since its the first thing that everyone tries to do after installing IM software.

  • Yes they do. It's a useful diagnostic tool to make sure things are working correctly without annoying the hell out of other users.

    Thanks for the tip about Jabberbot though. Perhaps you should make this feature more prominent since it sounds quite neat. Perhaps you could even use it or something like it for games, stock quotes, flight info etc.?

  • Disclaimer: I worked for a company that competed with AOL in the instant messaging arena, so do keep that in mind when reading my comments.


    Personally, I like to think it was McAfee Associates that was the first great Internet startup--they utilized the Internet (and before that, a BBS) for product delivery and customer service before many other companies did. Or, for that matter, maybe Netscape was the first great Internet IPO, but I digress from what I wanted to discuss here...

    Do you own a telephone? Do you have an email acount?

    Can you only use your telephone to call people who have the same carrier as yourself? What about your email account? Can you only send messages to people in the same domain as yourself?

    I would suspect that the answer to both questions, for you and for the majority of people reading this, is a resounding "no."

    The reason that you can use your telephone to interact with other customer's carriers, and send messages to people at different domains, is because there are common "open" standards that allow different phone systems and email systems to interconnect. Now, the telephone system was started over a century ago, so from a temporal view it is difficult to have a first-hand understanding of how it evolved, and email was started as an academic, open service, so it is a little different, but the principles involved are the same.

    What you may not understand is that the nascent instant messaging industry is in the same position. before we go any further, let me clearly state that, first off, there is a business here. Although instant messaging has nowhere near the same number of users as telephone or email systems, and a large number of people use instant messaging purely for entertainment, there is a business there. Departments and divisions within companies use instant messaging to share information, because it is quicker and easier than calling someone or sending them an email. And IBM/Lotus includes an instant messaging application in their Notes messaging suite (based on AOL's product, actually). And more and more people use instant messaging programs for business every day. So, let's just say that there is a growing business use for instant messaging.

    Now, with instant messaging, there is a similar growth arising as this new form of communication moves into the mainstream. If you happen to control the dominant instant messaging standard, then there is the potential, quite literally, to generate billions of dollars in revenue for your company in licensing fees (generating advertising revenue from banner ads in instant messaging clients has been somewhat marginal, in my experience). But you can only do that if you control the instant messaging protocols.

    Here in the United States, there used to be one system of phone companies called the Bell System, the largest part of which was a company called AT&T. If you were an individual who wanted a phone at home, there was only one company you could get (lease) the phone from, and only one company you could get the phone service from. In some cases, the phone connection was actually hard-wired into the wall! AT&T actually had a pretty good thing going for them. They could charge whatever their customers could pay, and had to only offer minimal products and services. Forget about having an answering machine at home, let alone a modem.

    As I said, AT&T had it pretty good. But other companies wanted to provide the same products and services (often, for less than what AT&T charged) as well as new products and services, whether it was national long distance calls from Microwave Communications, Inc. (now called MCI,) or an answering machine from Radio Shack. And, lo and behold, these companies did get to provide those products and services, because it was found by a federal judge that AT&T had abused its monopoly by preventing the entry of competitors into its markets.

    You can be pretty sure AOL doesn't want the same thing to happen to them.

    And that is why AOL has done everything it can to control its instant messaging platform. As long as they continue to keep their system proprietary and can lock people into it, they can charge as much as people are willing to pay and provide the minimum amount of features they want to, because there is no choice for consumers. But only for as long as they can control instant messaging. Once they lose that control, though, all of those wonderful revenue-generating opportunities are greatly reduced.

    That is why AOL has been fighting any attempt to open their protocols and directory services, as well as stifling the IETF's efforts to produce open standards for these.

    As a former employee of an instant messaging company, one whose closure was caused, in part, by this, I've had the opportunity to see some of this first-hand:

    • AOL's AIM client has two protocols for instant messaging. The first, OSCAR, is a proprietary, closed protocol. This is the protocol used by AOL's own AIM clients. The second, TOC, contained a subset of the OSCAR features, was made publicly-available by AOL, probably so they could stimulate growth on platforms they didn't fully support (AmigaOS, BeOs, various flavors of UNIX, and so forth).

      Instead of reverse-engineering the OSCAR protocol, we used AOL's own published TOC protocol to add AIM interoperability in our Windows-based instant messaging client. Thus began a dance of changes by them and fixes by us to maintain interoperability. Bear in mind, the TOC protocol was published by AOL without any terms, conditions, or licensing agreements attached to it. AOL provided a document on the web, and we used the information in it to add compatibility.
    • AOL didn't respond to any phone calls, emails, letters, or faxes we sent to them. It was proverbially like sending messages into a black hole. Any attempt by our executives to have any sort of dialogue with AOL on the subject of interoperability was stone-walled by them.
    • AOL was invited to several key industry events, like Jeff Pulver's instant messaging summit, and didn't attend because "they couldn't determine the appropriate person to attend." And, if memory serves, they also responded to an RFC on instant messaging directory services which a high-level description of their servers. (If someone recalls the exact details, could they please email me? Thank you.)

    After AOL's continual actions to block interoperability (even when using their own published protocols), to miss industry summits, and send the wrong information to the IETF, it becomes very hard to believe any comments they have about interoperability.

    Aryeh Goretsky

    - - -
  • Hello,

    AOL provides a client to people who are not customers of their online service without charging them for it.

    AOL also, at one time, provided their TOC protocol without any licenses or usage restrictions. Although they removed it shortly after, my former employer used it to add AIM interoperability to our Windows instant messaging client.

    From my own personal experience/observation, instant messaging servers are incredibly expensive to setup, run, and maintain. In fact, I would imagine the expenses are somewhat analagous to what the phone company pays in order to maintain the telephone switches used for phone calls.

    However, even though your phone company assumes a financial burden to provide this, they do not prevent you from calling people who use other phone companies, nor do they restrict the brand of the phone you wish to use. At least, that is how it works in the United States, I assume it is the same in most countries around the world.

    AOL freely and openly published their TOC protocol, which has only a subset of the features used by OSCAR, the protocol used by their AIM client. The protocol was published without any usage conditions or license restrictions attached. My former employer used this information to add interoperability in our instant messaging product. We did not reverse-engineer the OSCAR protocol, and we did not violate any of the conditions for using the TOC protocol (q.v., it was, in fact, shipped without any).

    If AOL wanted to make some sort of agreement on advertising revenue with us, all they would have had to to do was to reply to one of our phone calls, letters, faxes, emails, etc., and start a dialogue.

    They never did.

    My experience with banner advertisements in instant messaging programs is limited, but it was not a major source of revenue for my former employer. Providing OEM versions of the software was where almost all of the revenue came from; and if you can fend off interoperabilty attempts from other companies, you can then potentially make a fortune. But that's only if you control it. If all the information required for interoperability is publicly-available, you lose a very lucrative stream of revenue.

    Aryeh Goretsky

    - - -
  • by istartedi ( 132515 ) on Monday April 16, 2001 @08:42PM (#287040) Journal

    See [] for a press release from last fall disclosing the partnership between Jabber and VA Linux, Slashdot's corporate parent.

  • I've recently begun checking out IM protocols for use in my current employer's application. We want to be able to send messages from our system to a user who could be using any of these IM protocols. This is what initially sent me to investigate AIM. Alas, They don't publish an API. ICQ publishes a very high level one: but not one in which I could write directly to the server. (without a lot of JNI ;) So, I turned to Jabber. They not only provide an open API, but the team has broken ground for entry points into other IM systems. Don't even try to give the Jabber crew a hard time for stealing established system's bandwidth. Credit them for working hard to allow people writing IM clients to reach people regardless of the system they're signed up to. Whatever system becomes the "de facto" standard, let's just hope that it remains useful to those who don't run only those clients that are "blessed" by those who own the standard. Long live Joey Ramone.
  • (see subject)

    Rate me on []
  • Damn Raj.

    Don't u ever answer ur email?

    Vergil Bushnell

  • Of course the jabber people did in fact sumbit a RFC and it was turned down. (read about it on and now it turns out that while the ietf argues about 2 protocols with no support at all that jabber is doing *very* well. I think the IETF messed up on this one and should accept the jabber RFC.
  • This was my primary complaint when I started playing with it a year or so ago (maybe a little less). I was intrigued by the idea of a distributed open source IM client but the fact that your address is server dependent disturbed me.

    Sure email works this way, but I always thought this was one of the big benifits of IM...when people moved accounts or whatever their IM addresses stayed the same (lets u find their new email addresses as well). I admit it would be hard to develop a distributed system where your address is none server dependent but it certainly would be possible and well worth the benifits.

    I can see alot of ISPs trying to restrict their jabber servers (if this ever catches on) to only people who use their service (a server which supports searches could use up alot of resources if it became too big...and these people don't want to be responsible for the eventual spamings that occur). Secondly the fact that searches only work on a single server is just not acceptable...sure maybe there is a web page search but we all know how effective email searches are.
  • Longer spiel: it supports strong encryption mostly transparently to the user: a keypair is generated the first time you use it (without PGP's keyboard input) and public keys are passed around like baseball cards by the clients, without users ever worrying. Trust model is a simple rooted tree.

    Default UI is most similar to zephyr, which gale was a reaction to. gale is multidomain, and in theory more scalable across the internet. Encryption for secrecy mostly operates with private messages; public messages have equal standing, and those live in hierarchical categories, which look like Usenet newsgroups, but the subscription is hierarchical: subbing to 'rec.arts' would catch all '' and 'rec.arts.books' traffic. Encryption still comes into play with public messages in signing for authentication.

    There is a graphical python/Tk client.

    Status: it works perfectly fine for private messages, and there's a buzzing little community with people from Caltech, MIT, CMU, and a few companies, so the multidomain stuff works fine, although there are occasionally hiccups in finding people's public keys, I think usually releated to firewalls. The theoretical scalability is hampered by bugs making multiple servers know about each other dangerous (looping problems), plus the whole concept of public categories is being reworked.

    So it's not ready to be used by a million people, at least not a million people all talking together as opposed to isolated cells, but it does work fine for small cells (I think some companies are using it internally) and has neat features, particularly automatic encryption and authentication, and the hierarchical public categories.

    More info at [].

  • by AaronStJ ( 182845 ) <> on Monday April 16, 2001 @10:12PM (#287056) Homepage
    For those of you rushing out to get Jabber as an AIM replacement (like I did) better settle down. AOL has started blocking all IP adresses from using their servers. So no more interoperability with AIM.

    Jabber still works with ICQ, Yahoo, and MSN messangers, just not AIM. Maybe someday AOL and Jabber can come up with an agreement. But as it is, things are at a stalemate.
  • I hate to come off sounding like some loathed semantics fiend, but, c'mon. Linux is not an "operating system." At least, not alone.

    While I can understand and appreciate the importance of making a distinction, I rapidly got tired of replying to "What OS do you use?" with, "I use the Linux kernel compiled with gcc 2.95.2 (formerly known as egcs, which was forked from gcc) (yes, I understand that gcc isn't Linux-dependent) coupled with a number of supporting GNU utilities (Mostly compiled by RedHat; they may or may not have some patches to fork/configure them -- yes, I understand GNU utilities aren't Linux-dependent) including the aforementioned gcc as well as glibc (yes, I understand it isn't Linux-dependent) with the original bootstrapping iteration of getting a compiled kernel up and running done using the RedHat bootdisk from version 6.1 and the RH-supplied version of gcc (which may or may not have patches make it an unofficial fork from the FSF's gcc), most of the installed software are the RedHat 6.2 rpms (including updates) although I had originally installed RedHat 6.1 and manually upgraded via RPM rather than RedHat's traditional reboot/upgrade mechanism, under Xwindows (which uses XFree86 as the server -- yes, I understand it isn't Linux-dependent) I've got GNOME (Yes, I understand it isn't Linux-dependent) using Ximian (which used to be named Helixcode -- yes, [all together now] I understand it isn't Linux-dependent)."

    These days, I just say "Linux". In all that extra time I've saved, I've managed to find a 10 line proof for Fermat's Last Theorem (though I don't have enough space left in this comment to include it).

  • The majority of computers are still in the corporate sector. We all use ICQ and AIM for communication, and nobody is happy about it. Some companies have tried to block AIM as a security risk (you can send corporate information out without any log of it), but found that it became key to the company's communication.

    This is why Microsoft developed Conferencing Server []. It functions identically to MSN Messenger, except you use it only within an organization. So the theory is that it's more secure in that you only allow company users to chat on it (or exchange files, video conference, etc).
  • by madumas ( 186398 ) on Monday April 16, 2001 @08:37PM (#287060)
    Let's talk about JabberIM. I know there is alternatives, but last time I checked, it's the only one that works ok on a network drive under windows.

    The interface is simple, it's easy to use. But there is some problems:

    Frequent disconnection

    Concurrent connection: If I open two JabberIM on different machines, they will battle for the control of the connection!

    MSN stay connected when I close JabberIM. Very annoying, friends talk to a wall during hours.

    Or the messages pop and hide my work, or I never see them... I can't wait a few seconds before reading the mail like I was used to on ICQ and MSN.

    If a new user send me a message while I write to the other, the new window will capture my keystroke. Very annoying when you say : "I love you!".

    If those isues would be resolved, JabberIM would perfect for my needs.

  • I have trying to use jabber for the last year or so but it just was not good enough. But now finally good enough to use all the time.
  • Well the whole system is not..but I am. For example I have an address on If the server goes down I can't communicate. If I talking to someone on I can't talk to him if that server fails. So that makes two points of failure. I tried IMing across the two servers once and it was about a 20 sec delay to get the message to the other person. Has anyone else noticed this problem or was it a fluke?
  • I think Jabber addresses are easier to remember. I mean ICQ uses numbers so they are like 34365242523. AOL usernames get so weird. You get names like bob3436 tom353. Think those are hard to remember.

    I am using winjab [] one problem was I constantly got messages from ICQ and emails. I talk to them in the chat window and then their respond comes as an email. In the prefs I figured out how to make their messages come in the chat windows. Problem is when they send something to me while I am offline, I come back online and then the message come up in a chat window.

  • Well if jabber got that big it would be just like email. I don't find email addresses hard to remember. But it doesn't really matter you usually just copy and paste into your contact list and forget it. Thing I hate about ICQ ID is it makes spamming easier. Just type in any number under 7000000 and you will spam someone.

    In Winjab I can give people nicknames. So I see the nickname on the contact list. I see the nickname when I chat to them. No need to remember their jabber address.
  • I've become a jabber fanatic for one reason and that's the server side address book. It is such a dream to be able to sign in from any computer (either with a client or with the java client or if all else fails the new telnet client) and my addresses just appear. It really is one less headache that I'm glad to be rid of when I'm setting up an OS (or reinstall win2k for the 3rd time on the same computer.) There now I've done my evangalizing for the day.
  • What's harming Jabber is not lack of users. Userbases have to be built up from somewhere, and zero is as good a place to start as any.

    No, what's harming Jabber is lack of sexual content.

    Let's face it: sex sells. Sexuality pervades the modern marketplace, glistening as it dribbles down the sides of billboards selling cars and radiating off the neon shine of liquor displays. If Jabber is to succeed, it must get in at the ground level with sex now, before the secret of successs gets out and everyone's doing it.

    Jabber must be integrated with the state of the art in neural network sexual-tension-recognition software to bring the latest in sexual stimulation to sex-starved clients. Whereas AIM is content to convert emoticons such as ":-)" into smiley faces, Jabber must display full-frontal graphic and explicit nudity. If someone ends an IM with }:-), then there had better be goatsex [] on his partner's screen. We deserve no less.

    Only once Jabber has colonized the citizenry's noosphere can it be declared an unabashed success. We shall have six-year-olds snickering "jab her" and making rude pelvic thrusts within our time! Russia shall not be the first to land an IM client on Uranus [].

    That is the path Jabber's development team should take. Whether they shall see the light is a different matter, alas.
  • There is a “Jabber User Directory” hosted on If the admin of your server has activated it in its config, you can register on it. (Your server can also have a local users directory, or both)

    So, if the server admins are responsible, we'll get searching capabilities for users that want to be found

    IMHO, one does not need such facilities. There is none for e-mail, and we are happy so, aren't we? If there where any such facility, it would make spammer's life SO much easier! How do you send your friends an e-mail? Yes, you ask them not only for their “username”, but also for their e-mail domain. Shocking, isn't it?

    And for the “too much confusing choices”, sensible defaults should do the trick for those who are confused. I appreciate choosing the way I receive messages if I wish so. There is no reason to impose that the sender and the recipient see them in the same way if they have different tastes.

  • by ReuabLeahcim ( 443853 ) on Monday April 16, 2001 @10:07PM (#287105) Homepage and (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 [mailto] or [mailto]. Peace!

You will never amount to much. -- Munich Schoolmaster, to Albert Einstein, age 10