The allegation that Jabber, Inc. "has patents on stuff you need to implement jabber" is absurd and ill informed. Jabber, Inc. did not even exist when Jabber started, and because Jabber has kept everything in the public eye, and basically put the protocol in the public domain, it's near impossible for Jabber, Inc. to actually own any part of it. Yes, they own the trademark, but as stpeter pointed out it is being transferred to the JSF. It's also true that Jabber, Inc. has many commercial products, but the open source community has something equivalent to most of them.
As to their commitment to the open source community they have people such as myself and stpeter on their payroll that really only work on open source projects and tools. Neither of us have worked on any of the commercial projects in quite a long time.
It's funny, but the site you link to for the article (old article) actually has a jabber server. You can find more about it here. While it might not blatantly say Jabber on the page anywhere, we are talking about protocols here right? So to just touch on the subject of penetration I would say Disney's GO (which includes ABC and ESPN) is a pretty big name supporting Jabber.
While this may be true of a completely base installation, it is not true on a server that has been configured well. If karma (socket reading limitter) is used properly with a short auth time then the server will have no problems. Besides, this is not a protocol issue at all, rather an implementation one.
Well be happy, it already compiles under Linux. I've been working hard on the Linux port and have the Core and Engine compiling currently, and should be in CVS now. I'm also working on the OpenGL renderer as I type this. I'm actually hoping to get some OpenGL screenshots tonight. It will just be a basic version, but it's a starting point.
I beg to differ. I develop the AIM Transport. I've also worked on libfaim, and was around for the initial introduction of TOC. TOC looked promising despite it's odd ASCII protocol, but we continued work on OSCAR because TOC was considered a side project and not 100% supported by AOL. As luck would have it AOL has proved that decision to be wise many times. They have stopped work on TOC numerous times and have even removed features from it. OSCAR has continued to grow. When AOL started to try and block us (Jabber) we grew fairly confident that their changes were directed solely at Jabber. The blocks always happened after minute changes I made in the aim source specifically, and we were told so in an indirect way. Some ended up affecting other libfaim based projects such as Gaim. Until everything was figured out I was heavily considering a TOC implementation. The problem was that would have caused problems for other programs using TOC if they continued to actively target Jabber. I decided this type of behaivour would be unfair to the other projects, and it continues to allow them to always have a "pure" channel. In the end it has all worked out. We have fully figured out their attempted blocks and everything seems to be moving forward. There are specific IP blocks on some of the larger Jabber servers, but that's life.
Currently I'm actively working on the AIM-Transport (more information). and expect to put out a version 0.10 in not too long.
Re:Jabber shortcomings - not in the book
on
Programming Jabber
·
· Score: 4, Informative
I like to make sure that all questions asked on our (jabber.org) jdev and jadmin mailing lists get answered. Sometimes the questions will get answered in our groupchat, or in other ways, but an answer is usually given.
As far as I know xdb_sql currently lacks a maintainer, but it's open source so maybe someone will pick it up.
The lack of good docs on the user file definition is valid, but at the same time it's not suggested you edit it by hand due to the aggressive cacheing used on it. We're starting a new docs effort right now and I'll make sure this is on the list.
The basic applet that is on sourceforge (here) is focussed on simplicity, but it does work, and I know people have built more off of it.
As to your concerns with Jabber, Inc., I don't know why they would want to keep any of that stuff secret. It's mostly useless to them since their server ships with a different XDB backend and their web client has a different focus than a pure applet approach.
Doh... yes new. We like lots of views, especially new ones;-)
Java Oriented Jabber Book
on
Programming Jabber
·
· Score: 5, Informative
I've seen a lot of comments disliking the abundance of Perl/Tk usage in DJ's book. Recently Manning Publications released Instant Messaging in JAVA: The Jabber Protocols in print and ebook. It was written by Iain Shigeoka, and is ISBN 1-930110-46-4. It's a good read and goes over the creation of both a client and a basic server in Java, plus a good deal more.
I think you're failing to grasp some of the points of Jabber messaging, especially as something more than basic chat. The idea (at least from the Jabber point of view) is to _NOT_ learn the IP address of the other party. You only reference them from their "username". Username is the wrong term though, we user the term JID (Jabber id). The JID format is: username@host/resource. So it is built upon a DNS like system. Once you know another users JID you can interact with it using messaging, presence, or other methods. The power of not trying to interact with an IP directly is it's ability to more cleanly go around firewalls. The client makes a connection outside of the firewall to their Jabber server (potentially through some proxy), and they are then on the entire Jabber network. Applications that are exposed on the network then have the ability to interactively use presence and a clear path to the user for more complete interaction. So perhaps you are looking at this from the wrong viewpoint?
There is talk about guaranteed msging in the future , primarily with a focus on JAM (Jabber as Middleware). A lot of this is in parallel with the next generation discussions that are happening on and off. So it is in our sites, but we're not sure how quickly it will arrive. Feel free to join our standards-jig mailing list (See our lists) and participate, few views are always welcome.
Correct. I'm the author of the AIM Transport and it's still in active development. I'm actually in the middle of refactoring it as a completely external component (again). The ICQv7-t transport is also in active development on it's sourceforge site. Besides the blocks on some of the larger public servers things are great, just setup your own =)
Which attack and anger are you talking about? One of the main reasons I've seen people deploy Jabber and throw spite towards AIM is security. The companies need to be able to control their users actions to some extent and having the messages float around on some other network doesn't help that very much. A Jabber server can be configured to only allow internal usage, and then possibly proxy traffic to the outside world in a concentrated and controlled manner. Even more so components could be built to log all traffic and store it in a safe and encrypted manner. This would be quite a chore of packet sniffing a network and reconstructing to do this if you let your users have access to the AIM network. Even more so if you then let users have access to any network they want.
Is email too complex? If your JID were the exact same as your email address would it be too complex? I don't see why that makes the system too complex, especially if it allows for a unified ID. Your other issues seem to be UI issues that are also dependant on preferences (check out the force msg type options in Gabber).
I agree that documentation is our weakest point, but major steps are being taken to work on that. I wouldn't necessarily classify it as a lack of documentation, rather a lack of unified documentation. Recently there have been some great docs put together, but they don't get merged into larger finished docs. Hopefully in the next few weeks docs can beging to flourish more fully.
Hah, I drew a picture after one of our developer meetings about that, but it's not going to happen, ever. We're direct competition to Hailstorm, and there is no way to kill the source that is out there so what are they going to do? Fight us through other means I'm sure, but otherwise continue to try and move faster than us. I don't see that happening with corporate weight though.
Although this may be true of a service system, this is not true of Jabber. The real power lies in the number of servers that are out there. Unfortunately we haven't done the best job of protraying the idea of having your own server, or a server at your ISP rather than using the existing public ones. As the number of servers increases we can expect to see the supposed "user count" jump up and up suddenly, especially if corporations proxy out their users. But there is really no way to tell the user count because the server is available and people/corporations could be using it internally so their IM traffic stays internal and protected (logged?). Just food for thought, plus we're slowly forming our next generation plans that can begin to tear away the IM/chat stereotype from Jabber and begin to let it flourish as a true real time communication infrastructure.
We currently strongly encourage the use of PGP/GPG and it is implemented in WinJab, Jarl, and Gabber clients. The protocol has support for it, and is being widened soon to encompass more public key methods. The server also supports SSL connections, this is supported by many clients as well.
Two points. First, the AIM Transport for Jabber will possibly have code put in so that the aim.exe can sit beside it and then have complete functionality again. I'm still debating the possible legal problems of that with some people, but I feel fairly sure that if the user downloads the aim.exe themselves, then it should be ok. Next, AOL has every right to protect their network, I even applaud them for doing it, and doing it in such an interesting way, but thinking the merger rulings will help is wrong. Go read the FCC document yourself, pay close attention to pages 4 and 5. Until the conditions are met, more power to them, but I will continue to help in decoding more of the protocol.
Hello, I'm the author of the AIM Transport for Jabber (the piece of Jabber that is being discussed). I would like to point out that I 100% agree with you. OSCAR is their protocol, and they have every right to defend it and stop our use of it. However, suggesting that they will let us on TOC is doubtful. According to recent articles in the press the order to stop Jabber came from the head of the AIM group. This didn't say stop Jabber from using OSCAR, it said stop using period. Personally, I feel I might have to move to TOC for a short while, and that makes me feel bad, because I do not want to ruin the TOC experience for all the people already using it. The other, and primary reason, to not move to TOC is the lack of full power and potential. TOC is a dead protocol, and it's servers have experienced many problems. Outages for days at a time, and it has even lost features. Compared to TOC which continues to grow, I think there is an obvious choice there.
After reading the Indrema replies, I noticed the big question was: "Well what large game companies are going to support them?" The same could be asked of this setup, but I suspect otherwise. If the arcade machines are cheap to deploy, and cheap to develop for (similar to Indrema's free SDK), then large companies would probably love this as it gets there game out there quickly, cheaply. So now think of the ports over to the Indrema! It seems to be an obvious progressive alliance possiblity for the two (If it's not already there).
Hi, I'm the author of the Jabber AIM transport, and I would like to point out that it is in fact OSCAR based. I have been active in the movement to have an Open Source OSCAR stack for a long time, and it was a no brainer choice to use it in the transport. TOC is waste in many aspects, but has a few fine points (it actually worked for a while;-]), but just wanted to clarify that point.
I would just like to point out that they have not changed their protocol at all, and their RFC submission was not an actual protocol, but rather a broad and general architectural overview. Little has been done to be accepting of people still. Although there are small glimmers of light.
The protocol that we have implemented in the Jabber system, is designed just for this task, to bridge the current, and future IM services. We currently bridge to AIM, ICQ, Yahoo!, MSN, IRC, and others are in the works, along with other networks working on bridging into ours. What's even better is we are already completely open and free.
I would highly encourage you to visit our site Jabber.org for all your development needs, and Jabbercentral for your end user related needs. Even more so we encourage you to download our server and seutp your own system, because we are similar in idea to how email works, anyone can run a server and talk with all the currently existing Jabber servers.
With ~20,000 users between just the public jabber.org and jabber.com servers we're growing extremely fast, and we hope that others will take part in our growth.
I really don't like being off-topic, but I just have to say, that after dealing with JP, I 100% distrust and dislike the guy. He exploits his supposed position, and whines when he doesn't get his way. To top it off he uses people and waves around law suit threats like they were weapons. If you want more info on my personal incidents just let me know, I'm more than happy to share.
The structure that AT&T is trying to setup, of allowing connections to other servers, is very much like the free, open alternative that the Jabber team is creating. Although we are not creating a client only solution. We have a server based around a XML stream protocol that allows pluggable transports for different protocols, with clients for almost every platform. This allows for an extremely extensible system. Currently we have betas for AIM (libfaim has not been blocked throughout this entire ordeal of blocked clients), ICQ, and MSN is in the works. I have just completed a group chat (similar to ICQ) module as well.
Although the side of having an IM client that can connect to a lot of others is appealing, Jabber is much much more. We have plans to jabberify many programs (CVS, Abiword, Bugzilla, and more). By doing so the power of these programs increases in many orders of magnitude. Just imagine multiple working on a document in Abiword at the exact same time, or CVS automagically pushing you updates, or Bugzilla yelling at you when you get a new urgent bug? It all sounds really appealing to me.
Being free and open source, Jabber has the potential to be so much to the internet, and help settle some of these annoying arguments that a lot of the corporate players are having. Come visit us on IRC in #jabber on openprojects network or just visit the web site.
Slashdot Mirror
The allegation that Jabber, Inc. "has patents on stuff you need to implement jabber" is absurd and ill informed. Jabber, Inc. did not even exist when Jabber started, and because Jabber has kept everything in the public eye, and basically put the protocol in the public domain, it's near impossible for Jabber, Inc. to actually own any part of it. Yes, they own the trademark, but as stpeter pointed out it is being transferred to the JSF. It's also true that Jabber, Inc. has many commercial products, but the open source community has something equivalent to most of them.
As to their commitment to the open source community they have people such as myself and stpeter on their payroll that really only work on open source projects and tools. Neither of us have worked on any of the commercial projects in quite a long time.
It's funny, but the site you link to for the article (old article) actually has a jabber server. You can find more about it here. While it might not blatantly say Jabber on the page anywhere, we are talking about protocols here right? So to just touch on the subject of penetration I would say Disney's GO (which includes ABC and ESPN) is a pretty big name supporting Jabber.
While this may be true of a completely base installation, it is not true on a server that has been configured well. If karma (socket reading limitter) is used properly with a short auth time then the server will have no problems. Besides, this is not a protocol issue at all, rather an implementation one.
Well be happy, it already compiles under Linux. I've been working hard on the Linux port and have the Core and Engine compiling currently, and should be in CVS now. I'm also working on the OpenGL renderer as I type this. I'm actually hoping to get some OpenGL screenshots tonight. It will just be a basic version, but it's a starting point.
I beg to differ. I develop the AIM Transport. I've also worked on libfaim, and was around for the initial introduction of TOC. TOC looked promising despite it's odd ASCII protocol, but we continued work on OSCAR because TOC was considered a side project and not 100% supported by AOL. As luck would have it AOL has proved that decision to be wise many times. They have stopped work on TOC numerous times and have even removed features from it. OSCAR has continued to grow. When AOL started to try and block us (Jabber) we grew fairly confident that their changes were directed solely at Jabber. The blocks always happened after minute changes I made in the aim source specifically, and we were told so in an indirect way. Some ended up affecting other libfaim based projects such as Gaim. Until everything was figured out I was heavily considering a TOC implementation. The problem was that would have caused problems for other programs using TOC if they continued to actively target Jabber. I decided this type of behaivour would be unfair to the other projects, and it continues to allow them to always have a "pure" channel. In the end it has all worked out. We have fully figured out their attempted blocks and everything seems to be moving forward. There are specific IP blocks on some of the larger Jabber servers, but that's life.
Currently I'm actively working on the AIM-Transport (more information). and expect to put out a version 0.10 in not too long.
I like to make sure that all questions asked on our (jabber.org) jdev and jadmin mailing lists get answered. Sometimes the questions will get answered in our groupchat, or in other ways, but an answer is usually given.
As far as I know xdb_sql currently lacks a maintainer, but it's open source so maybe someone will pick it up.
The lack of good docs on the user file definition is valid, but at the same time it's not suggested you edit it by hand due to the aggressive cacheing used on it. We're starting a new docs effort right now and I'll make sure this is on the list.
The basic applet that is on sourceforge (here) is focussed on simplicity, but it does work, and I know people have built more off of it.
As to your concerns with Jabber, Inc., I don't know why they would want to keep any of that stuff secret. It's mostly useless to them since their server ships with a different XDB backend and their web client has a different focus than a pure applet approach.
Doh... yes new. We like lots of views, especially new ones ;-)
I've seen a lot of comments disliking the abundance of Perl/Tk usage in DJ's book. Recently Manning Publications released Instant Messaging in JAVA: The Jabber Protocols in print and ebook. It was written by Iain Shigeoka, and is ISBN 1-930110-46-4. It's a good read and goes over the creation of both a client and a basic server in Java, plus a good deal more.
I think you're failing to grasp some of the points of Jabber messaging, especially as something more than basic chat. The idea (at least from the Jabber point of view) is to _NOT_ learn the IP address of the other party. You only reference them from their "username". Username is the wrong term though, we user the term JID (Jabber id). The JID format is: username@host/resource. So it is built upon a DNS like system. Once you know another users JID you can interact with it using messaging, presence, or other methods. The power of not trying to interact with an IP directly is it's ability to more cleanly go around firewalls. The client makes a connection outside of the firewall to their Jabber server (potentially through some proxy), and they are then on the entire Jabber network. Applications that are exposed on the network then have the ability to interactively use presence and a clear path to the user for more complete interaction. So perhaps you are looking at this from the wrong viewpoint?
There is talk about guaranteed msging in the future , primarily with a focus on JAM (Jabber as Middleware). A lot of this is in parallel with the next generation discussions that are happening on and off. So it is in our sites, but we're not sure how quickly it will arrive. Feel free to join our standards-jig mailing list (See our lists) and participate, few views are always welcome.
Correct. I'm the author of the AIM Transport and it's still in active development. I'm actually in the middle of refactoring it as a completely external component (again). The ICQv7-t transport is also in active development on it's sourceforge site. Besides the blocks on some of the larger public servers things are great, just setup your own =)
Which attack and anger are you talking about? One of the main reasons I've seen people deploy Jabber and throw spite towards AIM is security. The companies need to be able to control their users actions to some extent and having the messages float around on some other network doesn't help that very much. A Jabber server can be configured to only allow internal usage, and then possibly proxy traffic to the outside world in a concentrated and controlled manner. Even more so components could be built to log all traffic and store it in a safe and encrypted manner. This would be quite a chore of packet sniffing a network and reconstructing to do this if you let your users have access to the AIM network. Even more so if you then let users have access to any network they want.
Is email too complex? If your JID were the exact same as your email address would it be too complex? I don't see why that makes the system too complex, especially if it allows for a unified ID. Your other issues seem to be UI issues that are also dependant on preferences (check out the force msg type options in Gabber).
I agree that documentation is our weakest point, but major steps are being taken to work on that. I wouldn't necessarily classify it as a lack of documentation, rather a lack of unified documentation. Recently there have been some great docs put together, but they don't get merged into larger finished docs. Hopefully in the next few weeks docs can beging to flourish more fully.
Hah, I drew a picture after one of our developer meetings about that, but it's not going to happen, ever. We're direct competition to Hailstorm, and there is no way to kill the source that is out there so what are they going to do? Fight us through other means I'm sure, but otherwise continue to try and move faster than us. I don't see that happening with corporate weight though.
Although this may be true of a service system, this is not true of Jabber. The real power lies in the number of servers that are out there. Unfortunately we haven't done the best job of protraying the idea of having your own server, or a server at your ISP rather than using the existing public ones. As the number of servers increases we can expect to see the supposed "user count" jump up and up suddenly, especially if corporations proxy out their users. But there is really no way to tell the user count because the server is available and people/corporations could be using it internally so their IM traffic stays internal and protected (logged?). Just food for thought, plus we're slowly forming our next generation plans that can begin to tear away the IM/chat stereotype from Jabber and begin to let it flourish as a true real time communication infrastructure.
We currently strongly encourage the use of PGP/GPG and it is implemented in WinJab, Jarl, and Gabber clients. The protocol has support for it, and is being widened soon to encompass more public key methods. The server also supports SSL connections, this is supported by many clients as well.
Two points. First, the AIM Transport for Jabber will possibly have code put in so that the aim.exe can sit beside it and then have complete functionality again. I'm still debating the possible legal problems of that with some people, but I feel fairly sure that if the user downloads the aim.exe themselves, then it should be ok. Next, AOL has every right to protect their network, I even applaud them for doing it, and doing it in such an interesting way, but thinking the merger rulings will help is wrong. Go read the FCC document yourself, pay close attention to pages 4 and 5. Until the conditions are met, more power to them, but I will continue to help in decoding more of the protocol.
--temas
Jabber Developer
Hello, I'm the author of the AIM Transport for Jabber (the piece of Jabber that is being discussed). I would like to point out that I 100% agree with you. OSCAR is their protocol, and they have every right to defend it and stop our use of it. However, suggesting that they will let us on TOC is doubtful. According to recent articles in the press the order to stop Jabber came from the head of the AIM group. This didn't say stop Jabber from using OSCAR, it said stop using period. Personally, I feel I might have to move to TOC for a short while, and that makes me feel bad, because I do not want to ruin the TOC experience for all the people already using it. The other, and primary reason, to not move to TOC is the lack of full power and potential. TOC is a dead protocol, and it's servers have experienced many problems. Outages for days at a time, and it has even lost features. Compared to TOC which continues to grow, I think there is an obvious choice there.
--temas
JID/EMAIL: temas@jabber.org
P.S. - These are my views, and mine alone.
After reading the Indrema replies, I noticed the big question was: "Well what large game companies are going to support them?" The same could be asked of this setup, but I suspect otherwise. If the arcade machines are cheap to deploy, and cheap to develop for (similar to Indrema's free SDK), then large companies would probably love this as it gets there game out there quickly, cheaply. So now think of the ports over to the Indrema! It seems to be an obvious progressive alliance possiblity for the two (If it's not already there).
Hi, I'm the author of the Jabber AIM transport, and I would like to point out that it is in fact OSCAR based. I have been active in the movement to have an Open Source OSCAR stack for a long time, and it was a no brainer choice to use it in the transport. TOC is waste in many aspects, but has a few fine points (it actually worked for a while ;-]), but just wanted to clarify that point.
--temas
Jabber ROCKS!
I would just like to point out that they have not changed their protocol at all, and their RFC submission was not an actual protocol, but rather a broad and general architectural overview. Little has been done to be accepting of people still. Although there are small glimmers of light.
--temas
Jabber ROCKS!
I would highly encourage you to visit our site Jabber.org for all your development needs, and Jabbercentral for your end user related needs. Even more so we encourage you to download our server and seutp your own system, because we are similar in idea to how email works, anyone can run a server and talk with all the currently existing Jabber servers.
With ~20,000 users between just the public jabber.org and jabber.com servers we're growing extremely fast, and we hope that others will take part in our growth.
--Temas
Jabber ROCKS!
(Assuming JP of AntiOnline)
I really don't like being off-topic, but I just have to say, that after dealing with JP, I 100% distrust and dislike the guy. He exploits his supposed position, and whines when he doesn't get his way. To top it off he uses people and waves around law suit threats like they were weapons. If you want more info on my personal incidents just let me know, I'm more than happy to share.
The structure that AT&T is trying to setup, of allowing connections to other servers, is very much like the free, open alternative that the Jabber team is creating. Although we are not creating a client only solution. We have a server based around a XML stream protocol that allows pluggable transports for different protocols, with clients for almost every platform. This allows for an extremely extensible system. Currently we have betas for AIM (libfaim has not been blocked throughout this entire ordeal of blocked clients), ICQ, and MSN is in the works. I have just completed a group chat (similar to ICQ) module as well.
Although the side of having an IM client that can connect to a lot of others is appealing, Jabber is much much more. We have plans to jabberify many programs (CVS, Abiword, Bugzilla, and more). By doing so the power of these programs increases in many orders of magnitude. Just imagine multiple working on a document in Abiword at the exact same time, or CVS automagically pushing you updates, or Bugzilla yelling at you when you get a new urgent bug? It all sounds really appealing to me.
Being free and open source, Jabber has the potential to be so much to the internet, and help settle some of these annoying arguments that a lot of the corporate players are having. Come visit us on IRC in #jabber on openprojects network or just visit the web site.