Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Jabber (also called XMPP) is an open and standardized IM protocol, which provides a feature called MUC (Multi User Chat), where users can create conference rooms on a jabber server to communicate with each other. We should consider to deploy this technology. This specifiation defines application fields of Jabber withhin the Ubuntu community and Pro / Cons for using it. In case of positive conclusion the implementation also goes into this specification.
At the moment the most communication in the Ubuntu community takes place in Ubuntu forums, mailings lists and IRC. Those communications forms are limited to plain text messaging. Here possible reasons why we should deploy Jabber:
Federation In Jabber all servers are connected to each other. Therefore it doesn't matter on which Jabber server a user registered, he can enter a conference hosted on another server without opening an extra connection to this server.
Flexibility With Jingle Jabber is very flexible in the way it communicates. While at the moment it only supports text messaging and VoIP, it is extendable to video conferencing and other communications forms in future.
Consistency At the moment there are a crowd of protocols used to handle the different communication forms. ICQ / MSN / AIM and mail for user-to-user communication, SIP and Skype for VoIP and IRC for multi-user chat. In oppostion to that Jabber is desidgned to integrate all those communication forms in one protocol.
Security All connections between clients and servers are by default encrypted via TLS / SASLS. To further improve security users can use the built-in PGP encryption.
Awareness Promoting jabber as a communication protocol for Ubuntu, we are making Jabber known to people as an altenative to locked IM protocols.
- Bob is a new Ubuntu user. He wonders why 3D-accelleration is not working. He calls up his Jabber account in Gaim, which he is running anyway for chatting with his Google Talk friends. He enters the ubuntu-support conference room to get assistance from other users to get 3D-accelleration working.
- John experiences a problem in Ubuntu. He doesn't know Jabber, but he's already familiar with Gaim, because he uses it for chatting with his ICQ buddies. He clicks in Ubuntu on 'get Help' and Ubuntu guides him through the Jabber account registration process, then it automatically enters the ubuntu-support conference room.
- Sandra's Paket Manager crashes. The responsible developers, who have lodged their Jabber ID in Launchpad get a crash report on their Jabber client in real time. (note: This can be easiliy done by the Jabber Pub Sub specification.
Have a look at the links section.)
- Joe administrates a server. He is subscribed to a Pub-Sub Node containing the information from the mailing list ubuntu-security-announce. When a new security update for php5 was released, he gets instantly a message about the new package version, so he can update this package.
Another thinkable option is a support base like Qunu. See http://www.qunu.com
- Lene is a Ubuntu newbie, and is happy to quickly get an instant messenger going. "Just like in Windows"
Be more specific in what you propose. "Deploying Jabber" is rather vague. Are you proposing that Jabber completely replace IRC as the preferred instant messaging mechanism for Ubuntu? Or are you simply proposing that both IRC and Jabber be officially used by Ubuntu, giving the user their choice of support mechanisms? I would be in favor of the second, but definitely not the first. --MichaelOlson
No, it's absolutely not intended to close the Ubuntu IRC channels. Even when we deploy jabber conferences there will still be many users who want to continue using IRC, because they are used to it. Therefore Ubuntu IRC channels will continue to exist for many years. -- SamirVanDeSand 2006-10-25 19:10:24
Since Ubuntu has exactly one method of instant messaging, namely IRC, the Consistency point is not valid. This content should instead be merged with Awareness. --MichaelOlson
In the discussion on the ubuntu-devel list some people expressed their doubts, that Jabber can handle conferences with 100+ users. Unfortunately, no Jabber conferences with that much users exist yet, so it don't know how well Jabber MUC does scale with a lot of participants. Maybe a Jabber developer can comment on this ? -- SamirVanDeSand 2006-10-25 19:10:24
See http://www.xmpp.org/extensions/xep-0045.html for the Jabber MUC specification.
Collaboration with the Telepathy team might be advisable.
BoF agenda and discussion
By Per Ekström:
Note: This should probably move to a forum thread or something, but I'm posting this here in the meanwhile since no discussion page has been created yet, and I'm too unfamiliar with Wikis to dare create one.
Anyhow, great idea, here are a few suggestions on how to make it better (focusing on the MUC stuff, for now):
* Develop a Jabber Client which focuses on a rich MUC experience
While Gaim and Kopete certainly works if you want to enter one or a few rooms, it's not exactly ideal when you have many chats going at once. This is due to current IM Clients are focused on delivering One-to-One (IM) instead of One-to-Many (MUC) chats. While there's nothing wrong with that, some people prefer the MUC way over the IM way, just like some people prefer a lightweight windowing manager like FluxBox instead of Gnome or KDE. I will try and develop something myself, but since I'm a very busy person right now it'll take until atleast this summer before I can do anything useful.
- This is very good idea. Developing a Jabber client with IRC-like GUI would ease the change to Jabber for IRC users.
* Using IRC-to-Jabber and Jabber-to-IRC transports to ease migration
Most people seem to think this is an either-or-proposition; however, it doesn't have to be this way. Jabber was designed with legacy protocols in mind, so it has gateways to pretty much everything under the sun. Most of these gateways are client-side only; However, for the open protocols it is possible to write a gateway the other way around. See this link for more info: http://esw.w3.org/topic/JabberChickenEgg Also have a look at this mail http://mail.jabber.org/pipermail/jdev/2006-October/024480.html
Expanding on this idea would be beneficial since we could quite easily move the infrastructure to Jabber while keeping the IRC support intact, thus minimizing confusion - However, it would take a little extra work.
That's my two cents. Feel free to tear 'em to bits.
Regarding servers which are usable from Jabber and IRC you might also have a look at http://www.psyced.org, which provides a mature IRC interface and a usable interface for Jabber MUC. But there are some disadvantages, like "long nicknames" for IRC users (it uses full xmpp:user@host uniforms, unless the user has configured an alias for it; beware, users _really_ dont like this, but unfortunately there is no workaround) or not being able to join remote jabber MUC rooms when using a local IRC client. -- PhilippHancke
Using the IRC module in ejabberd might be a quick way out, but it doesn't give a flattering image of true group chat within jabber. While the module works, it exposes a lot of the IRC clutter to the user because there is no real way to show them to the user. SamiHaahtinen
While it's important to ensure that no previous functionality is lost in a migration, it would also be good to keep an eye on what more there is to be gained. Collaboration can happen on more levels than a simple exchange of text messages and Jabber has a good track record as a vehicle for rich information. Audio conferencing, notetaking, whiteboarding, collaborative document authoring come to mind, see for example Coccinella and Buddyspace. (This usually meant that all parties had to use the same client. xmpp4moz, a project I worked on, removed the problem by using generic XMPP code on the client and moving real applications to the web.) This doesn't mean the pros quoted so far for IRC are any less relevant, but they'd probably be more useful as starting points than as goals. -- Hyperstruct