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