Slashdot Mirror
Unified Instant Messaging Clients?
Hynman writes "It's getting silly - I have 4 different types of messaging accounts: ICQ, AOL IM, MS Messenger, Hotmail and regular email clients all run on my computer at the same time, and they all have overlapping capabilities. Is there any effort out there to produce a unified messaging client, that supports all types of accounts, and will respond through the correct medium (i.e. the medium that the message is delivered in). Just plug in the account information for each medium, and it performs messaging functions of all services frome one program and one interface." This is why standards for instant messengers should be created. Something like this would be extremely useful. Comments?
Everybuddy aims to do just this - one client, multiple services.
This is a quote from the "Everybuddy" homepage: As of right now, Everybuddy has support for AIM, ICQ, and Yahoo! chat programs. It also has file transfer between other Everybuddy users, and planned support for file transfer to other users. You can find this at http://www.everybuddy.com/ I've tried the ICQ aspect but I suspect it's still in beat (current stable release is 0.0.6).
--8<--
Is that most of those IMs are from the same companies:AIM && ICQ belong to AOL, Hotmail && MSIM belong to MS...
I undesrstand if AOL wants to block out MS clients from its service (although i think it's a pretty stupid move...), but why shouldn't they allow their _own_ costumers to use all of their features? This is just plain odd to me, if the purpose is to have a large DB of users as possible, why seperate it into two??
I strongly urge all companies and public interest groups to act in order to enforce a single, safe(!!) and working protocol...
To the fool, he who speaks wisdom will sound foolish. ---Euripides
What happens when you go to the bathoom?
If you really need details, check out a good physiology textbook.
--
Mod up a post Rob doesn't like and you'll never mod again
One thing I'd like to see is an instant messaging client that converts messages into email and sends them to you. Then I could just check my inbox rather than inbox plus several messaging programs. Coping with outgoing messages would be more complex, but probably the Reply-To: address on the message would be something like 'icq-4929392@localhost', which the client could then pass on to ICQ.
The beauty of this is that you don't have to write yet another messaging client, even a grand unified one. You just need one wrapper for each protocol, to convert it to and from mail. There wouldn't be any noticeable speed loss, since the mail is being sent locally and outgoing messages are converted into ICQ (or whatever).
(Although I've never seen the point of instant messaging anyway, email seems easily instant enough to me.)
-- Ed Avis ed@membled.com
Although Microsoft is said to have "lost" the IM "war", and AOL is said to have "won" the IM "war", open-source is a definite loser here?
Ever since the "war" started, AOL has pulled all of the open-source clients from its page, including TiK, Laim, and TNT. The gaim developers have also been not-so-politely asked to pull the AIM logo from their client.
The "war" is long over, but the open-source clients are still missing, and AOL has removed every trace of them that was remaining.
On another topic, has anyone noticed that both AOL and Microsoft are terrible hypocrites when it comes to open standards? Microsoft, the closed-source company is whining about open standards when it isn't at an advantage, and AOL, who has recently taken steps to seem pro-OSS is... well, the facts speak for themselves.
I guess this is to be expected from large corporations...
--
And if anyone wants to help building a decent IM, one that doesn't take 11 megs of memory, check out the Mozilla-IM newsgroup netscape.public.mozilla.rt-messaging on news.mozilla.org
Apathy -- The state of numbness of the mind. When you are apathic, you can think.
As a person of libertarian bent; real-time messaging poses a difficult problem.
The natural solution, for a grand public good such as this, is to let the government set the protocol, and run the server. For the US, this wouldn't even be a wild stretch of the constitution; for it's just a natural extension of the Post Office. Except for the inevitable DOS attacks, and the manpower and hardware needed to overcome them, I don't see it as being too expensive, compared to the trillions the government spends every year anyway.
But, the major powers fighting over this (AT&T, AOL, Microsoft, Yahoo, etc) are never going to propose that. They stand to make too much money off of advertising, to settle for something like that. And your average Republican member of Congress isn't going to know enough about computers to see how easy it would be; they're more likely to do nothing than to approve $25 million or whatever to set up the system. And, in turn, this will lead to a push by your average Democratic members of Congress, who on average know just as little about the internet, to force somebody to open up their servers. And, unlike the Cable TV connectivity, it'd be impossible to set up a way for Company A to reimburse Company B; so the Company running the servers would have to either A) incur a loss or B) shut down the system.
If it can be made to work, Jabber would make an excellent compromise. If ISPs ran Jabber servers, interconnecting in the same way an IRC network or SMTP servers work, everyone would benefit, but nobody could get a free ride (as MS, AOL, AT&T are all trying to get on each other).
I got a bunch of immature, hostile replys (fortunately no emails) for taking a strong, but unpopular, position yesterday. Should this posting be just as unpopular, I hope the discussion is a bit more mature, than just calling me a w4r3z d00d or something.
Oh yeah, and this is a US-centric post. International issues make it even trickier...
The problem with standards creation is that there is no economic incentive for AOL or MS to create them. If I am AOL and you are MS or an open source project, what incentive do I have to let you access my system. The entire point of offering IM is to control its users. For example if I'm AOL I may want to start selling advertisements on ICQ. This doesn't work to well for me if other organizations or companies can tap into my network and let people run a program that doesn't use the adds. If I allow this to happen I potentially run the risk of paying to maintain servers and support, but no revenue.
As I see it this problem can be solved in one of two ways. Some authoritative force can require companies to allow open access to their systems. This will force companies to either shut down their IM's or come up with an alternative way to justify their expense.
The other way is some independent group coming up with a standard and creating good IM clients to support it. The problem with this will be that it faces an uphill battle with existing services, which is precisely the annoyance that brought this question.
It is late, but I'll happily follow any elegant solution to this problem. I'd just rather see a permanent fix than having a client that gets its access blocked every couple of months.
The IETF is currently organizaing a standard, and I believe MS and AOL are in on it, amazingly.
But who cares if they do have a standard? It doesn't mean anyone's going to use it. If none of the big guys implement it, or implement it strictly to the standard, we'll be stuck with clients that don't intercommunicate.
Now, if someone started an open source project, following the IETF developments, and there was a public effort to convince everyone to use these open clients rather than AIM, MSNMessenger, etc.
I for one, would certainly use it, and promote it to my friends and co-workers. I'd keep AIM on until enough of my "buddies" were phased over.
Well, the BeOS camp has had a project in the works for a while now and it's called Gimmick ( http://www.gimmick.org/ ). They've been releasing neat betas, and hopefully it could become a nice tool.
"Never ascribe to malice that which is adequately explained by incompetence" - Napoleon Bonaparte
The Internet Engineering Task Force (http://www.ietf.org) is working on an instant messaging standard, known as IMPP (Instant Messaging and Presence Protocol). The Working Group has a few Internet-Drafts available at http://www.ietf.org/html.charte rs/impp-charter.html, but no RFCs yet.
My impression is that the design of this protocol (in opposite to e.g. ICQ) is good, and I think this will be _the_ IM protocol to use, when IETF's work is finished. AFAIK, at least Microsoft is going to use IMPP (this is the "open standard" referred to during the IM war with AOL).
The current Instant Messaging model suffers from several glaring problems stemming mostly from the reliance on centrally controlled messaging servers (that double as ad servers). Major issues with the current IM model include:
- Reliability: Does the whole world want to count on one company's servers to stay up 24/7?
- Security: What if someone breaks into the server that has your passwords? What if (hypothetically of course) an employee of AOL doesn't like you?
- Privacy: Isn't it a warm feeling knowing that all your text goes through some other company's messaging servers?
- Authentication: How the hell do you know who's on the other end of the line?
In light of these concerns it astounds me that bosses in some companies use ICQ to talk to their employees on the job. ICQ may be a fun toy but do you really want to bet your company's next product (or for that matter your company) on it?In order to achieve IM nirvana the best route is always to take the least broken existing solution and try to fix it. In this case the least broken solution is not AIM or ICQ. I nominate Unix talk and IRC as candidates for the least broken existing solution.
Either of the old Unix standbys offers decentralized communication independent of any master company. A decentralized protocol right away eliminates the reliability issue, and at least gives you a fighting chance to address security, privacy, and authentication. While security is never easy on the plaintext internet, many of the same techniques that are used to secure telnet (e.g. ssh, IPsec) apply equally well to messaging as long as the protocol is decentralized.
As for graphical interfaces, WinTalk and mIRC already deliver the required windowing interface to these protocols. Buddy lists can be implemented by
- Packaging a finger daemon with the chat client, so that people can use finger to see who's logged on,
- Packaging a finger client with the chat client, so people can see which friends of theirs are logged on,
- Anyone have any idea how to fix the problem of dynamic IPs?
It's not a perfect solution and there are still points that need to be worked out but I feel that the old Unix programs provide a much more solid foundation for achieving a 90% useful solution than the new breed of corporation-serving adware Instant Messaging programs.Could this not all be implemented on top of the
existing IRC protocol?
I'm sorry if I'm all wrong about IM's, I haven't really had much
experience other than "Hrrm, someone's been touching
*my* work computer, in *my* cubicle, hrrm, what's
this funny thing in the task bar, AAAAAAAAAAARGH!! AOL!! KILL IT, KILL IT!!! DIEDIEDIEDIEDIEDIE!!!!"
(yes we run win9x, it's company policy, I have no choice)
but enough digressing.
Could not a slightly modified network of IRC servers essentially
duplicate all the features of an IM? For instance
seeing if they are online, file transfer, video conferencing could
easily be added via DCC or something like that. Why
must we reinvent the wheel when we already have
a protocol which can be modified to suit?
of course I could be completely wrong, so flame away.
----------------------
"Hope is the denial of reality, it is the carrot dangled before the draft horse in a vain attempt to reach it" - Raistl
There are severak IM clients that are attempting this, even if still in the beta stage. I'm surprised no one has mentioned AT&T's "I M Here" client. It was on Slashdot just a week or so ago. It already has support for AIM and MSN Messanger, with support for ICQ and Yahoo! pager in the works. Problem is, of course, that Tribal Voice developed it, and their apps for AT&T have been less than impressive. Oh, yeah, it's only good at work, since it only works with Windows 95/98 or NT. Wait a minute, maybe that's why no one posted it...
"137!! Why 137!"
Gimmick is a client being developed for the BeOS that can understand as many IM protocols as there is plug-ins for it. Drop an AIM plug-in into a folder, and you can get AIM messages. Drop an ICQ plug-in into a folder, and you can get ICQ messages. There is talk of a Jabber plug-in too. If there is anyone interested in it, please e-mail the guys who are working on it. They can use all the development help they can, and might be interested in helping port it to other platforms.
"I'd like to die quietly in my sleep like Grandpa, and not screaming like all the passengers in his bus."
... then MS would just come in and load an IM client on every WindowsXX box and drive AIM out of business... as well as ICQ, etc.
Therefore I'm against a standard, although I think it'd be great to see one implemented.
Right, so some of us don't work on *nix boxes.
everybuddy doesn't support us.
AOL hasn't folded ICQ into their messaging system for two reasons: 1) their internal instant message client has been around since AOL 1.0 or before and those that haven't upgraded to more recent versions could be out of luck 2) they sell virtual real estate at the top of their standalone app.
While theoretically, AOL could translate ICQ messages on their way through, even the naming conventions are radically different.
Sure, standards would be great, but don't look to AOL to implement them anytime soon.
I haven't managed to try this out yet (BeOS doesn't support CHAP, but that's another story), but it looks really promising.
They support ICQ, Jabber and AOL IM, so far they've released the ICQ part for testing and the rest is upcoming, although how upcoming is another matter - the last update on the site was August 2nd.
Gimmick
www.epicware.com/fire.html. Fire has been around for the last 6-8 months. It currently supports AIM, ICQ and Yahoo. Is open sourced, based on open source protocols (libfaim, libicq, libyahoo), could be ported to Windows (if apple would release cocoa), has been ported to openstep, coul be ported to Linux (By way of GNUStep). It's pretty mature and has a nice UI.
Just in case you didn't know, icq is owned by AOL now. So, I think it would be in AOL's best interest to somehow combine the two.
Project Steve
"It's getting silly - I have 4 different types of messaging accounts: ICQ, AOL IM, MS Messenger, Hotmail and regular email clients all run on my computer at the same time, and they all have overlapping capabilities."
I just don't understand this. Myself and several friends all got ICQ very early on, it has served us well. I cannot grok why one would load 4 clients? Is it necessary to make yourself accessible to every possible IM user on the planet? I realize it may be different for others, but basically the only people we want to IM are each other. I have zero desire to be accessible to 20 million AOL users, or the hordes who think those ridiculous "portals" with thier own branded IM's are cool.
As it is, my ignore list is easily twenty times larger than my contact list and all of us tend to view unsolicited IM's from lonely teen chatmongers and useless sales pitches demanding we "!!!!Go HERE NOW!!!!" as rude - I just don't get it.
All that said, a unified, standardized protocol only makes sense - I just don't understand the need that drives people to load multiple clients. Would someone clue me in?
======
"Rex unto my cleeb, and thou shalt have everlasting blort." - Zorp 3:16
Sacred cows make the best burgers.
Other than the server-to-server communication it is pretty good (esp. considering it is late 80s technology). Of course, if you designed it today it would use MIME and content-type text/html instead of its own simple formatting language @b(this in bold) @i(this in italics) @large(etc).
Anyway, the IETF IMPP mailing lists are hosted here:
impp@iastate.edu . . . (technical stuff)
meta-impp@iastate.edu . . . (other stuff)
(It's majordomo, you know how to use it)
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
I have a few questions though about a potential standardized protocol. First, would instant messages likely be sent in HTML format? Second, which of these AIM features would likely make it into the protocol? 1) Maintaining a profile for each online user, possibly with attributes like age, gender, e-mail address, etc? 2) Being able to poll for other users that are online, according to their attributes, in order to potentially meet new people? 3) Being able to tell how long another person has been online? 4) Displaying an away message when the user is not active with the client? My point is, I don't want to end up with standardized clients that only perform the most basic of functions. On the other hand, I'm also guessing that the above features would possibly get a little messy, what with multiple unrelated servers across the globe handling the IM's. Can anyone enlighten me? Lastly, an open protocol would be great, but a standardized quick-n-dirty cross-platform Instant Messaging API would be a welcome compliment.
- Reliability: Does the whole world want to count on one company's servers to stay up 24/7?
- Security: What if someone breaks into the server that has your passwords? What if (hypothetically of course) an employee of AOL doesn't like you?
- Privacy: Isn't it a warm feeling knowing that all your text goes through some other company's messaging servers?
- Authentication: How the hell do you know who's on the other end of the line?
Would it suprise you if I said you aren't the first to notice these problems. It's pretty much accepted that Network Presence/Instant messaging has to be a service provided by ISP's, preferably *your* ISP. Obviously, authentification and privacy issues are solveable and they don't really have to involve the ISP much. Where the ISP comes is mainly in two places: (1) making your presence/absence known to selected others via the as-yet-to-be-built Internet Presence network. (2) Providing store and forward for messages that can't be delivered due to the (temporary) absense of the recipient.The real question is, once we manage to produce a good solid NP/IP server/client system, how are we going to get the ISP's to adopt it? Keep this in mind: Neither AOL nor Microsoft has the slightest interest in ISPs support our NP/IP system! (Because they both want us to use their proprietary servers.) So we are going to have a big fight on our hands, and we're going to have to use some very powerful weapons indeed to get what we want.
For starters, we're going to have to reward the ISPs in some way. One idea just off the top of my head is to provide, in the clients, a clickable link for the recipient (and sender for that matter) back to a web page of the ISP's choice. This could be disabled by the user of course, but if the user clicks it the ISP gets some sort of benefit: as ad revenue, or the ability to promote it's own services to the recipient of an IM, or whatever. Another idea is to just include the winning NP/IM protocl in all new versions of the software that ISPs use. I.E, making it part of sendmail or the other mail clients, etc. (the force-feeding method) Another way is to organize some sort of email campaign to get the ISP's on board. We're going to have to have a good plan in place. Don't make any mistake about it: it's going to be an uphill battle.
Life's a bitch but somebody's gotta do it.
But this all seems pretty obvious stuff. Surely there are ISPs using DNS or IP hacks for clever routing of static names and addresses to dynamic connections? Firewall people have done some kinds of this for a long time.
Jabber (or something similar) will skyrocket to success once it is implemented for many of the same reasons that ICQ did the same.
It will only take a handful of people who are using AIM/ICQ/etc to realize that jabber is the answer to their problems. They will start using it. They will tell their friends about it. Their friends will want it. That's all it took for the other IMs.
For people who have ISPs who won't provide a server, there will be a solution. The same solution for people who want an additional email address - third parties will provide it for free.
The TCL/TK client for AIM isn't dead, you can still get information/downloads from places like http://www.oaks.yoyodyne.com/tik. The current version is 0.75 and runs fine under TCL/TK 8.0.5 on UNIX, Windows and the Mac. We even have one implementation of SSL encrypted AIM based on TiK at this point.
%SYSTEM-W-ABORT, abort
- Read Bill LeFebvre's article on Internet Black Holes to learn how the Real-Time Black Hole system uses DNS creatively. You can also go write to the source if you prefer. Here's an excerpt:
- Here's the abstract for TCP Splicing for Application Layer Proxy Performance, by Pravin Bhagwat et al.:
- Here's the abstract for Improving HTTP Caching Proxy Performance with TCP Tap:
- Cohen, A., S. Rangarajan, and H. Slye. On the Performance of TCP Splicing for URL-aware Redirection. In: Proceedings of the USENIX Symposium on Internet Technologies and Systems, pp. 117-125, October 1999.
- A Mobile Networking System based on Internet Protocol(IP) Pravin Bhagwat, Charles Perkins. Proceedings of USENIX Symposium on Mobile and Location Independent Computing, August, 1993, Cambridge, MA.
- A Mobile Host Protocol Supporting Route Optimization and Authentication IEEE Journal on Selected Areas in Communications, special issue on "Mobile and Wireless Computing Networks," 13(5):839-849, June 1995. c IEEE. Andrew Myles Department of Electronics
- RFC 2230 has some words that might be relevant here:
Happy reading.(This post may include:
- S Sarcasm
- B Bitterness
Viewer discretion is advised.)--
Everyone does of course realise that developing another protocol (of which there are at least three in development that I know of) will simply be another protocol? It won't be the take-over one, it will just add to the mess.
What we need are good clients using well-written libraries for each of these types of IM systems. This is more complicated than people realise, but still appropriate and possible.
Note: I'm biased as the maintainer of libicq.
- Michael T. Babcock (Yes, I blog)
Millions is old skool? Shite, mine is under 500,000.
I'm a loner Dottie, a Rebel.
started out right, they allowed people to see when their friends were online, message them, chat with them and send files to them. None of these were new ideas, most of them came from IRC while the interface came from Prodigy's old messager. Now people want to add every function under the sun to these damn things. ICQ is now taking up 10 megs of memory and I'm just sitting online. I hate the thought of the instant message clients because I don't want some nut to interupt me while I'm working with an oversized window. I'm just ranting because I find the direction these things are moving to be assanine. ICQ added stuff I would see in an office suite as part of the STANDARD features. Come on, how about a Lite client for people who don't want bells and whistles. I've had some bad mojo with the GNU clients by the way, when I used them and when other people used them. I think the best version of messager out right now is ICQ for the Mac. I have it on my powerbook and it runs fine and doesn't have a bunch of extra crap I'll never use.
I'm a loner Dottie, a Rebel.
Instant mesaging protocols so far did nothing that IRC protocol can't or doesn't do efficiently, so I would rather prefer improvement of IRC clients/scripts (yes, scripts exist not only for ops wars and flooding), so they will provide functionality, "instant messenger" do now. For me ircII on console and XChat in X already provide everything I need, and the less people will sit on the networks that don't interoperate with IRC, the better.
Contrary to the popular belief, there indeed is no God.
I was thinking more along the lines of low-bandwidth media. Streaming MPEG for (slow) internet access exists, as you have said, but its interoperability factors aren't quite there yet. Meanwhile, Real and Micros~1 will continue to attempt to hold on to their proprietary advantages.
My journal has hot