Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet

Unified Instant Messaging Clients? 272

Posted by Cliff from the would-this-end-the-IM-wars? dept.
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 discussion has been archived. No new comments can be posted.

Unified Instant Messaging Clients? More

Unified Instant Messaging Clients?

Comments Filter:
  • Everybuddy [everybuddy.com] aims to do just this - one client, multiple services.

  • Everybuddy... (Score:5)

    by rongen ( 103161 ) on Saturday December 18, 1999 @01:56AM (#1463800) Homepage
    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/ [everybuddy.com] I've tried the ICQ aspect but I suspect it's still in beat (current stable release is 0.0.6).

  • The Silliest Part About It... (Score:3)

    by try67 ( 89578 ) on Saturday December 18, 1999 @02:02AM (#1463803)
    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...
  • 1. Not everyone is a nerd

    2. It's nice to see which of your friends are online at a glance (i.e. without having to finger them all, which wouldn't work so well anyway)

    3. It's fantastic for file transfers - about the fastest way, in terms of user work

    4. Email is a pain for having a realtime conversation on, and the talk command is clunky - you have to open up a new terminal for each person you're talking to, and keep it open during the breaks in conversation, and keep looking to see if they've responded yet
  • What happens when you go to the bathoom?

    If you really need details, check out a good physiology textbook.

  • Instant messaging mail (Score:3)

    by Ed Avis ( 5917 ) <ed@membled.com> on Saturday December 18, 1999 @02:16AM (#1463806) Homepage
    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.)
  • Quoted from UK mag PCPlus:

    "Microsoft has pulled out of the fight claiming that to continue to squabble over standards would constitute an unacceptable security risk"..."[about Microsoft's MSN Messenger] AOL quickly cried foul claiming that Microsoft was hacking into its servers without authority and blocked access"..."[MSN messenger] now makes not attempt to access AOL Instant Messenging accounts"..."Microsoft claims to have 4.5 million using MSN Messenger while AOL has a more substantial 80 million users"

    They go on to say that there are moves to establish a universal standard by the IETF, and the standard should be released by the summer of 2000.

  • The question I have is where are all the standards agencies in this battle? I'm curious to know, are any of them working on a standard? Will they even bother? Or are the current [standards] too new and immature still? There are RFCs on just about everything, I know there's one for IRC somewhere, so instant messaging isn't a far shot from IRC, other than the need to have a single large network instead of any number of seperate competing networks.

    Man's unique agony as a species consists in his perpetual conflict between the desire to stand out and the need to blend in.

  • Heh, yep everybody sits there clicking the 'Check Email' button, trying to have an IM chat with somebody about if the world should be made flay again, 'Check Email' 'Check Email' 'Check Email' No, the main thing about IM clients is the message is delivered to you, you don't have to retreive it off a server somewhere...
  • Instant messaging? . . . An annoyance right on par with telemarketing, spam, junk mail and Geocities/Tripod pop-up screens.
  • We have to bear in mind that many people use webmail or POP mailboxes, and therefore do not instantly get messages. (Yes, POP can be collected at regular intervals, but not exactly the same thing.) This is the market the the instant messaging programs cater for. Also, the IMs usually have a feature that allow you to see who is currently online from your contact list. Yes, this feature is available on irc (notify), but there are many irc networks out there, also irc requires you to log on, while the IMs log on automatically.

  • Re:The Silliest Part About It... (Score:3)

    by pen ( 7191 ) on Saturday December 18, 1999 @02:26AM (#1463813)
    Well, you see, AOL's AIM clients have ads on them. When a user uses someone else's AIM client, the ads are no longer displayed, and AOL loses its investment, while the user is still taking up bandwidth and server space (however little). Furthermore, whoever made the AIM client actually makes a profit from their own ads.

    It's AOL's servers, and they may choose to block out whoever they want. You wouldn't blame someone for restricting access to their HTTP or FTP server, right?

    --

  • The purpose isn't to have a large database of users. The purpose...

    1) ...for AOL is to get as many people subscribing to their service as possible; with ad revenues as a consolation for people who do AIM or ICQ, but don't get suckered into AOL.

    2) ...for Microsoft is to boost the overall brand strength, and thus gain more corporate sales, through convincing people that Microsoft can provide solutions for any computing need. Picking up ad revenues is a nice backup as well, should government action mess with the core business.

  • Re:Microsoft backs down from AOL (Score:3)

    by pen ( 7191 ) on Saturday December 18, 1999 @02:32AM (#1463816)
    (A bit off-topic.)

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

    --

  • "There is nothing an IM application can do that an IRC client cannot

    Some of my friends hang out on Efnet, others on DalNet.. To see if they are online I have to log on to both servers. With an IM, it is right there, in a nice colourful list.

  • IRC is for chating.. IMs are the *NIX WHO, ECHO, and TALK commands all rolled into one nice colourful package
  • 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

  • Tricky issue (Score:4)

    by JamesKPolk ( 13313 ) on Saturday December 18, 1999 @02:48AM (#1463822) Homepage
    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...
  • Hell, I'd be happy with a good standard for authenticated SMTP...

    I like the idea of "instant messaging", but all the implementations are so clunky...
  • 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.

  • ...but it's solicited, therein lies the difference.

    I've actually benefitted a great deal from instant messaging. I telecommute (I live in Wash. State, my coworkers mostly live in California), and this is how I collaborate with my counterparts. There are tons of ICQ clients out there you can choose from, for whatever OS or features you want.



    - Jeff A. Campbell
    - VelociNews (http://www.velocinews.com [velocinews.com])

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

  • Gimmick (Score:3)

    by katsumi ( 127638 ) on Saturday December 18, 1999 @03:06AM (#1463827)
    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.

  • IETF is developing IMPP (Score:5)

    by magnus.ihse ( 41120 ) on Saturday December 18, 1999 @03:14AM (#1463828) Homepage
    The Internet Engineering Task Force (http://www.ietf.org [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 [ietf.org], 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).
  • Instant Messaging in its current form was designed by companies like AOL and Mirabilis for business purposes. While this corporate backing has made Instant Messaging popular, we must remember that corporations serve their own interests, not their users' interests. Just because AIM and ICQ are popular doesn't mean that they're the Right Thing from the user point of view.

    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

    1. Packaging a finger daemon with the chat client, so that people can use finger to see who's logged on,
    2. Packaging a finger client with the chat client, so people can see which friends of theirs are logged on,
    3. 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.
  • then it wouldn't be instant messaging, would it?
  • Sounds like there needs to be an extention to POP or IMAP that says: "When I get email, send me a message ip#.#.#.#:## and then the popclient wakes up and fetches the mail. Polling is not the best way to do things like this.
  • 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.
    ----------------------
  • 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...
  • Why would a program that bundles all other chat alike programs together *also* contain its own protocol (like the filetransfer you mentioned) ?
    IMHO, this only makes matters worse. It should use file transfer from another protocol like ICQ to do this, not its own protocol so that other all-in-one programs don't have to incorporate the 'everybuddy' protocol as well.
    Obviously, this is not an issue when this 'everybuddy filetransfer' is actually an ICQ/AIM/whatever filetransfer with its own interface..
  • www.everybuddy.com

    It works pretty darn well already.

    Nuff Said.
  • I'm pretty sure that you can do this with a licq plugin. I've seen it done before.. icq -> email gateway, and because it's email, it can also allow you to read messages on a pager.
  • err, of course, for the IM/ICQQ user, this
    would require a modified GUI client with lots
    of pretty buttons and so forth, oops
  • Gimmick [gimmick.org] 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 hear ya. It doesn't sound like bad idea to me. The protocol would be find. As long as the client and UI is completely different.

    But doesn't IRC have the problem of a slew of isolated networks. i.e. if you're on one, and your friend is on the other, you can't chat until one of you switches to a server in the other's network?

    Forgive me if I am off here -- when I used IRC, I never got heavily into it.

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

    Of course, Mirabilis's whole point was to sell servers to companies that want to have instant messaging in the office. The original idea was to have your *own* ICQ server at work.

    > 1. Packaging a finger daemon with the
    > chat client, so that people can use
    > finger to see who's logged on, ...

    if security is a concern, finger is probably not the best way to do this, as it is one of the first things a lot of administrators turn off...

    But you're right, it would be good to see a nice, open, and *secure* instant message protocol. I think the Jabber [jabber.org] project seems to be on the right track.

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

  • You are right, that could be a problem. Perhaps
    having a seperate IRC network for the IM, or
    having the client connect to whichever IRC networks
    you wish and do a WHOIS on the person you are
    looking for, or just always be on one IRC network.
    there should be tons of people to talk to on a
    decent IRC net anyhow. Anyway, those are the only
    ideas I can think of right now, I'm rather tired and
    my brain is giving out, so pleaase forgive me.

  • Re:Tricky issue (Score:1)

    by Anonymous Coward
    This force-fed advertising crap is super evil. We must fight for our minds. It's the most important battle we have.
  • I have 16 people on my ICQ list, and not one of them would go anywhere near a unix shell, much less finger or ytalk.

  • Should have co-opted fingerd (Score:1)

    by Anonymous Coward
    The finger protocol could easily be used here. And should have been. All you do is have a version of a finger daemon that has an opt-in policy. If you don't have, say, a ~/.fingerable file, or whatever, it won't even look at you.
  • 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.
  • Even if there is a standard, the real problem is the fact that you have to use one or two controlled servers. It's the only way any of these IMs will work. Who controls the servers then has your friends and family list for marketing purposes. I'm sure the privacy issues are more then trivial.
    What is needed is a serverless IM. Tragic looks to be a good starting place, but needs a little help making it more robust and figuring out a better naming convetion. Once it really is peer to peer then privacy is only a matter of encryption, and the single point of failure in the server is gone.

  • Re:It's not about standards, but servers. (Score:1)

    by Anonymous Coward
    Let there be no doubt: Big Brother is not the government. Big Brother is corporate greed.
  • 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 [gimmick.org]
  • Sure, standards would be great, but don't look to AOL to implement them anytime soon.

    Sure, standards would be great, everyone should have one. :)

  • dumbass! icq sends messages DIRECTLY! (Score:1)

    by Anonymous Coward
    all the ICQ servers do is tell you the IP and the PORT of the people on ICQ. you send instant messenges DIRECTLY with a TCP connection. which is ideal, in my opinion.
  • My dad has always liked that quote. As for me, I hope somewhere out there or some groups of people out there would be nice enough to put in the time and effort to make an all-in-one "im" client and possibly have ports to most of the popular os's
  • One is on its way, a Mozilla client of Jabber.

    We should be able to put it together relatively quickly, we have just been waiting for the Mozilla code to stabilize.

    It will be used in the sidebar of the browser, but we also hope to have the option of having a window.open() to let it float in a separate window.

    Also, there is an API for the "throbber", thus allowing it to be an indicator for an incoming message, we have not looked into it yet.

    We should have something useable by mid-January at the latest.

    Eric Murphy

    P.S. See the first post on the main thread for more info on Jabber.
  • As much as I generally dislike government meddling, any universal solution is inherently monopolistic and should be government run or heavily regulated. Somehow the Post Office seems a better choice than the FCC. Of course, there is always anarchy, but MS, AOL, AT&T will always use too much muscle. Interesting times we live in.
  • 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.

  • I agree with this completely, I think there must be a way of creating a "tallbar" interface for IRC which would simulate an ICQ/AIM/whatever environment. The "tallbar" can represent a series of different channels. You would have your work channel on your work IRC server where all your coworkers hang out... then on undernet you have that hidden channel where your friends hang out. Almost all the "IM" aspects of it could be done with DCC chat and file transfers... while you would also have the advantage of not having to build a contact list... you just create a hidden, password protected channel, and invite people to it.

    The only problem I can see with this interface are the problems with IRC in general.. But the protocol, infrastructure and servers are already there. It sounds like all we need is a IM GUI.

    (Off-topic though because it neglects the cross-protcol client question...)

  • 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.
  • I use it too for work... sometimes I use it to communicate with coworkers that are 10 meters from my desk !!
  • Quite amusing yeah, I have to agree. But what you have to remember, is that everybody has a different sense of humour and mood swings. Ugh, sounds like I'm sticking up for them here (perish the thought) but I just want to point out that everyone is different, and they will have different opinions. Okay, enough said. I'll shut up now.

  • I've given this a bit of thought over the past month, and I've been thinking of a tallbar interface with multiple collapsing groups of people. In other words, you can have multiple channels on multiple servers in your tallbar at the same time. All your friends/coworkers can exist in password protected hidden channels. I think it is a great idea.

    Anybody out there an IRC client author who is willing to rip up their UI? It shouldn't be hard to do this sort of thing.

    Hmmm... I really have to learn X programming... maybe ripping up another Opensource IRC client GUI is the way to do it. hmm...

  • You're right it is about servers. But c'mon people, computers are where they are based on corporate greed. They would be back in the punchcard area still without the corporate influence. And, thinking of that, why would a company invest huge amounts of money to provide a messaging server that you can access without paying them any homage. Yahoo, AIM and the rest provide instant messaging capabilities because they can lure people to their services. If they let you write your own client that can subscribe and work without ever visiting their site they are essentially spending real money for no real benefit. As much as people may wish that computers were part of a socialist state, you might as well face the fact that you wouldn't HAVE any computer at all to use if that's the way things got done.

    I'd like to see the companies get together and form a standard. They could each get 25% of the advert time on the client they distribute or something to make their investments pay off. But, if the client is open, then people will pull out the ads. If people pull out the ads, then the instant messenger people will stop investing in their servers.

    I've heard people argue about this as if there weren't many thousands of dollars in servers running out there to serve their chatting needs. Like somehow AOL has found these servers growing in a field and simply put them in a cage.

    I like the idea of peer-to-peer, but that only limits the need for servers, it doesn't eliminate it. You still need a central server for name resolution. Sure, I have a fixed IP I could give to my friends, but most people don't. So, even if the communication is peer to peer (which is still very tough to do if both people are behind proxies) the naming requires a server. Maybe an open source group like VA or RedHat would sponsor it, but I doubt ANY company with enough money to do it would want to do it if they couldn't control having their adds on the client.

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

    Email works without a central point of control, aside from DNS. Why should instant messaging and presence be any different?

  • Seeing that there are multiple projects going on, (jabber, everybuddy, i've seen a few others....) in attempt to merge current instant messaging protocols... err software... but anyway, won't this create the same thing, people having to use multiple instant messaging software to be able to communicate with people? oh well.

  • Client-Server is dead as feudalism (Score:1)

    by Anonymous Coward
    The feudal "client-server" mentality of lords and serfs is dead. A healthier, peer-to-peer relationship between equally respected and empowered freemen (well, free computers) is the only scalable system. Why do you think Linux already comes complete as a full computer, with inetd well populated? We don't need no stinking servers. We have our own daemons, and don't need AOL or anybody else to babysit our dumb terminals.
  • I use aim to communicate with other people i know who are on AOL, and i regularly get the newest betas, and recently they added an "offline" list. This is new to AIM, and I feel it is a step towards integrating the features of ICQ, if not one day... they may be both integrated togethether.

  • "If a standard was created then MS would just come in and load an IM client on every WindowsXX box" - this is a reason to be AGAINST a standard? What? So what you're basically saying is that you'd like for everyone to be able to talk to everyone else, but if Microsoft helped make that possible it would somehow be a BAD thing? Geez, not everything Microsoft does is bad! If my mom and girlfriend that don't have the ability to go out and find an open source tool were still able to chat with me that would be a "good" thing. If it were by a standard, you could always go get your open sourced version, what difference does it make?

    I've heard this crap before for why people don't want to use some of the XML standards. Who cares if MS uses the standard too!? Its published, can't be closed back up, and interportable. If you don't want to use MS products, that's fine. That's great actually - I'm moving away from it too. But why is it bad if MS wants to support the standard too? It just makes it more quickly adopted so the rest of us can get more use of our standards implementations too. Might as well face it, standards are good and once they are set, MS has the same right as everyone else to use them.

  • There is an RFC on instant messaging, #753. It is very general, but a good starting point for Instant Messaging(and any offshoots) to grow. Also, the RFC is still in the development stage, so there's probably still a chance for improvement.

  • Re:The Silliest Part About It... (Score:3)

    by Surak ( 18578 ) <surak&mailblocks,com> on Saturday December 18, 1999 @05:57AM (#1463897) Homepage Journal
    I understand what you're saying but some things still don't make any sense:

    Why does AOL continue to maintain the TOC server? TOC is an ASCII-based protocol for interfacing to OSCAR, the "native" AIM server. TOC was created to interface to TiK, AOL's former TCL/TK based client meant to run on Linux as an alternative to the Java client. AOL no longer has TiK available for download and FWIU no longer maintains the client. Clients on TOC (such as gAIM [freshmeat.net] and TiK) don't display ads because they don't talk to OSCAR, which feeds them.

    AOL bought Mirabillis, and thus ICQ. I'm sure it wouldn't be difficult to add advertising to ICQ clients.

    Why was AOL interested in developing Linux-based AIM clients in the first place, considering that AOL's main interest is in gaining users to their online service? Note that there is no AOL client for Linux. Yes, TCL/TK and Java are platform-independent but the obvious uses are for Linux since Windoze users will use the native clients which are MUCH faster and require no external software (JDK or TCL/TK).


  • "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

  • IMHO I think that the AOL Instant Messenger interface is probably the most intuitive and easy to use. If anyone ever does make anything like this, it should use an interface similar to AIM, just without the advertisements =]
  • Zephyr is still in use here at Iowa State.

    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)

  • It is not that the host is not secure but that you just gave away valuable information to make a crackers job easier... The problem with security by obscurity is that most people walk in to situations were the previous admin didn't set the servers up this way. I would be glad to fix this problem except my customers wouldn't like me very much. And knowing the account name on any server is bad if you cann't guarantee the strength of every users password.. In my situtation I have users choosing weak passwords which would make craking them a breeze. (and don't counter with you should enforce password restrictions) I already know this. I just have to convince the people I work for that everyones password should look like this "1L9jn4?k" and not me "nutcracker"... Not an easy task when your job is only to run the severs and they get to make all of the final desicions. By allowing people(crackers) to know your usernames compromises your securtiy. Of course there is a non security issue here also... SPAM... Even by making e-mail and usernames different by fingering SPAMers could compile a file to spam your server and clients... The only way I can see finger as being a non security issue is if your server is behind a firewall... This reminds me of an important saying for system admins "If you don't NEED the service don't run it, every service you run decreases the security of your server"
  • Of course it won't. These projects are unifying protocols, not creating new ones.
  • Most people do not like using AOLIM or ICQ, buit to keep in touch with several people I know in real life and over the internet, this is one of the few ways to do it in real time, aside from using my other phone line or email. But a standard seems to be a long time away, as most companies (AOL) value are based on thier messaging/chat capabilities (oh come on, when was the last time someone used AOL for everything aside from IMs and chat.)
  • It's funny that someone of a "libertarian bent" would put such faith in a system of communication where political clout is allowed to coerce the choice of individuals. Remember that if ICQ is popular, it means that it is considered valuable by a large number of people. It may have shortcomings, but they who use it obviously think its advantages outweigh its disadvantages.

    No person can make value judgements for another. Congressmen can and should be able to pass laws to protect individual rights, but to pass laws specifying what IM is "best" and creating a government monopoly on IMs is as ridiculous as the government mandating a person's favorite color.
  • Crimminy. People like you, I don't understand. We're supposed to embrace new stuff, stuff that makes it easier and faster to communicate. IM's do that, if used properly. IRC is oldschool -- who has time to connect to a server (or even find one that doesn't say 'your connection class is full, please try again', etc etc, then find your buddies, who have different nicks because someone nick collided them, etc, finally just to ask them one quick question?

    Yeah, IMs are abused by lots of people ("Hey are you there?" "hey, did you get my email?" "hey, did you get my phone call", etc. etc.) but when used properly, they are a lot faster and more convenient than anything else! Yeah, there's room to improve (security, which is nonexistent in practically any IM today, and standards (althoug I only use ICQ, and everyone else I know only use ICQ)) but it's new, and they'll eventually get it going. Face it, IM is here, it's going to be around until it gets replaced with some sort of psychic mind melding, so get used to it!

  • In either case, I'm sure we'll see something that will unify our multiple unified IM proggies. And if it happens that these Unifying Unifiers need to be unified because of competition in the market place, SO BE IT! :)

    Feel free to contact me:

    ICQ 434551
    AIM 4132445
    YAHOOWHATEVER 578543858
    PHONE NUMBER 646-656-5353
    EMAIL 35235426_2346566576573543.3542355@compuserve.com
    RANDOMNUMBERS 535743845fd98fd54982399e
  • Trivial to autodetect and block.
  • 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.

  • Re:Tricky issue (Score:4)

    by Surak ( 18578 ) <surak&mailblocks,com> on Saturday December 18, 1999 @06:44AM (#1463922) Homepage Journal
    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.


    Somehow I suspect you're using the term "libertarian" in some sense that I am unfamiliar with. You espouse yourself as being "libertarian bent" out of one side of your mouth and out of the other you are asking the government to set a standard and run a server! Sounds like good ol' fashioned socialism to me...

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


    This actually sounds more plausible. An independent, third-party solution is definitely needed. Unfortunately, instant messaging is all about creating proprietary advantage in a world where there originally were none. If Jabber had been defined before the commercialization of the Internet, then everyone would adopt it. I think eventually, a standard will have to be adopted because people are just getting sick of having to have 4 or more clients running all the time.

    OTOH, look at streaming video and audio. We have a standard for that (MPEG) but it isn't being used. RealNetworks' and Microsoft's proprietary RealPlayer and NetShow clients currently rule the roost despite the fact that a viable standard exists. Again, the idea is to have a proprietary advantage in an environment where none should exist at all.


  • NP/IM as ISP service is the right thing (Score:4)

    by SurfsUp ( 11523 ) on Saturday December 18, 1999 @06:48AM (#1463923)
    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?
    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.
  • Is there a Win32 version of Everybuddy? I can't find a version anywhere on their web page. Interestingly, there is a choice to vote for a Mac version in their "Voting Booth" but no mention of Win32. Seems odd.
  • I looked a little closer at their Voting Booth and found:

    "as much as i hate to ask. what about win32.. some of us are forced to use it at the the still :( "

  • Re:NP/IM as ISP service is the right thing (Score:1)

    by Anonymous Coward
    Here's how you do it: talk somenick@someisp.net. Then you have Some ISP figure out whether you're connected right now, probably with a random new IP address. Then they simply do a TCP splice to rewrite to the right real address for the incoming commection. Simple. Sublime. Same with finger, etc.
  • Divide the project up like this..

    - A main program, whose purpose is to draw the IM windows and control the core function of the program.

    - Libraries consisting of protocol definitions and translations.

    - Libraries for the various features (chat, IMs, etc...)

    With this structure, The EU has to only create the account and download the needed libraries.

    Sound Good?
    Dijital

  • Now, ICQ already has many clones, just look at the horde available in Linux. It seems to me that if such clones are possible, it would be possible for MS to allow their messenger to integrate with the ICQ network. Of course, AOL is more likely to be able to stop MS that the upstart no-name people who write ICQ clones for Linux.

    Ashandare
  • It has been up to the end user to standardize clients. I use ICQ because my friends do, and I don't use AIM because my friends don't use AOL. They will have a hard time standardizing because messaging clients are by nature proprietary--they want to keep you using their client, much as portals try to keep you from going outside of their website.

    AOL probably won't merge AIM with ICQ, because AOL is still using IE even though they bought Netscape. Just because they own Netscape, doesn't mean they've merged it into AOL.

  • As somebody else suggested, another way to do this, a way using a higher protocol, is with an RBL-style DNS hack instead of an IP hack. You could finger @somenick.someisp.net and have their DNS reverse figure out where you really are. For some purposes, this would be preferred. For others, you want to hack IP so that talk somenick@someisp.net would work, too.

    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.

  • I have used Fire.app. It is very good (excellent on Mac OS X). If you have WebObjects installed, you can run it on Windows too.

  • Actually Tragic deals with this issue. It keeps a list of the last known class C that each party came from. It then sends out a query to all 255 addresses in each. Unless you are using one of the really big ISPs you will probably be right more then wrong. Even some of them will work this way due to geographical issues.

    Tragic could be extended to make this even more useful. Add an echo net like lookup feature. When it queries for a person, if it contacts a different tragic then they exchange some of their directory info. This way information passes around the net. You then search out via the new dir info and keep repeating the process until you find the person. A simple set of rules could maximize the search for a limited set of resources.

    The only issue that tragic doesn't deal with well is the naming. I think this could be done with a unique serial number and then aliases on top of it. Use the aliases, and then add part of the serial number as needed until it becomes unique.

    I've thought about extending it myself to get this functionality, but I don't have time to do it yet. If someone else does I'll definitly lend a hand.
  • Yup, thats exactly what I'm saying.

    This is the way Microsoft corners a niche. They give it away, and screw the competition. Its the same tactic they used to get Office on every PC (which I like Office, but its still the tactic), as well as IE. Hence the reason why Corel and Netscape are doing so poorly.

    I'm all for standards, but I know for a fact that if MS becomes a dominant player in the IM game, they'll use it to "break" other clients. They're attempting to do it with SMB filesharing right now, and they've tried doing it to SMB in tha past (remember the Win95 "feature" where it'd listen on some weird-ass port for certain responses instead of port 139??).

    Therefore, I'm against a standard in this case.

  • Jabber (or something similar) will skyrocket to success once it is implemented for many of the same reasons that ICQ did the same.

    • It is free
    • It is cool
    • It will work

    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.

  • Everybuddy will support all native file transfer stuff if it exists. The published protocol for AIM does not have file transfer.

    Everything we can support we will, we are not implementing our own chat protocol. I think the reason we did file transfer, is to give the ability to do so for those using aim and any other protocol which doesnt support file transfer, at least with other EB clients.

    If you want to discuss it further, please sign up for our mailing list, there is info on www.everybuddy.com [everybuddy.com]

  • In answer to some of Suraks's comments and some details...

    • The TOC servers support the QuickBuddy Java AIM client, which despite the "changes" early on in the MS-AOL war, is still a supported AOL product.
    • Unofficial history: The TiK client grew out of a need to test the TOC servers. It was a spare time project out of AOL's server development group.
    • AOL made a brief announcement a few weeks ago that we would see TiK 1.0 before the end of the year after not hearing much from them for about 6 months. Unfortunately, said announcement is no longer posted on the AOL servers.

    The TCL/TK client for AIM isn't dead, you can still get information/downloads from places like http://www.oaks.yoyodyne.com/tik [yoyodyne.com]. 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 [yoyodyne.com] based on TiK at this point.

  • Fixing dynamic IPs (Score:3)

    by Tom Christiansen ( 54829 ) <tchrist@perl.com> on Saturday December 18, 1999 @02:28PM (#1464026) Homepage
    3.Anyone have any idea how to fix the problem of dynamic IPs?
    Either with IP splicing as used for mobile IP and web performance, or else via RBL-style DNS games. Here's a suggested reading list.
    • Read Bill LeFebvre's article on Internet Black Holes [performancecomputing.com] to learn how the Real-Time Black Hole system uses DNS creatively. You can also go write to the source [vix.com] if you prefer. Here's an excerpt:
      The simplest way to get started using the MAPS RBL to protect your mail relay against theft of service by spammers is to arrange for it to make a DNS query (of a stylized name) whenever you receive an incoming mail message from a host whose spam status you do not know.
    • Here's the abstract for TCP Splicing for Application Layer Proxy Performance [umd.edu], by Pravin Bhagwat [umd.edu] et al.:
      Application layer proxies already play an important role in today's networks, serving as firewalls and HTTP caches -- and their role is being expanded to include encryption, compression, and mobility support services. Current application layer proxies suffer major performance penalties as they spend most of their time moving data back and forth between connections, context switching and crossing protection boundaries for each chunk of data they handle. We present a technique called TCP Splice that provides kernel support for data relaying operations which runs at near router speeds. In our lab testing, we find SOCKS firewalls using TCP Splice can sustain a data throughput twice that of normal firewalls, with an average packet forwarding latency 30 times less.
    • Here's the abstract for Improving HTTP Caching Proxy Performance with TCP Tap [umd.edu]:
      Application layer proxies are an extremely popular method for adding new services to existing network applications. They provide backwards compatibility, centralized administration, and the convenience of the application layer programming environment. Since proxies act as traffic concentrators, serving multiple clients at the same time, during peak load periods they often become performance bottlenecks. In this paper we present an extension of the TCP Splice technique called TCP Tap that promises to dramatically improve the performance of a HTTP caching proxy, just as TCP Splice doubled the throughput of an application layer firewall proxy.
    • Cohen, A. [bell-labs.com], S. Rangarajan, and H. Slye. On the Performance of TCP Splicing for URL-aware Redirection [bell-labs.com]. In: Proceedings of the USENIX Symposium on Internet Technologies and Systems, pp. 117-125, October 1999.
      Recently, the focus of the work on NEPPI applications was mostly on high performance URL-aware switching using TCP splicing. TCP splicing is a technique for bridging TCP connections at the IP level within the kernel, thus avoiding the overhead of application-level copying between sockets as performed by programs such as proxies. URL-aware switching with TCP splicing can be utilized in layer 7 switches to achieve high performance content-aware redirection of HTTP requests. We have developed of prototype of a layer 4/7 switch based on NEPPI.
    • A Mobile Networking System based on Internet Protocol(IP) [umd.edu] Pravin Bhagwat, Charles Perkins. Proceedings of USENIX Symposium on Mobile and Location Independent Computing, August, 1993, Cambridge, MA.
      Due to advances in wireless communication technology there is a growing demand for providing continuous network access to the users of portable computers, regardless of their location. Existing network protocols cannot meet this requirement since they were designed with the assumption of a static network topology where hosts do not change their location over time. Based on IP's Loose Source Route option, we have developed a scheme for providing transparent network access to mobile hosts. Our scheme is easy to implement, requires no changes to the existing set of hosts and routers, and achieves optimal routing in most cases. An outline of the proposed scheme is presented and a reference implementation is described.
    • A Mobile Host Protocol Supporting Route Optimization and Authentication [cmu.edu] 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
      Host mobility is becoming an important issue due to the recent proliferation of notebook and palmtop computers, the development of wireless network interfaces, and the growth in global internetworking. This paper describes the design and implementation of a mobile host protocol, called the Internet Mobile Host Protocol (IMHP), that is compatible with the TCP/IP protocol suite, and allows a mobile host to move around the Internet without changing its identity. In particular, IMHP provides host mobility over both the local and wide area, while remaining transparent to the user and to other hosts communicating with the mobile host. IMHP features route optimization and integrated authentication of all management packets. Route optimization allows a node to cache the location of a mobile host and to send future packets directly to that mobile host. By authenticating all management packets, IMHP guards against possible attacks on packet routing to mobile hosts, including the interception or ...
    • RFC 2230 [faqs.org] has some words that might be relevant here:
      Dial-Up Host Example

      This example outlines a possible use of KX records with mobile hosts that dial into the network via PPP and are dynamically assigned an IP address and domain-name at dial-in time.

      Consider the situation where each mobile node is dynamically assigned both a domain name and an IP address at the time that node dials into the network. Let the policy require that each mobile node act as its own Key Exchanger. In this case, it is important that dial-in nodes use addresses from one or more well known IP subnets or address pools dedicated to dial-in access. If that is true, then no KX record or other action is needed to ensure that each node will act as its own Key Exchanger because lack of a KX record indicates that the node is its own Key Exchanger.

      Consider the situation where the mobile node's domain name remains constant but its IP address changes. Let the policy require that each mobile node act as its own Key Exchanger. In this case, there might be operational problems when another node attempts to perform a secure reverse DNS lookup on the IP address to determine the corresponding domain name. The authenticated DNS binding (in the form of a PTR record) between the mobile node's currently assigned IP address and its permanent domain name will need to be securely updated each time the node is assigned a new IP address. There are no mechanisms for accomplishing this that are both IETF-standard and widely deployed as of the time this note was written. Use of Dynamic

      DNS Update without authentication is a significant security risk and hence is not recommended for this situation.

    Happy reading. :-)
  • Yeah, fuck advertising. Fuck Slashdot, Freshmeat, and every other site out there that relies on banners to make money. If they want to make money, they should go work at McDonald's! Greedy bastards!

    (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 [linuxsupportline.com].
  • Millions is old skool? Shite, mine is under 500,000.
  • 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.
  • 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.
  • ISTM most of the comments here have been to do with the standard ICQ client for windoze available from ICQ/Mirabilis directly.
    To make a suggestion, GnomeICU [gdev.net] is the best client I've seen - it spends most of its time being about 1cm square in the Gnome panel, with a light to show your status. If someone messages you, you get a flashing yellow post-it symbol. Does chat, does file xfer, does everything else you require in a proper chat client. Doesn't do birthdays. Doesn't sing (unless you enable sounds), doesn't dance. The contact list itself has an optional 'auto hide' feature, which is cool, too.
  • No, they came from IRC. We can only do terminal-to-terminal communications on the old Unix systems. IRC is a text relay between two client programs, not terminals. ICQ uses client programs, not terminals. Therin lies the difference.
  • 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.
  • But the Java client is still primarily aimed (no pun intended) at Unix and other platforms not supported by the AOL software.

    The TiK announcement is gone from AOLs servers probably for the same reason the software isn't present on AOL's servers anymore: they killed it.

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close