1356245
story
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."
Big Brother (Score:1)
So rock-on for cookies, 4000 different passwords, and may I be the only one to grant myself access
What about HCP? (Score:1)
ICQ - IH8U (Score:1)
> 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...
Security/Privacy (Score:1)
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
Wow - all these projects (Score:1)
jwrite user@server.com "message"
or
echo "message" | jwrite user@server.com
Jer
ICQ - IH8U (Score:1)
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
Random pickiness (Score:1)
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
Yes, Jabber+IRC will work (Score:1)
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 above post (Score:1)
united IMs (Score:1)
Within a short period of time(months), I expect Jabber to reach the "near-universal" interoperability.
License (Score:1)
Besides, Mozilla would only need a client, and clients are quite easy to write.
Jer
Server side + HTTP/1.1 + WebDAV (Score:1)
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.
yes it does (Score:1)
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
UINs, ID's, Usernames, Etc (Score:1)
It's silly, everyone has an email address... Use it. I mean, one address for everything, email, chat, etc... sure would be nice.
That's what Q is for: http://www.qdirectory.com (Score:1)
http://www.qdirectory.com
(Torpor Q = 8008)
The *existing* open source messaging protocol (Score:1)
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... (Score:1)
why not IRC? (Score:1)
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.
why not IRC? (Score:1)
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 (Score:1)
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.
why not IRC? (Score:1)
email.
Random pickiness (Score:1)
BuddyList and other Presence Indicators (Score:1)
Re: ICQ - IH8U (Score:1)
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.
tcp not udp (Score:1)
RE: why not IRC? (Score:1)
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?
Gatewaying (Score:1)
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.
Security/Authentication (Score:1)
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.
libicq etc (Score:1)
$ 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.
Two points (Score:1)
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/ [mit.edu] 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 [fsck.com] for mailing list archives.
Shared Server-side UINs are privacy risk... (Score:1)
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 (Score:1)
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.
Gale (Score:1)
AIM (Score:1)
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.
Random pickiness (Score:1)
+ 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...
Comment preview LIES! (Score:1)
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 (Score:1)
looks good! (Score:1)
Snoop
Work with the IETF. (Score:1)
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.
AIM (Score:1)
AIM (Score:1)
why not IRC? (Score:1)
Wow - all these projects (Score:1)
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 (Score:1)
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
BuddyList and other Presence Indicators (Score:1)
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
Security/Privacy (Great Idea) (Score:1)
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.
way to go! (Score:1)
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! (Score:1)
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! (Score:1)
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.
Eek! No! (Score:1)
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.
XML? (Score:1)
ytalk? (Score:1)
In my opinion, nothing is simpler and faster.
Beyond the scope of the /. reader (Score:1)
Well, for UNIX, there is a program called mxx [home.com], 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.
Okay, which one? (Score:1)
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 (Score:1)
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 (Score:1)
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 (Score:1)
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!
Eek! No! (Score:1)
jabber message thingy.
why not IRC? (Score:1)
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
TOO MANY of these projects! (Score:1)
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?
firewalls (Score:1)
Excellent! (Score:1)
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 protocols (Score:1)
why not IRC? (Score:1)
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.
ICQ - IH8U (Score:1)
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 (Score:1)
why not IRC? (Score:1)