Slashdot Mirror
Jabber As The Coming IM Standard?
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 story links to jabber.com (which is fine) but if you're looking for the open source project you might want to hit jabber.org. The open source project is where it all started, and jabber.com 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"? ;-)
As opposed to your email, where, if your server goes down.. Umm, And if their server is down.. Umm.. 8-P
-- I'm the root of all that's evil, but you can call me cookie..
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.
-- I'm the root of all that's evil, but you can call me cookie..
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.
-- I'm the root of all that's evil, but you can call me cookie..
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.
Check out:
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 roystgnr@rice.edu; 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?
In practice UDP is not actually extremely scalable unless you implement your own congestion control.
DNA just wants to be free...
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.
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?
yes, in fact, several clients support GnuPG encryption. WinJab for Windows and Gabber for GNOME are two excellent free software options.
(For those confused, JabberIM is the Jabber client available from Jabber.com. It is one of many Jabber clients available.)
:) Check this out:
Most of your complaints can be fixed in the Preferences dialog.
>* 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
>you!".
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.
--
Business. Numbers. Money. People. Computer World.
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.
jhw
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.
I'm a loner Dottie, a Rebel.
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'm a loner Dottie, a Rebel.
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.
Craig.
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.
... Linux is becoming a powerhouse on the server!!
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
My journal has hot
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}}
--Mid
- - 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
In fact spliting channels into a separate session control and others is what is suggested by BXXP framework.
LL
man, do they have templates for trolls these days?
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: http://www.newsforge.com/article.pl?sid=01/04/16/1 931237
Can your IM do this?
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.)"
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
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.
-Puk
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.)
I do not deploy Linux. Ever.
However, the new "web client services" shows some promise.
I do not deploy Linux. Ever.
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 'jdev@conference.jabber.org' 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.
I do not deploy Linux. Ever.
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.
I do not deploy Linux. Ever.
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.
Alex
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.
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.
Alex
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.
If a corporation is a personhood, is owning stock slavery?
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.
If a corporation is a personhood, is owning stock slavery?
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.
In fact, the driving forces of Jabber seem to be in conflict with this. The OpenSource jabber.org 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.
Burris
For example, if I could only allow people to send URLs and text externally, but files internally,
Will I retire or break 10K?
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.
Will I retire or break 10K?
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.
Will I retire or break 10K?
This is silly since its the first thing that everyone tries to do after installing IM software.
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.
Hello,
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:
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.
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
- - -
Dexter is a good dog.
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
- - -
Dexter is a good dog.
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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 Picture-rate.com
"and dear god does this website suck now." -- CmdrTaco
Don't u ever answer ur email?
Vergil Bushnell
Insects and Grafitti Photos
Of course the jabber people did in fact sumbit a RFC and it was turned down. (read about it on jabber.org) 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.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
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.
If you liked this thought maybe you would find my blog nice too:
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 'rec.arts.tv' 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 gale.org.
For those of you rushing out to get Jabber as an AIM replacement (like I did) better settle down. AOL has started blocking all jabber.com 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.
Stupid like a fox!
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.
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 jabber.org. 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.
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!
10 January 1610