Posted by
ryuzaki0
on from the stuff-to-fart-around-with dept.
Jeremie writes
"Jabber is a new
project I recently started to create a complete open-source
platform for Instant Messaging with transparent communication
to other IM systems(ICQ, AIM, etc). Most of the initial
design and protocol work is done, as well as a working server
and a few test clients."
102 comments
EVERYTHING MUST BE FREE!!!
by
Anonymous Coward
·
· Score: 0
Eliminate Commercial Software! Great to see another Open Source project killing Corporate greed!!!
Too many protocols
by
Anonymous Coward
·
· Score: 0
Jabber wouldn't be the first attempt. Take a look through Freshmeat, for example. You'll find stuff like Teaser/Firecat and the Human Communication Protocol (as well as knock-off server clones).
It is just like all those game SDKs for Linux. Too many chiefs, and not enough indians.
Excellent!
by
Anonymous Coward
·
· Score: 0
I've always found that ICQ was slow poorly designed, and a highly insecure system. If you can defeat those, especially the security (encrypt everything!), I'd use it.
The other thing that I don't like about ICQ is those 25 million numbers, when only around 5 million people actually use it. I know I have a duplicate account myself, which I cannot delete (using their system), and the administrators won't delete it for me.
If you don't use it for 6 months, fry the account.
The client should also be able to create a new account without having to visit a web system first.
Sounds good... I've been using Licq for around 3 months now due to ICQ being so clumsy. (And limiting message size.. sheesh...)
why not IRC?
by
Anonymous Coward
·
· Score: 0
IRC is an open protocol and it works quite well. I never understood why we need things like ICQ or AIM when we already have IRC. Would someone enlighten me?
I use AIM & ICQ when I want to talk to certain people; these programs show when these people are online. These systems have a user authentication system so someone can't take someone else's nick like on most servers on IRC (servers like slashnet are an exception).
I use IRC when I have a quick question about something, and I can't find it in the manual. Then I'm really not interested in who I'm talking too, as long as I get an answer. Then I usually stick around to return the favor to someone else and answer their question.
I have though about doing something like an Instant Messanger system over IRC. Here's how it would work: the user client would send out a request to the client of each buddy, the buddy clients would sign it, using public key encryption, indicating that they are who they are. This would use DCC to the primary nick. If this is unsuccessful (like someone else happens to be using the same nick instead of the intended buddy), the backup would be communication via a certain channel. The main client would indicate that it has a certain buddy key, and the buddy client would respond returning the request and signature. Thus, the buddy client could change nicks (like the case when someone else is using that nick), but keep the public key, and people can still get a hold of the buddy.
I have two main problems with this: 1) I live in the US, and thus I wouldn't be able to do the public signature part. 2) This would create a lot of traffic on the designated backup channel, I don't think that the server ops would appreciate this.
Any thoughts/ideas?
Just what the pundit ordered
by
Anonymous Coward
·
· Score: 0
What the pundet never used Hotline? Rol in ICQ's/AIM's ability to find people online with hotline and you have somthing cool.
For an open sorce example see
and Ripcord.
Who says macintoshes don't inspire ideas... I heard another PC pundit longing for a laptop docing station (aka Duo doc)
Just what the pundit ordered
by
Anonymous Coward
·
· Score: 0
What the pundet never used Hotline? Rol in ICQ's/AIM's ability to find people online with hotline and you have somthing cool.
For an open sorce example see http://members.tripod.com/wasbeer/fancy_doc/READ ME.html
and Ripcord.
Who says macintoshes don't inspire ideas... I heard another PC pundit longing for a laptop docing station (aka Duo doc)
Zephyr???
by
Anonymous Coward
·
· Score: 0
So I don't think I've seen anyone mention MIT's Zephyr. I know I've seen the code at the Washington University St. Louis archives. It uses Kerberos for authentication, so I'm not sure how easily it could be scaled to the entire Internet. And not having plowed through the code, I don't know how easily you can plug in other communication protocols. But the code is there, so it might be interesting to take a look at.
why not IRC?
by
Anonymous Coward
·
· Score: 0
That's just the thing though - you don't need to be on (even on the network) (even with your machine off) to allow someone to message you. You'll get the message when you fire up your client. Unlike irc - if you're not on, tough luck.
Deleting ICQ Accounts
by
Anonymous Coward
·
· Score: 0
I don't know if the function is still there, but there used to be the capability to remove your accounts from their databases. It was still there when AOL bought them out, because I used it that night and wiped myself from their database. (Okay, I might be a LITTLE paranoid.)
Wow - all these projects
by
Anonymous Coward
·
· Score: 0
Zephyr, works exactly like this: zwrite user@realm
Zephyr requires keberos to be authenticated though. Gale is based on public key pairs. No passwords to remember, authentication and encryption are end-to-end. The servers just pass the data through to the clients that want it. It also does public chat as well as instant messaging.
Random pickiness
by
Anonymous Coward
·
· Score: 0
XML seems obvious enough to me... if you can find a way to plug Jabber's transport layer into a browser (Java somehow?), Jabber would not only be cross-platform, it would also have instant theme/skin support... and these skins wouldn't just be visual, they could be audio or print or...
nonsense
by
Anonymous Coward
·
· Score: 0
ktalkd is more convenient than AOL IM by orders of magnitude
Finger doesn't always work
by
Anonymous Coward
·
· Score: 0
For some reason, a lot of admins consider finger to be a security risk, and so they turn it off (at least for requests coming from outside the box).
ICQ - IH8U
by
Anonymous Coward
·
· Score: 0
However, most computer users are what you would probably consider illiterate. You can ignore them all you want, but he or she who makes a good program for the masses will gain much fame and commendation. I would guess the creators of these projects are are trying to make their programs as easy to use for the illiterate as possible.
Finger works fine -- unless the person you are looking for happens to be on a Windows box or another machine that isn't running a finger server, or a machine running a finger server but doesn't actually give any useful information (which seems to be the trend these days).
ytalk works fine -- assuming the person is on a machine with a talk client (and server? I can't remember). And (as you mentioned) is computer literate (or, more precisely, UNIX/command-line literate).
Instant messaging has its place, as do IRC, talk, etc. It is especially convenient for running in the background while doing other work. Instant messaging doesn't replace these programs...it fills a slightly different need.
"Stuff-To-Fart-Around-With Dept"
by
Anonymous Coward
·
· Score: 0
ah yes, slashdot, the web's most visible example of bathroom humour to date, except for www.spacemoose.com, of course.
and what is so "real-time" about this anyway? is there something in the spec *guaranteeing* the latency period? neither tcp or udp guarantee transmission times, or even arrival. hardly a "real time" messaging system.
File transfer?
by
Anonymous Coward
·
· Score: 0
Well, this looks cool except that i see that all communications go through a server, and there is no direct client-client communication. I'd like to be able to send files directly to someone i'm chatting with without going through a server. I hope they add this feature..
The *existing* open source messaging protocol
by
Anonymous Coward
·
· Score: 0
Zephyr relies on kerberos for authentication. No kerberos implies no authentication, and sniffing and forging are then both trivial.
Cross realm zephyr doesn't work very well either.
But for within one realm it works great.
a few things
by
Anonymous Coward
·
· Score: 0
This is not a very optimal solution to a big problem, namely the problem of determining presence.
What we really want is to be able to see:
1) Who is online
2) What protocols does he/she/it support
Everything else is superfluous and pointless. And so is Jabber since it's just yet another protocol with a mindless client->server->client type protocol.
Sure, I think there are parts of it where there has gone some real thinking into it, but it still is not what is actually needed.
a few things
by
Anonymous Coward
·
· Score: 0
This is not a very optimal solution to a big problem, namely the problem of determining presence. What we really want is to be able to see: 1) Who is online 2) What protocols does he/she/it support Everything else is superfluous and pointless. And so is Jabber since it's just yet another protocol with a mindless client->server->client type protocol.
Sure, I think there are parts of it where there has gone some real thinking into it, but it still is not what is actually needed.
XML?
by
Anonymous Coward
·
· Score: 0
Why was this based on XML?
Isn't XML a little verbose/bloated for a chat protocol?
I actually like ICQ's user names. For ordinary people (Mom, Dad, Grandpa Bill, etc.) they are much easier to relate than jbbriggs@server.ccd.corpnetwork.com. Who wants to spend 5 minutes spelling the damn thing three times over the phone long distance when you could just say "it's my name"?
Simpler is often better. When you do tech support over a phone all day you learn to appreciate it.
As for "one address for everything" what kind of a stupid idea is that? Sure, it's easier to remember (but if you're smart you've got a personal organizer to keep this kind of thing in already). I'd rather give my online identity information out on a "need to know" basis as much as is reasonably possible. Various user id's help to accomplish this.
An ideal solution would be a system with a "user id" that allows quite long strings and can include all the characters needed to present an e-mail address, web address or whatever. This would satisfy everybody.
tcp not udp
by
Anonymous Coward
·
· Score: 0
Perhaps this could be selected as a preference and stored at the server? I assume that all messages will be going through the server anyway, why not have the preference determine the protocol and port that the person wants to receive messages through?
Seems reasonable...
yes it does
by
Anonymous Coward
·
· Score: 0
When you register with a Jabber server, and want to use the ICQ transport, you will need to either tell it your existing ICQ # and password, OR let it create you a new one.
Then, your status is sent to the ICQ transport and relayed on to other ICQ users, as well as any 1234567@ICQ messages that you send or reply to. The ICQ transport uses your ID to handle all the communications for you.
Beyond the scope of the /. reader
by
Anonymous Coward
·
· Score: 0
First of all, let's get something straight about messaging in general, let alone this instant messaging bit; Message is a problem that has many more political and security issues than technical issues. Anybody can hack together a klugeish messageing system (witness ICQ/IRC/etc.). Making it fit in the big scheme of things is a hell of a lot harder (and that doesn't just mean hacking in a compatability back-end engine).
I tend to think of the the instant messageing projects as failures waiting to happen (primarily because the developers didn't see the forrest while building the trees). At best, they represent a handy way to install Back Orifice, at worst, they are a handy way to install Back Orifice.
Messageing should be an N-way authentication scheme between the user client, access mechanism (radius/dhcp/bootp/etc.), provider authentication (passwds/PAM/NIS(+)/MxSQL/TACCAS/etc.), directory service (LDAP/X.500/etc), certification authorities (USPS/Verisign/Microsoft/NSA/etc.) and distribution architecture (monolithic server/distributed server/boradcast/client to client/etc. That's the kind of key distribution problem that the NSA is STILL working on today. I consider the problem NP incomplete due to the human factor of trust (which really isn't matmatically quantifiable anyway).
Now, with all that said, whatever tinkertoy people build in the meantime had better be compatable with MicroSoft's comming bloated directory service, because there's this little thing called market share that drives the amount of stone that programmers must chissle when solving that N-Way authentication problem... and you can count on the fact that MicroSoft will have their own messaging standard that becomes the tool to replace ICQ/AIM/whatever. I wish AOL luck in the software creation industory; however, I think that are vastly mistaken in their effort to compete with MicroSoft, let alone the OSS community.
a few things - interoperability
by
Anonymous Coward
·
· Score: 0
This is not the whatchamacallit - the thingy.
It doesn't matter if Jabber is designed to work with many other protocols, it still doesn't have a viable, scalable solution for determining presence, nor does it have any support for querying of the remote entity. It's simply YAP.
yes it does
by
Anonymous Coward
·
· Score: 0
Listen, I don't care much about people who use ICQ or AIM, I'm a lot more interested in the future of presence determination and what might be possible then. Jabber is simply something that ties two or three pointless protocols together, it doesn't do much to solve the underlying problem.
XML?
by
Anonymous Coward
·
· Score: 0
Haven't checked it out much, but it seems to me that just using xx, and maybe a little nesting, is a long way to what XML is about.
I could be wrong (that happens sometimes).
Real-time?
by
Anonymous Coward
·
· Score: 0
What's Real-time about it?
Anonymous Coward
why not IRC?
by
Anonymous Coward
·
· Score: 0
I hate being anal like this, but we always hated channels being referred to as "rooms". "chat rooms" was an AOL invention or at least used most notoriously by them...
XML?
by
Anonymous Coward
·
· Score: 0
XML has to be one of the most over-hyped technologies. You can make up your own tags - BFD.
BuddyList and other Presence Indicators
by
Anonymous Coward
·
· Score: 0
A lot of us may dislike AOL for political reasons, but they are technically impressive. The client runs on some of the crappiest hardware imaginable.
As for the server side, think of the scalibility problems they must encounter... it's an amazing feat, really!
I looked at his resume and was very impressed - 15000+ TPS sustained on what was probably a high-end HP workstation is *very* nice.
Comparison of Protocols
by
Anonymous Coward
·
· Score: 0
ICQ - depends on Central Authority to maintain database, can't be used on disconnected Intranets.
Zephyr (from MIT) - Based on kerberos. Real hard to setup server.
Talk/write - Requires knowing where someone is, doesn't work behind firewalls. No notification.
Gale (gale.org) - More like IRC than ICQ because all servers talk to eachother. - Central server logs all messages, public and private (Yikes!)
Just my.02
why not IRC?
by
Anonymous Coward
·
· Score: 0
here's why not: file transfers. DCC is really screwed up. ICQ is right now the only easy way to transfer files between two people who don't happen to have the stuff to set their computers up as FTP or HTTP or hotline servers. which is very sad, because ICQ sucks ass.
XML?
by
Anonymous Coward
·
· Score: 0
Just because the "other chat communication protocols" use something similar to XML, dosn't nesicarily make it a good idea. If a lot of clients are going to be using this technology, it should be as secure and efficent (compact) as possible. I just don't see why XML is a good idea simply because "it's easy to use", when the only people who need to really 'use' it are the programmers. And I (personally) would rather have to deal with a slightly more complex protocol during development, rather than having an extremly 'chatty' protocol. (pun intended;)
I really don't like the idea of a corporate company taking care of my server acces. A government a little less, but certainly not the US goverment (way too big and fscked up). And then again, smart cards aren't a real good solution, they always want statistics, and I find that very dangerous.
So rock-on for cookies, 4000 different passwords, and may I be the only one to grant myself access:]
> If you need to see whether a person you are > looking for is currently online, or not, you > use finger. If you need "Instant Messaging", > there's always ytalk. Chat? IRC, and so on...
So you're saying I have to always be telnetted into my server, and paying attention to my telnet session to talk to people? Or do I have to make people go to my web site to get my IP, and maybe I'm booted into Linux to answer them, and maybe they have a talk client... and...
The nice thing about instant messaging is just that. Instant messaging. As a program, ICQ is pretty much a piece of crap, but it has the advantage that a LOT of people use it. You can be fairly sure to get ahold of friends online. Even when your webpage changes, your email address changes, whatever, you always have that "ICQ number", and people can get ahold of you.
Maybe someday we can "convert" all those ICQ users over to something that works better, but most people are content where they are. Until then, I'll have to live with ICQ when I want to get ahold of my friend from another state easily...
I've put great thought into these also, and the Privacy part is going to be addressed via different built in "privacy" levels in the server. One of them will be absolutely invisible, the only way someone would know you existed is if you sent them a message, and then they could only reply...
The security I'm leaving for version 2, but I'm making sure not to do anything to get in the way of it. Using something like PGP could already be used in the existing architecture, but would have to be supported by the client.
I also use talk, finger, etc... and you can count on Jabber working 100% WITH those utilities(if the Jabber server administrator installs translators for those services), and also have alias Jabber functions like jtalk, jwrite, jfinger that work identically but go directly to the jabber server instead of through a translator.
I live on the CLI, but many/most of my friends do not, and I want to be able to talk to them... hence Jabber:)
1) The links in the Users section going to the overview was an accident, although the overview is really the only data there and yes, way overqualified for most users. It will be "nicer" after a public stable release.
2) File transfer or anything dealing with big binary chunks isn't going to be part of the main protocol. My current plan is to impliment all of those activities through HTTP/1.1 and WebDAV which is perfectly suited for that application, and just send the startup/location information through Jabber.
3) Not sure totally what you mean... thinking...
4) Because tools for manipulating/processing XML are quickly becoming standard and available. Secondly, XML is just a wonderful way to wrap up data, and it's text, easy to deal with in any situation.
5) Mirabilis uses UDP because ICQ is central-server based, and there is no way that their servers could possibly support a few million TCP connections. Jabber has no central server, so doesn't have that restriction, although very busy Jabber servers will have to deal with some problems because of TCP also, but there are ways of fixing it.
I'll be honest, I'm not a big IRC user, although I admire the architecture.
I was thinking, though, that a Jabber transport could be used to create seamless communication with IRC users, and vice versa. The Jabber users wouldn't really live in a room or be able to participate in the rooms(use a real IRC client for that) but could send IRC users messages like "user id@EFnet" and the Jabber IRC transport would do the translation.
The Jabber server is ready, if someone familiar with the IRC protocol wants to code this:)
I agree 1000% and this is exactly why I did Jabber. It may also be just another IM client/server system, but it is more. It was _designed_ to be interoperable with all other instant messaging systems from the start, so if you are using a Jabber client, you can talk to anyone else on any other system, and they can talk to you.
Within a short period of time(months), I expect Jabber to reach the "near-universal" interoperability.
Jabber is under the GPL at this point, but if need be, I'm willing to put it under another license to make it compatable.
Besides, Mozilla would only need a client, and clients are quite easy to write.
Jer
Server side + HTTP/1.1 + WebDAV
by
jeremie
·
· Score: 1
Yes, I'm planning on server file transfers through the server, probably using HTTP(specifically the WebDAV extensions) and letting Jabber communicate the locations/passwords for the files.
The files don't even need to be stored on the server, it can be a socket-to-socket copy in a server process, but storing them might be a usefull option, especially for broken downloads and group sends.
It does determine who is online, providing instant status updates.
And as far as protocols, it doesn't need to show what they are using(although it can), because anything you send to them via Jabber will be translated on the fly to whatever protocol they are using if they are not Jabber users themselves.
Yes, everything else is superfluous, that is why Jabber is what it is, exactly what you state(plus the superfluous stuff too:)
Man, I wish people would just use email addreses for usernames. I mean, who in their right mind wants to remember a 15 char username (what AOL IM makes you use since they have 10 million other people taking anything remotely good), or the massively long number ICQ makes you use.
It's silly, everyone has an email address... Use it. I mean, one address for everything, email, chat, etc... sure would be nice.
-- The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
That's what Q is for: http://www.qdirectory.com
by
torpor
·
· Score: 1
One global ID for everything. Combination of letters/numbers. Why hasn't it caught on among the hacker community - too corporate?
http://www.qdirectory.com
(Torpor Q = 8008)
-- ; -- the corruption of government starts with its secrets. a truly free people keep no secrets.
--
The *existing* open source messaging protocol
by
Brandon+S.+Allbery
·
· Score: 1
It even has authentication. And it has ways to reduce network load.
It's called Zephyr. And it's widely used at a number of universities. The code is freely available, there are even prebuilt RPMs (minus Kerberos authentication support) on RHCN.
Why invent yet another protocol when we already have one?
IRC could do instant messaging...
by
Peter+Amstutz
·
· Score: 1
If someone wrote an IRC client based around watching notifies and sending private messages instead of channels, one could just as easily do the same stuff and more that ICQ does with IRC. IRC is a more mature protocol, more widely used, and isn't proprietary like ICQ. The technology has been around for quite a while, the only difference is that Mirabilis came up with a new user interface that is less intrusive than the average IRC client. Someone want to do this with IRC?
IRC is based around the concept of rooms. You can only talk to other users inside that room, and all messages are public (by default) to the room.
Actually that isn't true. When sending a message over IRC, the command to send to a specific user and to send to a channel are exactly the same. There is no "default" message destination, channels merely exist to facilitate one-to-many and many-to-many communication, as opposed to one-to-one communication, as ICQ does.
A system like ICQ is based around the concept of lists of people. You can send messages to anyone on your list, and the messages and generally private to that person. Its restricted by its generally centralized and proprietary architecture and protocols.
The "lists of people" concept in ICQ is entirely client side, and can be done in IRC using NOTIFYs. Client-to-client stuff is handled using CTCP and DCC (Client-To-Client-Protocol and Direct-Client-to-Client respectively).
What IRC lacks is encrypted communications and established user accounts - at the moment, relatively little data is saved about users, and their nick can often change hands easily, allowing people to pretend to be or me mistaken for others... This is one of the few advantages of the centralization of ICQ and AIM.
You can do the exact same thing with IRC. Just get on an IRC server and don't join any channels. If your friends want to contact you, they can/msg you, just like with ICQ or AIM.
Anyway, the more like a BBS it is, the better. FidoNet is *still* the best messaging system, a LOT better than UseNet, webboards, or mailing lists.
IRC has too much baggage to be used like ICQ
by
Trepidity
·
· Score: 1
What baggage? IRC is a quite simple, well-documented protocol. Everything is in plaintext, and all the commands have numbers assigned to them so a client can just look at the numbers and know what's happening. Hell you can write IRC bots inside of mIRC's pathetic scripting language, so it can't be that hard to write an IRC client that acts like ICQ. All you need to do is take away the ability to/join a #channel and just use/msg instead, and you've got ICQ.
And IRC is definitely much more firewall friendly than ICQ. ICQ uses tons of different ports, while IRC uses one - 6667. Most clients can even go through a SOCKS firewall if you wish.
Actually, user-to-user messages on ICQ are TCP sometimes. If it fails to send through TCP directly to the user, and you click on "send through server," then it'll send through the server using UDP.
I really hope this one will go through a pretty secure firewall. Most people have tcp access to port 80/21, unless they are hooked to a proxy. If they can pipe realaudio through port80, then this should be easy.
-- Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
It looks as if Jabber's main strength is in any-to-any messageing. Frankly, if they develop an addressing scheme that allows me to send a message to just about anyone, on any protocol (up to and including email) then Jabber is the client I'll use.
And as people realise "Well, with my ICQ program, I can message other ICQ users, but this guy can use Jabber to message AIM, ICQ, Mail, IETF, etc", one protocol will emerge the victor. Think about how many protocols your email (sometimes) goes through. Do you care? No, because gateways make it invisible.
There's a few ways to look at this. The first is to compare messages with SMTP mail. Where's the security and authentication in SMTP? Almost none. Do you care? Maybe, but if so you either use PGP to encrypt it, or perhaps you build your own mail network using something like (eek!) Notes, and if you really must go over the 'net, use a VPN. Most people tolerate the insecurities of SMTP and get on with it, without Back Orifice ever getting installed on their machines;)
Then there's instant messaging. One comparisom I've heard (thanks Nemo) is "ICQ is like passing notes in class". It's not quite chat, it's not quite mail, but for the most part, you take your chances, and if the teacher nabs the note and reads it, well tough. Again, if you care, you can use PGP, to build a secure messaging system atop the insecure one -- just as TCP is a reliable network protocol built atop IP's *un*reliable network protocol.
I'll agree that the protocol implementation and the UI should be kept seperate. But I'd go further. The UNIX way is to have a small command line program which does the job then exits. cicq is supposedly working towards this:
$ echo "You there?" | cicq -send slim
... a gui should be a wrapper around programs such as these. A "universal" messaging system would also be a wrapper around more specialised programs. i.e. messagesend -send icq:slim would spawn cicq -send slim
It's the UNIX way. And it's good. Let's not forget it just because some of us feel we're competing against Windows.
It works, it scales (somewhat), it supports real authentication, it's open, it presents the right paradigm for instant messaging and online discussion. (Since I used it heavily at CMU, using AOL Instant Messenger, IRC, and ICQ is just painful.)
There's an effort underway by the IETF to come up with a standard protocol for instant messaging and "presence information" called IMPP. Anyone considering working on a project like this should get in the loop so they can make sure all their bases are covered, and so that they can interoperate with others' servers.
Shared Server-side UINs are privacy risk...
by
kirk_bb
·
· Score: 1
Unless you REALLY trust the people who are managing your UIN/Username/etc on the server, you don't WAN'T them to share everything between themselves. Besides, in Europe, it's illegal for them to do so.
A far better notion is to have all that information available to YOU, and YOU decide what to share with them. However, this technology (like a digital wallet) has been around for a really long time in web-world and has been abandoned for now, mostly because people don't want to administer them. You move computers, you have to move the thing. Floppies suck, smart cards aren't everywhere.
Now once GSM with PID smart-cards come to the US and I can use one card for credit, ATM, computer security and phone.... yum.... pervasive technology with privacy rights...
UINs, ID's, Usernames, Etc
by
GrenDel+Fuego
·
· Score: 1
Some web sites do use a centralised user database.
You create an account on this one site.. and when you want to access any of the sites that support it, it just authenticats you off the first site's server.
It's called adultcheck:)
I read somewhere a lot of advances in technology, including eCommerce, have been greatly helped along by the Adult entertainment industry.. I'm begining to believe it.
I'm not sure about anyone else, but I've been using various versions of AIM (even beta) on my Mac and have never had any stability problems with it (the client). The only real problems that I've had have been server side, and even those are minimal and most likely due to the fact that AOL happens to serve millions of people and any line can only take so much.
Say what you want about certain members of AOL's clientele. Whine about it being an evil, greedy corportation. It's hard to deny that what AOL is doing technically is pretty darn impressive.
+ All the links in the "Users" column go to the Overview, which claims it's for users but quickly bangs on about distributed servers, XML protocols and other techie stuff.
+ XML sounds very nice for simple messages, but how does it deal with live chat and file transfer?
+ The XML tags and attributes could do with being a bit more apt to the data. (e.g. "jenny" would be better put as "jenny" - at least, that's how it appears)
+ Come to think of it, why use XML rather than something a bit leaner? I wouldn't have thought that the client-server communications had to be human-readable, especially since it sounds like the only things Jabber clients will be talking to are Jabber servers.
+ Do you know why Mirabilis chose UDP for the ICQ transport?
+ Running a spellchecker on your site wouldn't hurt, either...
Otherwise, very nice, very commendable, good luck with it, etc. etc...
Okay, I'm getting annoyed now. I'm trying to use lt and gt entities so that y'all can see the XML tags I'm talking about and I DID hit Preview and they DID show up and I hit Submit and now they're not there.
Pants.
I'm going to have one more go at this and if it doesn't work you'll just have to view source to get what I'm talking about.
+ The XML tags and attributes could do with being a bit more apt to the data. (e.g. "<group name='main'>jenny</group>" would be better put as "<user name='main'>jenny</user>" - at least, that's how it appears)
NOW WORK, YOU BASTARD!
Why you might want something likeJabber in Mozilla
by
yoz
·
· Score: 1
Take a look at jwz's posting on the subject in Mozilla.org's "Blue Sky" section.
I've looked at alot of ICQish projects around, but Jabber looks like it has some great potential. I especialy like the idea of transports and having an XML based protocol. I added myself to the update list hope it catches on.
Don't start a new protocol. The IETF wants instant messaging to be global and standardized; the last thing we need is another duplication of effort. Work with the IETF and end up with something standard.
Oh and by the way... KDE sucks.
-- Tired of FB/Google censorship? Visit UNCENSORED!
What's the point of creating an "open" protocol, when AOL has already opened theirs? ICQ, of course is totally stupid, lagged, and insecure. I was glad to hear that AOL bought them out...maybe it will add some of the AOL stability to it.
Give me one good reason why you think AOL is unstable (don't forget to take into consideration the fact that they have experienced growth of tremendous levels, and will inevitably experience some growing pains).
IRC does different things. The most important point about ICQ is (a) you can see who of your contacts is available (b) you can initiate a conversation without pre-arranging it, like with a phone, since the reciever app is omnipresent.
This all comes about because Unix never got instant messaging, rmsg getting sucked into irc.
It'd be nice if we could get a standard so you could do
rwrite username@full.host.and.domain.net "Hi there, how's it going?"
BuddyList and other Presence Indicators
by
sdw
·
· Score: 1
I wrote the first BuddyList server for AOL several years ago. (see my resume at http://sdw.st).
I've been watching the evolution of Presence Indicators with a lot of interest, of course, and I like some of the decisions so far here. I have some ideas that I'm thinking of persuing on my own that I may be able to share with everyone soon.
(Don't ask me about AOL internals because obviously I have a strictly professional and ethical obligation to uphold non-disclosure contracts.)
sdw
-- Stephen D. Williams
BuddyList and other Presence Indicators
by
sdw
·
· Score: 1
I know from past experience that too many hacker wannabees think that stealing accounts or bumping people or other pranks is cool rather than learning to program, which IS cool. Of course/./* is well into the latter category and didn't need the pre-emptive warning. Unfortunately my oldest son falls into the former category for the moment, sadly.
If you would have looked at the resume, you would have seen at least one huge addition to instant messaging that I came up with, architected and designed, skunk-worked, managed as an early project, implemented, had 25000 beta users, and ultimately watched die because of abuse fears...
sdw
-- Stephen D. Williams
Security/Privacy (Great Idea)
by
Gary+Franczyk
·
· Score: 1
You could easily make it totally transparent to the end user that you were using PGP. Just make it a check box in the configuration and have a simple check to see if it is installed and working properly.
I admire the attempt. Unlike the above-anonymous cowards...
It would be nice to make a client that could do AIM, ICQ, dynamic DNS, etc. Put that in a 32x32 icon and stick it in wharf, and you got one kick-ass project.
Keep up the good work...
g'luck
--
numbers, numbers everywhere!
by
chialea
·
· Score: 1
well, it might be so that they don't have the same problem that AOLIM does -- I have 3 "Dave"s on my list, and it's still fine. also, very easy to change your username.
yes, I'll agree that that number is a pain in the butt, and only my techie friends know it off the top of their heads, but it has its points.
you can search for the nickname, or just about any other piece of info -- it's just not the PRIMARY means of identification to the server.
better than a letter! less costly than a call!
by
chialea
·
· Score: 1
and who can beat being able to have your TA's, and even some professors online, easily botherable? no one. that's the problem.
and as long as I'm stuck with this windoze box (no, I do not feel like writing my own ethernet card drivers, thank you) I'm stuck with ICQ. most people don't use finger, and if you are using dynamic IP (love that MSN when I'm at home!) it's kinda interesting trying to finger someone, even if they are running finger (as I am).
so, I guess if someone wants to see if I'm online, they'd better call me first to see what my IP is.
That's a nice thought, but in pratice, ick. If you do that, then the userdirectory becomes a spammer's paradise: a quick, queryable database of email addresses matched to real names. Ick! Ick! Ick!
This of course will eventually be the Right Way to do it, once cerificate-signed email becomes the norm and any and all email without at least a Class-2 caliber cert behind it gets discarded.
Besides, if you have a well designed DTD for chatty stuff, there really wont be that much overhead, and an XML based system gives people the ability to design almost entirely new realtime communication applications ontop of the original code without writing anything but a new doctype.
Beyond the scope of the /. reader
by
reaper
·
· Score: 1
Well, for UNIX, there is a program called mxx, that does public key signatures, and encryption of messages. It works between systems running the server.
No reason it couldn't be extended slightly to work on Windows machines, handle a directory lookup, etc...
Note that the author is avoiding touching the code anymore.
I've been following many of the instant messaging projects that are around, but I don't know which one to try.
I want the one that is closest to ICQ, has a good Windows client, and is fairly mature.
As a little side note, I think Teaser and Firecat is an important project in this field, mainly becuase it does not attempt to emulate ICQ and therefore is more secure. But we need something that is like ICQ, just because Windows users are more at home with it.
Good idea, right direction
by
adamsch1
·
· Score: 1
I used to work at a company that lets say puts out web browsers and I tried to push them to do this, but they ignored me time and time again.
O well. If an open source movement picks up in this area we might see some cools things happen. An ideal goal would be to get a windows version up and running so that smaller ISP's can snatch it and possibly force more commercial ISP's to adopt the technology. Then agin AOL paid alot of money for ICQ and would be rather against this I imagine.
UINs, ID's, Usernames, Etc
by
adamsch1
·
· Score: 1
This brings up another issue I'd like to see resolved. I hate having to create new user accounts on all of these web sites. I'd like one user account so that if I come across a site I'd like to take a look at, I just type in my "universial" username and password and I get instant access.
As an example, I went to TV guide to see local listings of Nerds 2.01, but they wanted me to create a new user account. So I walked away never to return. More and more sites are doing this and it's extremely aggravating, it takes time, and I bet you they are losing customers because of this policy.
Just what the pundit ordered
by
Agathos
·
· Score: 1
In one of those countless "predictions for the coming year" articles the columnists like to write in late December/early January, PC Week's Rob O'Regan says we'll see a new killer Internet app which will combine instant messaging with "document sharing and other real-time collaboration."
Sounds like a cool idea to me. I'm far from an expert, but I wonder if Jabber's XML-based protocol and the open source model in general will make it possible to turn it into this kind of app. If so, it looks like a great chance to show the world (once again) what open source can do!
nickserv and all of the other *serv 'bots' don't exist on all IRC networks. For that matter, I've only seen them on dalnet, and when you've got 450 people in #chatzone at once, i can see why it might be neccessary. I don't see any *serv on efnet or undernet. So it's not necessarily true that IRC provides the same features as ICQ or AIM, even if you just sit on the server without joining a channel or anything.
Hm, and perhaps I should get offline at home once in a while... it's been online since i last restarted it, a little more than a week ago:o)
--
Dogma: Dead (mostly because your Karma ran it over)
TOO MANY of these projects!
by
Stiletto
·
· Score: 1
The person who said "There are too many chiefs and not enough indians" is TOTALLY correct. A quick search on freshmeat returns fifteen of these "instant message" projects under development right now that all do pretty much the same things.
To the programmers working on these projects: It's noble that you are committing your time to cool and open projects like this, but don't you think you could get more done if you all worked together rather than seperately?
An even more disturbing thing I have noticed about these projects is the fact that many of them are being developed under the Windoze paradigm where the interface is closely tied to the implementation, rather than the unix model where the interface, implementation, and underlying libs are seperate components.
For instance, download a few of these projects and check them out. All of them include their own implementation of the ICQ protocol. People, the ICQ protocol is the same regardless of whether you are using Qt or GTK! Why can't we develop a libicq and a libaim THAT EVERYONE AGREES ON? This way the protocol and the interface can be worked on in parallel by different teams!
just create something that works through a firewall. AOL-IM works fine but ICQ dosen't even get close to working through my firewall, all their firewall config doesn't do a thing!
IRC is a chat protocol. ICQ and AIM are instant messaging protocols. While similar in purpose, they differ greatly in organization.
IRC is based around the concept of rooms. You can only talk to other users inside that room, and all messages are public (by default) to the room. The IRC protocol works very well, although its restricted by its ASCII-based interface.
A system like ICQ is based around the concept of lists of people. You can send messages to anyone on your list, and the messages and generally private to that person. Its restricted by its generally centralized and proprietary architecture and protocols.
ICQ and AIM may do chat too now (I've only used an old ICQ client), but their specialty is one to one communication. IRC's specialty is group-based communication. Both have their own own advantages, and a good general-purpose realtime messaging system should incorporate both schemes.
I still don't see the need for "Instant Messaging"-software.
If you need to see whether a person you are looking for is currently online, or not, you use finger. If you need "Instant Messaging", there's always ytalk. Chat? IRC, and so on...
"Instant Messaging" is just a way of re-inventing the wheel for the computer illiterate.
security/encryption/PGP and the good ole gov't
by
McFLY
·
· Score: 1
I'm all for the security aspect as well. One issue you should keep in mind is the export restrictions placed on many types of security measures. It seems to me that you'd like to keep your software available to all types of users, world-wide.
IRC uses more bandwidth (unless you're just idling, but then it probably still uses more), and anybody can/whois you and try to hack you. With ICQ only the people on your list can get your IP address, and only if you're visible to them.
Slashdot Mirror
Eliminate Commercial Software! Great to see another Open Source project killing Corporate greed!!!
Jabber wouldn't be the first attempt. Take a look through Freshmeat, for example. You'll find stuff like Teaser/Firecat and the Human Communication Protocol (as well as knock-off server clones).
It is just like all those game SDKs for Linux. Too many chiefs, and not enough indians.
I've always found that ICQ was slow poorly designed, and a highly insecure system. If you can defeat those, especially the security (encrypt everything!), I'd use it.
The other thing that I don't like about ICQ is those 25 million numbers, when only around 5 million people actually use it. I know I have a duplicate account myself, which I cannot delete (using their system), and the administrators won't delete it for me.
If you don't use it for 6 months, fry the account.
The client should also be able to create a new account without having to visit a web system first.
Sounds good... I've been using Licq for around 3 months now due to ICQ being so clumsy. (And limiting message size.. sheesh...)
IRC is an open protocol and it works quite well. I never understood why we need things like ICQ or AIM when we already have IRC. Would someone enlighten me?
What the pundet never used Hotline? Rol in ICQ's/AIM's ability to find people online with hotline and you have somthing cool.
For an open sorce example see
and Ripcord.
Who says macintoshes don't inspire ideas... I heard another PC pundit longing for a laptop docing station (aka Duo doc)
What the pundet never used Hotline? Rol in ICQ's/AIM's ability to find people online with hotline and you have somthing cool.
D ME.html
For an open sorce example see
http://members.tripod.com/wasbeer/fancy_doc/REA
and Ripcord.
Who says macintoshes don't inspire ideas... I heard another PC pundit longing for a laptop docing station (aka Duo doc)
So I don't think I've seen anyone mention MIT's Zephyr. I know I've seen the code at the Washington University St. Louis archives. It uses Kerberos for authentication, so I'm not sure how easily it could be scaled to the entire Internet. And not having plowed through the code, I don't know how easily you can plug in other communication protocols. But the code is there, so it might be interesting to take a look at.
That's just the thing though - you don't need to be on (even on the network) (even with your machine off) to allow someone to message you. You'll get the message when you fire up your client. Unlike irc - if you're not on, tough luck.
I don't know if the function is still there, but there used to be the capability to remove your accounts from their databases. It was still there when AOL bought them out, because I used it that night and wiped myself from their database. (Okay, I might be a LITTLE paranoid.)
So does gale: gsend user@domain
Zephyr requires keberos to be authenticated though. Gale is based on public key pairs. No passwords to remember, authentication and encryption are end-to-end. The servers just pass the data through to the clients that want it. It also does public chat as well as instant messaging.
XML seems obvious enough to me... if you can find a way to plug Jabber's transport layer into a browser (Java somehow?), Jabber would not only be cross-platform, it would also have instant theme/skin support... and these skins wouldn't just be visual, they could be audio or print or...
ktalkd is more convenient than AOL IM by orders of magnitude
For some reason, a lot of admins consider finger to be a security risk, and so they turn it off (at least for requests coming from outside the box).
However, most computer users are what you would probably consider illiterate. You can ignore them all you want, but he or she who makes a good program for the masses will gain much fame and commendation. I would guess the creators of these projects are are trying to make their programs as easy to use for the illiterate as possible.
Ben
biy@andrew.cmu.edu
ah yes, slashdot, the web's most visible example of bathroom humour to date, except for www.spacemoose.com, of course.
and what is so "real-time" about this anyway? is there something in the spec *guaranteeing* the latency period? neither tcp or udp guarantee transmission times, or even arrival. hardly a "real time" messaging system.
Well, this looks cool except that i see that all communications go through a server, and there is no direct client-client communication. I'd like to be able to send files directly to someone i'm chatting with without going through a server. I hope they add this feature..
Zephyr relies on kerberos for authentication.
No kerberos implies no authentication, and sniffing
and forging are then both trivial.
Cross realm zephyr doesn't work very well either.
But for within one realm it works great.
What we really want is to be able to see:
1) Who is online
2) What protocols does he/she/it support
Everything else is superfluous and pointless. And so is Jabber since it's just yet another protocol with a mindless client->server->client type protocol.
Sure, I think there are parts of it where there has gone some real thinking into it, but it still is not what is actually needed.
What we really want is to be able to see:
1) Who is online
2) What protocols does he/she/it support
Everything else is superfluous and pointless. And so is Jabber since it's just yet another protocol with a mindless client->server->client type protocol.
Sure, I think there are parts of it where there has gone some real thinking into it, but it still is not what is actually needed.
Why was this based on XML?
Isn't XML a little verbose/bloated for a chat protocol?
it's unstable, very
I actually like ICQ's user names. For ordinary people (Mom, Dad, Grandpa Bill, etc.) they are much easier to relate than jbbriggs@server.ccd.corpnetwork.com. Who wants to spend 5 minutes spelling the damn thing three times over the phone long distance when you could just say "it's my name"?
Simpler is often better. When you do tech support over a phone all day you learn to appreciate it.
As for "one address for everything" what kind of a stupid idea is that? Sure, it's easier to remember (but if you're smart you've got a personal organizer to keep this kind of thing in already). I'd rather give my online identity information out on a "need to know" basis as much as is reasonably possible. Various user id's help to accomplish this.
An ideal solution would be a system with a "user id" that allows quite long strings and can include all the characters needed to present an e-mail address, web address or whatever. This would satisfy everybody.
Perhaps this could be selected as a preference and stored at the server? I assume that all messages will be going through the server anyway, why not have the preference determine the protocol and port that the person wants to receive messages through?
Seems reasonable...
When you register with a Jabber server, and want to use the ICQ transport, you will need to either tell it your existing ICQ # and password, OR let it create you a new one.
Then, your status is sent to the ICQ transport and relayed on to other ICQ users, as well as any 1234567@ICQ messages that you send or reply to. The ICQ transport uses your ID to handle all the communications for you.
First of all, let's get something straight about messaging in general, let alone this instant messaging bit; Message is a problem that has many more political and security issues than technical issues. Anybody can hack together a klugeish messageing system (witness ICQ/IRC/etc.). Making it fit in the big scheme of things is a hell of a lot harder (and that doesn't just mean hacking in a compatability back-end engine).
I tend to think of the the instant messageing projects as failures waiting to happen (primarily because the developers didn't see the forrest while building the trees). At best, they represent a handy way to install Back Orifice, at worst, they are a handy way to install Back Orifice.
Messageing should be an N-way authentication scheme between the user client, access mechanism (radius/dhcp/bootp/etc.), provider authentication (passwds/PAM/NIS(+)/MxSQL/TACCAS/etc.), directory service (LDAP/X.500/etc), certification authorities (USPS/Verisign/Microsoft/NSA/etc.) and distribution architecture (monolithic server/distributed server/boradcast/client to client/etc. That's the kind of key distribution problem that the NSA is STILL working on today. I consider the problem NP incomplete due to the human factor of trust (which really isn't matmatically quantifiable anyway).
Now, with all that said, whatever tinkertoy people build in the meantime had better be compatable with MicroSoft's comming bloated directory service, because there's this little thing called market share that drives the amount of stone that programmers must chissle when solving that N-Way authentication problem... and you can count on the fact that MicroSoft will have their own messaging standard that becomes the tool to replace ICQ/AIM/whatever. I wish AOL luck in the software creation industory; however, I think that are vastly mistaken in their effort to compete with MicroSoft, let alone the OSS community.
This is not the whatchamacallit - the thingy.
It doesn't matter if Jabber is designed to work with many other protocols, it still doesn't have a viable, scalable solution for determining presence, nor does it have any support for querying of the remote entity. It's simply YAP.
Listen, I don't care much about people who use ICQ or AIM, I'm a lot more interested in the future of presence determination and what might be possible then. Jabber is simply something that ties two or three pointless protocols together, it doesn't do much to solve the underlying problem.
Haven't checked it out much, but it seems to me that just using xx, and maybe a little nesting, is a long way to what XML is about.
I could be wrong (that happens sometimes).
What's Real-time about it?
Anonymous Coward
I hate being anal like this, but we always hated channels being referred to as "rooms". "chat rooms" was an AOL invention or at least used most notoriously by them...
XML has to be one of the most over-hyped technologies. You can make up your own tags - BFD.
A lot of us may dislike AOL for political reasons,
but they are technically impressive. The client runs on some of the crappiest hardware imaginable.
As for the server side, think of the scalibility problems they must encounter... it's an amazing feat, really!
I looked at his resume and was very impressed - 15000+ TPS sustained on what was probably a high-end HP workstation is *very* nice.
ICQ
.02
- depends on Central Authority to maintain database, can't be used on disconnected Intranets.
Zephyr (from MIT)
- Based on kerberos. Real hard to setup server.
Talk/write
- Requires knowing where someone is, doesn't work behind firewalls. No notification.
Gale (gale.org)
- More like IRC than ICQ because all servers talk to eachother.
- Central server logs all messages, public and private (Yikes!)
Just my
here's why not: file transfers. DCC is really screwed up. ICQ is right now the only easy way to transfer files between two people who don't happen to have the stuff to set their computers up as FTP or HTTP or hotline servers. which is very sad, because ICQ sucks ass.
Just because the "other chat communication protocols" use something similar to XML, dosn't nesicarily make it a good idea. ;)
If a lot of clients are going to be using this technology, it should be as secure and efficent (compact) as possible.
I just don't see why XML is a good idea simply because "it's easy to use", when the only people who need to really 'use' it are the programmers. And I (personally) would rather have to deal with a slightly more complex protocol during development, rather than having an extremly 'chatty' protocol. (pun intended
TK
I really don't like the idea of a corporate company taking care of my server acces. A government a little less, but certainly not the US goverment (way too big and fscked up). And then again, smart cards aren't a real good solution, they always want statistics, and I find that very dangerous.
:]
So rock-on for cookies, 4000 different passwords, and may I be the only one to grant myself access
HCP is another interesting project in the works. It lets you simply plug in existing protocols...
> If you need to see whether a person you are
> looking for is currently online, or not, you
> use finger. If you need "Instant Messaging",
> there's always ytalk. Chat? IRC, and so on...
So you're saying I have to always be telnetted into my server, and paying attention to my telnet session to talk to people? Or do I have to make people go to my web site to get my IP, and maybe I'm booted into Linux to answer them, and maybe they have a talk client... and...
The nice thing about instant messaging is just that. Instant messaging. As a program, ICQ is pretty much a piece of crap, but it has the advantage that a LOT of people use it. You can be fairly sure to get ahold of friends online. Even when your webpage changes, your email address changes, whatever, you always have that "ICQ number", and people can get ahold of you.
Maybe someday we can "convert" all those ICQ users over to something that works better, but most people are content where they are. Until then, I'll have to live with ICQ when I want to get ahold of my friend from another state easily...
WWJD? JWRTFM!!!
I've put great thought into these also, and the Privacy part is going to be addressed via different built in "privacy" levels in the server. One of them will be absolutely invisible, the only way someone would know you existed is if you sent them a message, and then they could only reply...
The security I'm leaving for version 2, but I'm making sure not to do anything to get in the way of it. Using something like PGP could already be used in the existing architecture, but would have to be supported by the client.
Jer
There will definately also be a command to do this for Jabber, soon probably.
jwrite user@server.com "message"
or
echo "message" | jwrite user@server.com
Jer
I also use talk, finger, etc... and you can count on Jabber working 100% WITH those utilities(if the Jabber server administrator installs translators for those services), and also have alias Jabber functions like jtalk, jwrite, jfinger that work identically but go directly to the jabber server instead of through a translator.
:)
I live on the CLI, but many/most of my friends do not, and I want to be able to talk to them... hence Jabber
1) The links in the Users section going to the overview was an accident, although the overview is really the only data there and yes, way overqualified for most users. It will be "nicer" after a public stable release.
:) Will fix!
2) File transfer or anything dealing with big binary chunks isn't going to be part of the main protocol. My current plan is to impliment all of those activities through HTTP/1.1 and WebDAV which is perfectly suited for that application, and just send the startup/location information through Jabber.
3) Not sure totally what you mean... thinking...
4) Because tools for manipulating/processing XML are quickly becoming standard and available. Secondly, XML is just a wonderful way to wrap up data, and it's text, easy to deal with in any situation.
5) Mirabilis uses UDP because ICQ is central-server based, and there is no way that their servers could possibly support a few million TCP connections. Jabber has no central server, so doesn't have that restriction, although very busy Jabber servers will have to deal with some problems because of TCP also, but there are ways of fixing it.
6) Sorry about the speling
Thanks!
Jer
I'll be honest, I'm not a big IRC user, although I admire the architecture.
:)
I was thinking, though, that a Jabber transport could be used to create seamless communication with IRC users, and vice versa. The Jabber users wouldn't really live in a room or be able to participate in the rooms(use a real IRC client for that) but could send IRC users messages like "user id@EFnet" and the Jabber IRC transport would do the translation.
The Jabber server is ready, if someone familiar with the IRC protocol wants to code this
See my reply above to "why not IRC?", I think Jabber and IRC can work together very nicely :)
I agree 1000% and this is exactly why I did Jabber. It may also be just another IM client/server system, but it is more. It was _designed_ to be interoperable with all other instant messaging systems from the start, so if you are using a Jabber client, you can talk to anyone else on any other system, and they can talk to you.
Within a short period of time(months), I expect Jabber to reach the "near-universal" interoperability.
Jabber is under the GPL at this point, but if need be, I'm willing to put it under another license to make it compatable.
Besides, Mozilla would only need a client, and clients are quite easy to write.
Jer
Yes, I'm planning on server file transfers through the server, probably using HTTP(specifically the WebDAV extensions) and letting Jabber communicate the locations/passwords for the files.
The files don't even need to be stored on the server, it can be a socket-to-socket copy in a server process, but storing them might be a usefull option, especially for broken downloads and group sends.
It does determine who is online, providing instant status updates.
:)
And as far as protocols, it doesn't need to show what they are using(although it can), because anything you send to them via Jabber will be translated on the fly to whatever protocol they are using if they are not Jabber users themselves.
Yes, everything else is superfluous, that is why Jabber is what it is, exactly what you state(plus the superfluous stuff too
Jer
Man, I wish people would just use email addreses for usernames. I mean, who in their right mind wants to remember a 15 char username (what AOL IM makes you use since they have 10 million other people taking anything remotely good), or the massively long number ICQ makes you use.
It's silly, everyone has an email address... Use it. I mean, one address for everything, email, chat, etc... sure would be nice.
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
One global ID for everything. Combination of letters/numbers. Why hasn't it caught on among the hacker community - too corporate?
http://www.qdirectory.com
(Torpor Q = 8008)
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
It even has authentication. And it has ways to reduce network load.
It's called Zephyr. And it's widely used at a number of universities. The code is freely available, there are even prebuilt RPMs (minus Kerberos authentication support) on RHCN.
Why invent yet another protocol when we already have one?
-- brandon s. allbery, sysadmin @ cmu electrical & computer engineering "Think, youth, THINK!"
If someone wrote an IRC client based around watching notifies and sending private messages instead of channels, one could just as easily do the same stuff and more that ICQ does with IRC. IRC is a more mature protocol, more widely used, and isn't proprietary like ICQ. The technology has been around for quite a while, the only difference is that Mirabilis came up with a new user interface that is less intrusive than the average IRC client. Someone want to do this with IRC?
IRC is based around the concept of rooms. You can only talk to other users inside that room, and all messages are public (by default) to the room.
Actually that isn't true. When sending a message over IRC, the command to send to a specific user and to send to a channel are exactly the same. There is no "default" message destination, channels merely exist to facilitate one-to-many and many-to-many communication, as opposed to one-to-one communication, as ICQ does.
A system like ICQ is based around the concept of lists of people. You can send messages to anyone on your list, and the messages and generally private to that person. Its restricted by its generally centralized and proprietary architecture and protocols.
The "lists of people" concept in ICQ is entirely client side, and can be done in IRC using NOTIFYs. Client-to-client stuff is handled using CTCP and DCC (Client-To-Client-Protocol and Direct-Client-to-Client respectively).
What IRC lacks is encrypted communications and established user accounts - at the moment, relatively little data is saved about users, and their nick can often change hands easily, allowing people to pretend to be or me mistaken for others... This is one of the few advantages of the centralization of ICQ and AIM.
You can do the exact same thing with IRC. Just get on an IRC server and don't join any channels. If your friends want to contact you, they can /msg you, just like with ICQ or AIM.
Anyway, the more like a BBS it is, the better. FidoNet is *still* the best messaging system, a LOT better than UseNet, webboards, or mailing lists.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
What baggage? IRC is a quite simple, well-documented protocol. Everything is in plaintext, and all the commands have numbers assigned to them so a client can just look at the numbers and know what's happening. Hell you can write IRC bots inside of mIRC's pathetic scripting language, so it can't be that hard to write an IRC client that acts like ICQ. All you need to do is take away the ability to /join a #channel and just use /msg instead, and you've got ICQ.
And IRC is definitely much more firewall friendly than ICQ. ICQ uses tons of different ports, while IRC uses one - 6667. Most clients can even go through a SOCKS firewall if you wish.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
There's this cool system where you can message people even when their computer is off!
email.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Actually, user-to-user messages on ICQ are TCP sometimes. If it fails to send through TCP directly to the user, and you click on "send through server," then it'll send through the server using UDP.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
My, aren't we grouchy today.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I really hope this one will go through a pretty secure firewall. Most people have tcp access to port 80/21, unless they are hooked to a proxy. If they can pipe realaudio through port80, then this should be easy.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
It looks as if Jabber's main strength is in any-to-any
messageing. Frankly, if they develop an addressing
scheme that allows me to send a message to just about
anyone, on any protocol (up to and including email)
then Jabber is the client I'll use.
And as people realise "Well, with my ICQ program, I can
message other ICQ users, but this guy can use Jabber to
message AIM, ICQ, Mail, IETF, etc", one protocol will emerge the victor.
Think about how many protocols your email (sometimes) goes through. Do you care? No, because gateways make it invisible.
There's a few ways to look at this. The first is to compare messages with SMTP mail. Where's the security and authentication in SMTP? Almost none. Do you care? Maybe, but if so you either use PGP to encrypt it, or perhaps you build your own mail network using something like (eek!) Notes, and if ;)
you really must go over the 'net, use a VPN.
Most people tolerate the insecurities of SMTP and
get on with it, without Back Orifice ever getting installed on their machines
Then there's instant messaging. One comparisom I've heard (thanks Nemo) is "ICQ is like passing notes in class". It's not quite chat, it's not quite mail, but
for the most part, you take your chances, and if the teacher nabs the note and reads it, well tough.
Again, if you care, you can use PGP, to build a secure messaging system atop the insecure one -- just as TCP is a reliable network protocol built atop IP's *un*reliable network protocol.
I'll agree that the protocol implementation and the UI should be kept seperate. But I'd go further. The UNIX way is to have a small command line program which does the job then exits. cicq is supposedly working towards this:
$ echo "You there?" | cicq -send slim
... a gui should be a wrapper around programs such as these. A "universal" messaging system would also be a wrapper around more specialised programs. i.e. messagesend -send icq:slim would spawn cicq -send slim
It's the UNIX way. And it's good. Let's not forget it just because some of us feel we're competing against Windows.
It works, it scales (somewhat), it supports real authentication, it's open, it presents the right paradigm for instant messaging and online discussion. (Since I used it heavily at CMU, using AOL Instant Messenger, IRC, and ICQ is just painful.)
Go to ftp://athena-dist.mit.edu/pub/ATHENA/z ephyr/ to download the source.
There's an effort underway by the IETF to come up with a standard protocol for instant messaging and "presence information" called IMPP. Anyone considering working on a project like this should get in the loop so they can make sure all their bases are covered, and so that they can interoperate with others' servers.
Go to http://lists.fsck.com/cgi-bin/wilma/pip for mailing list archives.
Unless you REALLY trust the people who are managing your UIN/Username/etc on the server, you don't WAN'T them to share everything between themselves. Besides, in Europe, it's illegal for them to do so.
A far better notion is to have all that information available to YOU, and YOU decide what to share with them. However, this technology (like a digital wallet) has been around for a really long time in web-world and has been abandoned for now, mostly because people don't want to administer them. You move computers, you have to move the thing. Floppies suck, smart cards aren't everywhere.
Now once GSM with PID smart-cards come to the US and I can use one card for credit, ATM, computer security and phone.... yum.... pervasive technology with privacy rights...
Some web sites do use a centralised user database.
:)
You create an account on this one site.. and when you want to access any of the sites that support it, it just authenticats you off the first site's server.
It's called adultcheck
I read somewhere a lot of advances in technology, including eCommerce, have been greatly helped along by the Adult entertainment industry.. I'm begining to believe it.
It's worth pointing out the GALE project as well.
I'm not sure about anyone else, but I've been using various versions of AIM (even beta) on my Mac and have never had any stability problems with it (the client). The only real problems that I've had have been server side, and even those are minimal and most likely due to the fact that AOL happens to serve millions of people and any line can only take so much.
Say what you want about certain members of AOL's clientele. Whine about it being an evil, greedy corportation. It's hard to deny that what AOL is doing technically is pretty darn impressive.
(hey, if you want feedback, here it is...)
+ All the links in the "Users" column go to the Overview, which claims it's for users but quickly bangs on about distributed servers, XML protocols and other techie stuff.
+ XML sounds very nice for simple messages, but how does it deal with live chat and file transfer?
+ The XML tags and attributes could do with being a bit more apt to the data. (e.g. "jenny" would be better put as "jenny" - at least, that's how it appears)
+ Come to think of it, why use XML rather than something a bit leaner? I wouldn't have thought that the client-server communications had to be human-readable, especially since it sounds like the only things Jabber clients will be talking to are Jabber servers.
+ Do you know why Mirabilis chose UDP for the ICQ transport?
+ Running a spellchecker on your site wouldn't hurt, either...
Otherwise, very nice, very commendable, good luck with it, etc. etc...
Pants.
I'm going to have one more go at this and if it doesn't work you'll just have to view source to get what I'm talking about.
+ The XML tags and attributes could do with being a bit more apt to the data. (e.g. "<group name='main'>jenny</group>" would be better put as "<user name='main'>jenny</user>" - at least, that's how it appears)
NOW WORK, YOU BASTARD!
Take a look at jwz's posting on the subject in Mozilla.org's "Blue Sky" section.
I've looked at alot of ICQish projects around, but Jabber looks like it has some great potential. I especialy like the idea of transports and having an XML based protocol. I added myself to the update list hope it catches on.
Snoop
Snoop Baron
Don't start a new protocol. The IETF wants instant messaging to be global and standardized; the last thing we need is another duplication of effort. Work with the IETF and end up with something standard.
Oh and by the way ... KDE sucks.
Tired of FB/Google censorship? Visit UNCENSORED!
What's the point of creating an "open" protocol, when AOL has already opened theirs? ICQ, of course is totally stupid, lagged, and insecure. I was glad to hear that AOL bought them out...maybe it will add some of the AOL stability to it.
Give me one good reason why you think AOL is unstable (don't forget to take into consideration the fact that they have experienced growth of tremendous levels, and will inevitably experience some growing pains).
IRC does different things. The most important point about ICQ is (a) you can see who of your contacts is available (b) you can initiate a conversation without pre-arranging it, like with a phone, since the reciever app is omnipresent.
It'd be nice if we could get a standard so you could do
rwrite username@full.host.and.domain.net "Hi there, how's it going?"
I wrote the first BuddyList server for AOL several years ago. (see my resume at http://sdw.st).
I've been watching the evolution of Presence Indicators with a lot of interest, of course, and I like some of the decisions so far here. I have some ideas that I'm thinking of persuing on my own that I may be able to share with everyone soon.
(Don't ask me about AOL internals because obviously I have a strictly professional and ethical obligation to uphold non-disclosure contracts.)
sdw
Stephen D. Williams
I know from past experience that too many hacker wannabees think that stealing accounts or bumping people or other pranks is cool rather than learning to program, which IS cool. Of course /./* is well into the latter category and didn't need the pre-emptive warning. Unfortunately my oldest son falls into the former category for the moment, sadly.
If you would have looked at the resume, you would have seen at least one huge addition to instant messaging that I came up with, architected and designed, skunk-worked, managed as an early project, implemented, had 25000 beta users, and ultimately watched die because of abuse fears...
sdw
Stephen D. Williams
You could easily make it totally transparent to the end user that you were using PGP.
Just make it a check box in the configuration and have a simple check to see if it is installed and working properly.
I think its an excellent idea.
I admire the attempt. Unlike the above-anonymous cowards...
It would be nice to make a client that could do AIM, ICQ, dynamic DNS, etc. Put that in a 32x32 icon and stick it in wharf, and you got one kick-ass project.
Keep up the good work...
g'luck
--
well, it might be so that they don't have the same problem that AOLIM does -- I have 3 "Dave"s on my list, and it's still fine. also, very easy to change your username.
yes, I'll agree that that number is a pain in the butt, and only my techie friends know it off the top of their heads, but it has its points.
you can search for the nickname, or just about any other piece of info -- it's just not the PRIMARY means of identification to the server.
and who can beat being able to have your TA's, and even some professors online, easily botherable? no one. that's the problem.
and as long as I'm stuck with this windoze box (no, I do not feel like writing my own ethernet card drivers, thank you) I'm stuck with ICQ. most people don't use finger, and if you are using dynamic IP (love that MSN when I'm at home!) it's kinda interesting trying to finger someone, even if they are running finger (as I am).
so, I guess if someone wants to see if I'm online, they'd better call me first to see what my IP is.
That's a nice thought, but in pratice, ick. If you do that, then the userdirectory becomes a spammer's paradise: a quick, queryable database of email addresses matched to real names. Ick! Ick! Ick!
This of course will eventually be the Right Way to do it, once cerificate-signed email becomes the norm and any and all email without at least a Class-2 caliber cert behind it gets discarded.
But it isn't, so it's not.
Besides, if you have a well designed DTD for chatty stuff, there really wont be that much overhead, and an XML based system gives people the ability to design almost entirely new realtime communication applications ontop of the original code without writing anything but a new doctype.
for messaging, I've always used write and ytalk
In my opinion, nothing is simpler and faster.
Well, for UNIX, there is a program called mxx, that does public key signatures, and encryption of messages. It works between systems running the server.
No reason it couldn't be extended slightly to work on Windows machines, handle a directory lookup, etc...
Note that the author is avoiding touching the code anymore.
- Dan
I've been following many of the instant messaging projects that are around, but I don't know which one to try.
I want the one that is closest to ICQ, has a good Windows client, and is fairly mature.
As a little side note, I think Teaser and Firecat is an important project in this field, mainly becuase it does not attempt to emulate ICQ and therefore is more secure. But we need something that is like ICQ, just because Windows users are more at home with it.
I used to work at a company that lets say puts out web browsers and I tried to push them to do this, but they ignored me time and time again.
O well. If an open source movement picks up in this area we might see some cools things happen. An ideal goal would be to get a windows version up and running so that smaller ISP's can snatch it and possibly force more commercial ISP's to adopt the technology. Then agin AOL paid alot of money for ICQ and would be rather against this I imagine.
This brings up another issue I'd like to see resolved. I hate having to create new user accounts on all of these web sites. I'd like one user account so that if I come across a site I'd like to take a look at, I just type in my "universial" username and password and I get instant access.
As an example, I went to TV guide to see local listings of Nerds 2.01, but they wanted me to create a new user account. So I walked away never to return. More and more sites are doing this and it's extremely aggravating, it takes time, and I bet you they are losing customers because of this policy.
Sounds like a cool idea to me. I'm far from an expert, but I wonder if Jabber's XML-based protocol and the open source model in general will make it possible to turn it into this kind of app. If so, it looks like a great chance to show the world (once again) what open source can do!
They would still be able to send spam to your
jabber message thingy.
nickserv and all of the other *serv 'bots' don't exist on all IRC networks. For that matter, I've only seen them on dalnet, and when you've got 450 people in #chatzone at once, i can see why it might be neccessary. I don't see any *serv on efnet or undernet. So it's not necessarily true that IRC provides the same features as ICQ or AIM, even if you just sit on the server without joining a channel or anything.
:o)
Hm, and perhaps I should get offline at home once in a while... it's been online since i last restarted it, a little more than a week ago
Dogma: Dead (mostly because your Karma ran it over)
The person who said "There are too many chiefs and not enough indians" is TOTALLY correct. A quick search on freshmeat returns fifteen of these "instant message" projects under development right now that all do pretty much the same things.
To the programmers working on these projects: It's noble that you are committing your time to cool and open projects like this, but don't you think you could get more done if you all worked together rather than seperately?
An even more disturbing thing I have noticed about these projects is the fact that many of them are being developed under the Windoze paradigm where the interface is closely tied to the implementation, rather than the unix model where the interface, implementation, and underlying libs are seperate components.
For instance, download a few of these projects and check them out. All of them include their own implementation of the ICQ protocol. People, the ICQ protocol is the same regardless of whether you are using Qt or GTK! Why can't we develop a libicq and a libaim THAT EVERYONE AGREES ON? This way the protocol and the interface can be worked on in parallel by different teams!
Am I the only one that feels this way?
just create something that works through a firewall. AOL-IM works fine but ICQ dosen't even get close to working through my firewall, all their firewall config doesn't do a thing!
i'd really like to see public/private key encryption (and thus authentication) wrapped into the thing.
an example of the u.i. would be that you can have "authenticated" messages be real-time, and all others go to mail...
or, authenticated messages are "green" in color, whilst non-authenticated are "red"
lots of possibilities...
cool tool indeed.
i'll need to go help out..
me
"Too many chiefs, and not enough indians" - couldn't agree more ..
IRC is a chat protocol. ICQ and AIM are instant messaging protocols. While similar in purpose, they differ greatly in organization.
IRC is based around the concept of rooms. You can only talk to other users inside that room, and all messages are public (by default) to the room. The IRC protocol works very well, although its restricted by its ASCII-based interface.
A system like ICQ is based around the concept of lists of people. You can send messages to anyone on your list, and the messages and generally private to that person. Its restricted by its generally centralized and proprietary architecture and protocols.
ICQ and AIM may do chat too now (I've only used an old ICQ client), but their specialty is one to one communication. IRC's specialty is group-based communication. Both have their own own advantages, and a good general-purpose realtime messaging system should incorporate both schemes.
I still don't see the need for "Instant Messaging"-software.
If you need to see whether a person you are looking for is currently online, or not, you use finger. If you need "Instant Messaging", there's always ytalk. Chat? IRC, and so on...
"Instant Messaging" is just a way of re-inventing the wheel for the computer illiterate.
I'm all for the security aspect as well. One issue you should keep in mind is the export restrictions placed on many types of security measures. It seems to me that you'd like to keep your software available to all types of users, world-wide.
IRC uses more bandwidth (unless you're just idling, but then it probably still uses more), and anybody can /whois you and try to hack you. With ICQ only the people on your list can get your IP address, and only if you're visible to them.