Version 3.0.3:
- Fixed Twitter compatibility. (The API call used to get the following list was deprecated.)
- Twitter: Enable the show_ids setting to assign a two-digit short ID to recent tweets to use for retweets and replies (so you can RT/reply to more than just a person’s last message).
- Some other Twitter fixes/improvements.
- “otr reconnect” command and some other fixes.
- GnuTLS 2.12 compatibility fix.
- Include “FLOOD=0/9999″ in the 005/ISUPPORT line at login to hint the IRC client that rate limiting is not required. (Next step: Get IRC clients to parse it.)
- Other stuff too small to mention.

The second point in the changelog got me pretty excited. To appreciate this, let me give you some background. I’m an Identi.ca user first, Twitter user second. The main reason for this is the integrated XMPP support. I’d much rather drink from the fire hose, then wait for refresh intervals to give me notice dumps. I want the data live, as it happens, in real time. Twitter used to have an XMPP bot, but I guess they couldn’t scale it well enough, and ended up pulling it.

Anyway, with Identi.ca, when using the XMPP bot, you get the notice ID at the end of each “dent”. Something like this:

toros: !Ubuntu Cloud Portal: Zero to Ensemble in 5 mins http://goo.gl/J1Iby [76347696]

I can reply directly to that notice, rather than just replying to the last notice of @toros, by sending “reply #[notice_id]” to the XMPP bot. Then, everything stays in context on the website. Further, Identi.ca keeps a stellar view of contextual threads, as shown in this example, something Twitter could learn from.

However, with previous versions of Bitlbee, all you could do with Twitter was reply to the last notice, rather than a specific notice. This was frustrating, as other clients have been able to keep things in context if implemented correctly. Well, the recent change fixes that. Now, at the beginning of each message, there is a short two-digit number identifying that notice. This number is unique to your running instance of Bitlbee. Further, if a reply or retweet is sent to you, you can see which notice the reply is referring to, which makes it trivial to scroll through your back buffer to find the post you sent, in case you forgot.

At any rate, here’s a screenshot of Twitter in action with the new release. Notice the hilights, the notice IDs and the references to other posts. Pretty slick. Here’s how you set it up:

1. Upgrade Bitlbee to 3.0.3, using either your operating system repository, or using the upstream tarball.
2. Restart Bitlbee after the upgrade is successful.
3. From the Bitlbee window, disconnect from your Twitter account.
4. Type “account # set show_ids true” where “#” is the account number for your Twitter connection.
5. Reconnect to your Twitter account.
6. Profit!

If you still don’t have the notice IDs for each post, you may need to disconnect from Bitlbee entirely in your IRC client, and reconnect.

Now, the only thing left to do is reply to a notice. Use “reply #” to send an automated @-reply to that user, as follows:

< nixternal> [45->44] @AaronToponce if I am not on IRC much, I don’t need irssi much. Is bitlbee still being developed? Plus it doesn’t suit my workflow
< aaron> reply 45 oh yes, very active development. new release has much improved twitter integration that i really, _really_ dig
< root> You: [47->45] @nixternal oh yes, very active development. new release has much improved twitter integration that i really, _really_ dig

Notice that I just typed “reply 45 oh yes, …” and “@nixternal” was sent in its place. For me, this is a VERY welcomed feature, and Twitter sucks much less than it did before. But, not all is peaches and cream. After 100 notices scroll by your screen, the counter resets. This could be problematic if you wish to reply to an old Tweet that was several hours ago, because you were away from your computer. Using “reply ## foo bar baz” will result in sending the reply to the most recent ##, rather than the intended one, which may not even be the same user. And, if using the standard @-reply, the reply will go to the most recent post, which means you might be out of context. Still, I welcome the change, as it’s a massive improvement in my eyes over what was previous.

While Identi.ca is still my #1 (for other reasons than just the XMPP bot), Twitter has now become a new toy to play with, given these additions. Wilmer, my hat goes off to you my friend, you are turning out a spectacular product, that I absolutely love. Keep up the amazing work!

First, so you understand, Open Discussion Day started back 4 years ago when Ploum first blogged about showing support for open protocols, such as Jabber/XMPP (using Google Talk, jabber.org, and others). I’ve blogged about it in the past, even though I missed blogging about it last year.

You can start with by checking out the page http://www.opendiscussionday.org. There, you’ll find a wiki that has some information on how to get started with open communication platforms, protocols and software. Given the ways we communicate with each other on the Internet and elsewhere, it makes sense to advocate supporting these open platforms. Here’s a brief, non-exhaustive list of various open protocols worth checking out:

• Jabber/XMPP- Jabber/XMPP is probably the most successful open communication platform to date. According to Wikipedia, it has more than 50 million active users, mostly on the Google Talk/Gmail service. It’s supported on Windows, Mac and Linux. It’s a federated protocol, which means Jabber/XMPP can communicate across different domains. It uses SSL encryption by default, which means your communication is secure, and most of the clients are free, and solid applications.
• OMB- The Open MicroBlogging protocol was started in response to Twitter. Rather than being tied to a particular vendor for your status updates, Laconi.ca, now Status.net, launched and announced they would provide an open, federated, protocol for broadcasting your “tweets”, following others, and others following you. Identi.ca was their product, and it has proven to be very successful, and the open platform has sparked a number of other microblogging servers, all in tight communication. http://army.twit.tv, http://brainbird.net, and others are based on this code, and can all communicate together. Lastly, there are a number of microblogging applications that support Identi.ca, and the others. You can follow me at http://identi.ca/eightyeight.
• IRC- Internet Relay Chat is one of the older forms of open communication in this list, except for email. It uses TCP for the transport protocol, and optionally SSL/TLS for encrypting your communication. As with everything else is this list, IRC is federated, meaning connecting multiple IRC servers together, and communicating transparently. Freenode is probably one of the more common IRC servers for open source projects. OFTC, EFNet and UnderNet are popular as well. There are many IRC clients out there that can get you chatting on any number of different IRC networks at the same time. My personal favorite is Irssi, a text-based client.
• Email- The last, but definitely not least, however the oldest, and probably most ubiquitous. Everyone is familiar with email, and it’s rare to find people these days that don’t have an email address. It too is federated, meaning you can send an email from gmail.com to hotmail.com, without thinking about it. Many open protocols have been built around email, including SMTP, IMAP and POP, as well as their secure, encrypted versions. As much as the Internet would like to see email die, I personally think it will be around for quite some time. The only thing I would ask, is that people stop sending proprietary attachments to their message, bottom post, trim unnecessary cruft from the mail, and write in plain text (I think I might be reversing my stance on HTML email- we’ll see).

Of course, there are many closed discussion platforms and protocols, such as Twitter, Facebook, Skype and MSN/AIM/ICQ/Yahoo. It’s important to note that you don’t own your data on these services, unlike the ones I’ve mentioned above. You are subject to vendor lockin, and everyone else must use those services too, as they don’t communicate with each other. But, we’re about the open discussion protocols, not the closed ones, so let’s continue.

I’m sure there are many other open communication platforms that would be worthy discussing in this post. I chose what I feel to be the biggest and most successful of the open protocols. The future will tell what else we see in this arena, but right now all I can say, is we have a great deal of options for supporting an open protocol, many of which are doing very, very well. If you have other open communication protocols that you use, make sure you specify them in the comments, or add them to the Open Discussion Day wiki. For the record, I fully support all the open protocols/communication platforms, and you can find me on any of the protocols listed above.

Happy Open Discussion Day, 2010!

See you online!

Well, it’s time to ditch the legacy IM protocols in favor of Open Standards, such as IRC, XMPP/Jabber, SIP/SIMPLE and others. Of course, this means making a sacrifice to potentially lose friends and family on your roster. However, at the same time, it’s an opportunity to advocate Free Software to your friends and family, and encourage them to register open IM accounts.

May 19th has been named Open Discussion Day. This is the day, if you have not already, to ditch your legacy IM accounts for good. As it sits, you have 11 weeks to advocate to friends and family, letting them know of your decision, and what you can do to help them make the switch as well.

Lastly, I’m looking for some volunteers to help me manage Open Discussion Day this year. I’m looking for folks willing to do a little advocacy (marketing, blogging, websites, wikis, etc). If interested, you can find me in our official channel on Freenode, #opendiscussion.

First, what is Open Discussion Day? Open Discussion Day is all about supporting open protocols for communication. The official day is May 19th, the birthday of Robert Bugg Quattlebaum Jr., who announced that he was dropping legacy IM for just Jabber. As such, Lionel decreed May 19th Open Discussion Day with May 19, 2006 being the first.

The idea of Jabber, the cornerstone of Open Discussion Day, is simple. When email was started in the early 60s, the idea was that people could connect to each other, regardless of domain, location or date. As such, over 40 years later, email is a crucial part to everyday communication. Can you imagine john@example.com only being able to send mail to the example.com domain? Of course not. John should be able to send email to any user under any domain regardless of the daemon powering the email server. Instant messaging should be no different.

Jabber was setup with the same concept. When Jeremie Miller set out to create an instant messaging protocol, he wanted any user under any domain to be able to connect to any other user under any other domain. The result was the Extensible Messaging and Presence Protocol, also known as Jabber. What’s cool about Jabber, is any Jabber server can be setup under any domain, unlike the proprietary IM protocols, such as MSN, AOL, ICQ or Yahoo!. Can you imagine being able to setup an MSN instant messaging server for your domain? Microsoft wouldn’t have it. Jabber on the other hand is different. Setup a Jabber server for your local LAN or setup an external server to connect you to the outside world, such as I have done under the aarontoponce.org domain.

So, what’s the point of Open Discussion Day 2008? Drop your legacy IM services for Jabber, of course. Jabber, in my opinion, will be one of the most influential communication tools of the new millennium. With Google supporting Jabber and AOL testing it, we’re already starting to see the protocol take some serious notice by the big online players. It is even estimated that Jabber has more users now, second only to AOL, than any other protocol (according to Wikipedia). With the transports feature of Jabber, Jabber users can even use their legacy IM accounts through their Jabber account. Thus, only connecting to their Jabber server, which connects them to the legacy servers, optimizing the total outreach of your buddy list. However, while Jabber supports this cool feature, Open Discussion Day is about dropping those legacy accounts completely.

Join us in #opendiscussion on Freenode if you’re in favor of dropping legacy IM for Jabber.

First, we need to connect to testing.bitlbee.org. This server supports SSL, which I would prefer to connect with, so I’ll be using that in the example. So, in irssi, let’s connect:

/connect -ssl testing.bitlbee.org 6668

This will make the connection, then open a “&root” window for you to setup your account(s). Let’s do that, just for simplicity sake. First, we should register ourself with the server, so if we need to login again, we can identify: In our &root window in irssi:

register password

Where password is a password of your choice. Now, if you ever disconnect, you can reconnect your accounts with just a “identify password“. Now that we’re registered, let’s add our Jabber account. For me, I’m running my own Jabber server, so I’ll use that for my example:

account add jabber aaron@aarontoponce.org password

This will connect to the aarontoponce.org Jabber server with my password, whatever that may be. At this point, you should save your information before you go any further:

save

Now, let’s connect:

account on 0

The first account you add will be the 0th account (we’re counting like normal here, starting with zero), the second account you add will be account 1, and so on. Ok, now you’re connected, how do you join a Jabber MUC room? Well, on the testing.bitlbee.org server, we have the ‘join_chat’ command. The syntax is simple: “join_chat “. Let’s see how we can connect to the Jabber MUC on conference.jabber.org:

join_chat 0 jabber@conference.jabber.org &jabber atoponce

0 is the account number that is referenced to the account I added earlier. Now I’m connected to a Jabber MUC, running in Bitlbee, running in irssi, all behind screen. In other words, no more joining and leaving the MUC room. As long as my server is running, I can keep my irssi client going, and keep tabs on all the back logs in case I want to reply to something.

This is clearly not the case. Every user who signs up for a Google Talk account is using the Jabber protocol. However, if they already have an AIM account, they can give their login information to Google, and Google will connect to the AIM servers via the method of transports- a long supported featured in Jabber. With my impression of users having the ability to choose, this lead me to the conclusion that Google was hindering the progress of Jabber by giving users another protocol to choose from.

Think of the following analogy: You are a Chevrolet car dealer, and have been selling Chevrolet cars for years. Then, all of the sudden, you decide to start selling Ford vehicles as well. You do this with the hope that you will bring more business to your dealership. Chances are good that you’ll sell more total vehicles. However, you will sell less Chevys than you were prior. This is because you are giving your shoppers a choice. As such, you are hindering overall Chevrolet sales. I was under the impression Google was doing this with Jabber and AIM.

Dax Kelson gave me a better analogy of what is actually happening. As a language institution, you sell Spanish courses. You decide now that you would like to sell Portuguese courses. However, the Portuguese package is a separate package that is added on to the Spanish package. In other words, every new customer still purchases your Spanish classes, but now they can also purchase Portuguese as an option if they would like. This is more fitting to what Google is doing. Every customer gets a Jabber account, however, they can add AIM support now too if they would like.

As with all assumptions, we can see where not clearly studying out the details takes you. In my case, public humiliation. I’m okay with that. I seem to do this to myself a lot. You would think I would learn my lesson, but I guess old habits die hard. At any event, I apologize.

Now, let’s look at why this is a good thing, versus a bad. First off, every account uses the Jabber protocol. End of story. I’ve known this for some time, even having to explain it to well established geeks in the community thinking Google Talk and Jabber are separate. They are not. Google Talk is a brand that uses the Jabber protocol. Even if you decide to give Google your AIM information, and connect to your AIM account with Google Talk, you are doing so via the transport feature of Jabber. So, let’s look at this transport feature.

One of the philosophies of Jabber is that anyone should be able to run a Jabber server under any domain. This means that I shouldn’t have to connect to a vendor-supplied server, such as MSN or Yahoo. Instant messaging should be like email, allowing any domain to communicate to any other domain. So, I have a Jabber server running under the domain of aarontoponce.org which should be able to communicate to Google Talk users using their gmail.com domain, as well as jabber.org domain users, and so on. Decentralized server-to-server communication is the main philosophy behind the Jabber protocol. So, how does AIM fit in?

With transports, the server that you are connecting to can, and should be able to connect to *any* IM server. This includes the proprietary networks and protocols, such as AIM, MSN, Yahoo, GaduGadu, Novell Groupwise, ICQ and more. This allows us to connect to our family and friends regardless of what protocol they are using. Of course, I would love to see them using Jabber instead of MSN, for example, but I can’t force them to switch, leaving behind their other contacts. So, using my Jabber account, I can use the server to connect to any server regardless. Because I support Jabber, and would love to see it’s global acceptance, I also support transports. Which means, I support the initialization of Google using AIM in their Google Talk product. Google has brought so many to the Jabber protocol, it would be silly to judge them harshly.

While I don’t support the AIM protocol, and don’t have an AIM account, I understand why Google made the move they did with their Google Talk product. The decision is to bring more users to Google and connect people to more of their friends and family without alienation.

• Multiprotocol clients are a curse for interoperability.
• Multiprotocol clients hinder adoption of open standards like XMPP and SIMPLE.
• Multiprotocol clients even hinder their own adoption!
• Multiprotocol clients explain why “the Firefox of instant messaging” does not yet exist.

Please read the following article for support of these arguments. All the more reason why I left Google Talk for a fully functional XMPP implementation on my own server.

With Open Discussion Day coming around the corner here in a few months, begin supporting Open Standards now by switching to Jabber/XMPP and ditching your proprietary protocols- including Google Talk. I highly recommend using jabber.org for all your XMPP needs. Let your family and friends know early that you are making the switch, and encourage them to do the same, so when Open Discussion Day is here, it won’t be so difficult to switch. Instant messaging should be open like email- allowing any server to talk to another without the vendor lockin.

So, Google, if you’re reading this, I’d advise opening your implementation of Jabber, and ditching AIM support. You’re only making the playing field worse, and you’re tarnishing your reputation as a company that is not evil. As far as I’m concerned, Google Talk is just another proprietary IM service now, and you don’t get my support.

For one, why message employees internally using a solution that leaves the local network? With ICQ, and other legacy protocols, such as MSN, and most likely this merger with Microsoft and Parlano, your message leaves your local computer to the remote servers, which then identifies the account that the message is intended for, and sends it to the user. If the recipient of the message is in the same corporate network as the sender, wouldn’t it make more sense to have a local instant messaging server, this keeping all chatting and data internal? Especially if that chatting was of any sort of sensitive nature? Naturally.

The second thing that bothers me about corporate instant messaging is the lack of security. It would seem to me, that if a business needed to use instant messaging, and the messages were leaving the network to the outside world, wouldn’t security be the primary concern? You would think so, but apparently, it’s not so. Sure, with 3rd party plugins, and certain IM clients, security via client-to-client encryption can be enforced. But is it happening? Why not just implement a protocol that uses encryption by default, like Jabber? Then there is no need to rely on certain clients or 3rd party plugins to keep the messaging secure. It’s already taken care of.

So, this question goes out to those 85% of businesses using instant messaging. When will security be your primary concern with regards to instant messaging? In other words, when will you recognize, if you haven’t already, that setting up in-house Jabber servers is superior to any other solution for corporate IM? Hopefully, you take that question seriously.

Now, it’s the tools that makes the business productive. If a certain tool meets the needs of the business better than other tools do, it’s an obvious choice. But what tools out there in the world of IM make a business productive? Let me rephrase. What implementations in the world of IM make a business productive? For example, there are whiteboards, video chat, voice chat, multi-user chat, and file transfer to name a few. Can Jabber meet these needs to help increase the productivity of your business? Let’s take a look:

• Whiteboards are the ability to draw on a virtual surface, thus enhancing the collaboration of those involved. Rather than everyone meeting in a central location around a physical whiteboard, virtual whiteboards, accompanied with chat (text, voice or video) can reach the same goals. There is only one client that I am aware of that meets this need over a Jabber nework. It is Coccinella, a Free and Open Source client that also supports voice chat over the Jabber network. It’s cross platform compatible, as well as easy to setup and use.
• Video Chat is becoming ever more popular these days in business. I have worked at a company where video conferencing was crucial to their meetings, and the success of the business. Twice a day, once in the morning, and once in the afternoon Monday through Saturday. I have seen and heard other businesses doing the same. In fact, the company that I work for currently, introPLAY, uses video chat on occasion as needed. Can this be done over a Jabber network? Most definitely! Ultimately, you just need a client that supports video and Jabber accounts, such as iChat. There are a few of these clients out and about.
• Voice Chat (VOIP) is the wave of the future for both land line telephony and messaging presence. It’s one thing to type from one person to another in plain text, however, it’s completely another to hear their voice. More can be said in a shorter time, and sensing voice tone can be crucial where the same in text could be misinterpreted. Several clients support voice over IP, including the Coccinella client mentioned above. Extending VOIP further with Jingle or Asterisk installations bring full blown telephony to the office with no price at all, and great support.
• Multi-user chat (MUC) can be crucial when offices are separated, or meeting in person won’t suffice. Of course, getting things done at your desk during a MUC session can make all the difference in the world increasing productivity. Some offices have found that local IRC meets the need just fine, of which several clients that support Jabber accounts also support IRC. However, many Jabber clients support MUC over Jabber without the need for another tool. My favorite being Gajim.
• Lastly, file transfer can be a nice tool to those who don’t have access to SCP, FTP or even email attachments. Sending files, be it documents, images, audio, video, binaries, zipped, archived, whatever, can make getting what needs to be shared easy. Every client that I have ever used supports file transfers with ease. This should be a no brainer.

Again, it’s the proficiency and effectiveness of a company that’s going to make it successful. With the right tools, especially in the instant messaging department, businesses should be able to get the most done with a minimal amount of effort. Jabber makes this easy. So, while Microsoft and Parlano may be “innovating” the IM space, there are tools already there to utilize. Besides, who’s going to complain about free?

So, with that said, who do you turn to when the MSN servers go down? What if you are having login problems or can’t get your roster to pull up? What happens when your instant messaging account is getting bombarded with spam? Question after question, users are faced with this often. And who do they turn to? Does MSN have a support channel that you can turn to if you’re having troubles? Does AIM? ICQ? Yahoo!? XMPP does, and it rocks!

First off, before I continue, I realize that this is not a unique aspect about XMPP or Jabber. Many Free and Open Source Software solutions have active and willing-to-help communities. Even proprietary solutions have support channels. However, I find it ironic that Jabber seems to be the only IM service with a decent support backbone. Specifically, http://www.jabber.org. The rest of the IM services lack this considerably, and as such, are losing members.

So, let’s look at these support solutions. Let’s take my example that I had today. I requested SSL certificates from www.xmpp.net to install on my Jabber server. I requested them a few days ago. During the process, I received the SSL key and the SSL certificate request, but not the certificate itself. I was told during the process, that it would take up to 6 hours to receive the cert. Well, 3 days later, I’m wondering what happened. I turned looking for support.

I had a few options available to me, which readily apparend, and easy to execute. I could add Peter Saint-Andre to my Jabber roster, leader of the XMPP Federation, and ask him directly, send him an email, or join a MUC (multi-user chat) on jabber.org, and see if they had any ideas. Well, I chose to add St. Peter to my roster, and ask him directly. He was more than willing to find out what had happened to my certificate, and get the matter taken care of straight away. The support was incredible! I received my certificate, installed it to my server, and am now one satisfied consumer.

Sure. There are toll-free numbers to call, trying to get an issue resolved. They are famous and litter the phone lines. But who wants to talk to a robot or push buttons all day? I certainly have better things to do with my time then waste it talking to outsourced help, only to regurgitate everything again to an actual representative 10 minutes later. Online support, especially IRC or MUC is far superior to toll-free numbers and automated messages. Just ask anyone in #xmlounge on irc.xmission.com how effective online support is.

Now, is this the case for every Jabber provider- say GMail? Not necessarily. I’m not that ignorant. However, is this NOT the case for every legacy/proprietary provider? It is, and that’s my point. Community is much more powerful than any mega-corporation out there. Always has. Always will be. And it should be priority #1 for any user to turn to a provider that has *great* support options. Again, jabber.org is one supch provider. There are many others.

Encryption is one of my most passionate topics. I’ve blogged about it several times, and I’ve given encryption-related presentations many times over. I don’t consider myself an expert, but I do feel that I have a good grasp since being introduced to it in 2001 when generating my GnuPG key. Because encryption is such a part of my everyday life, it’s important to me to use a protocol that takes advantage of it natively. That is yet another reason why I chose Jabber and the XMPP spec. Let’s look at it in more detail, and paint a scary picture while we’re at it.

First, the scary picture. Imagine that you’re at work just plugging along getting the things done that you need to get done. At work, you have to use ICQ to keep in contact with other coworkers and even clients outside. During the day, you bang heads with one of your coworkers. You don’t agree with how she is executing a project, and she’s just as upset with your style of execution. Now, both of you are fuming at each other. This coworker you’ve never really gotten along with, and she has some friends who back her up no matter what. Knowing that ICQ messages are transferred over the wire in plain text, you pull up Wire Shark, and sniff out all the ICQ packets watching what she is saying about you to her friends. Yes, you can see everything in clear text after cleaning the TCP dump.

Now, I don’t condone sniffing out packets on the corporate wire. Talk about getting fired if you get caught (unless you are IT staff yourself). But, the lesson needs to be taught. Using conventional packet sniffing tools, you can sniff out usernames, passwords and the entire conversation on IM protocols that are not using encryption. This includes MSN, AIM, ICQ, Yahoo! and most others. Talk about a security hole. Anything that is not encrypted on the wire, in my book, is a security hole. So, using IM protocols that do not encrypt their traffic, is just asking for trouble.

This is where Jabber steps in. When the Jabber protocol was first introduced, SSL was a top priority. Every account that connects to a Jabber server should be connecting via an encrypted stream. Initially, as mentioned, SSL was the default encryption method. Now, with the introduction of TLS, Jabber now supports TLS as the default. Some Jabber servers run both SSL and TLS for maximum backwards compatibility. In either case, you can be rest assured that your traffic is 100% encrypted between you and the server. This means no amount of energy put into Wire Shark or other packet sniffing tools are going to be an effective means of getting the message text or account info.

Unfortunately, all the encryption and decryption happens in two instances- at the client and at the server. This means that both the computer your Jabber client is installed on and the server that you have an account with could hold logs in plain text of your conversations. To illustrate an example, if you use Gmail for your Jabber IM, there is a “Chats” link in the Gmail interface. By default, Gmail logs all of your chats, and stores them in your Gmail account (you can turn this off, by the way). They are stored in plain text after the server has decrypted the messages. To me, and luckily the core XMPP team, this is troubling. Why can’t we have a client-to-client encryption method, rather than just client-to-server and server-to-server encryption (yes, server-to-server communication is also encrypted on the wire)? That’s the exact question that is being asked, and hopefully in a future release of the XMPP core spec, this will be a reality. However, at least you’re encrypted on the wire, and a bothered employee can’t sniff your packets seeing what you are saying about him to your friends.

The XMPP specification on encrypting data is just scratching the surface. Many clients include 3rd party plugins or tools to make client-to-client encryption a reality, regardless of protocol. I have also blogged about this before, hoping for some sort of standard in this arena. However, even these tools are just encrypting message text, leaving the IP in the packet exposed. Imagine encrypting the entire packet from top to bottom, leaving no rock unturned. Again, this is being worked on with the core XMPP team.

Because Jabber is decentralized, as mentioned in my previous XMPP article, installing Jabber in a local intranet is another way to achieve security. Not only encrypting packets, but isolating your packets is another level of security that most don’t think about. Using legacy providers means that you need to rely on two things for IM to be successful: your Internet needs to be up and running, and the IM service needs to be up an running. Utilizing an intranet installation means you don’t need to rely on others to have a working IM session. You are in control, and to me, this is a level of security that you just can’t get any other way. Why send packets out to the Internet when they’re coming right back into your network? Jabber makes this possible.

Hopefully, this is the straw that breaks the camel’s back when it comes to convincing anyone to move to Jabber and ditch their proprietary accounts. Security just makes sense, and why other services haven’t utilized it is beyond me. Coupled with 3rd party plugins and corporate installs, you can make your Jabber service pretty tight security-wise. And, to put the icing on the cake, with the XMPP team working on tightening that security further, Jabber should be the only IM you or anyone else uses. It just puts things into perspective, no?

First, I want to get the gears moving a bit in your head. Think about this for a second. When your send an email to you friend, can you only send him an email if he is using the same email provider as yourself? In other words, if you are using Gmail for all your email needs, can you only send an email to other Gmail users? Of course not! Don’t be silly. You can send emails to people regardless of who their email provider is, whether it be Yahoo! mail, Hotmail, or some company email, and they can reply or forward as necessary to other people regardless of their provider. So, I have a question then: why do instant messaging providers make you keep rosters of only those who have the same provider? Why can MSN users only send messages to other MSN users? Why can Yahoo! users only send messages to other Yahoo! users? AIM? ICQ? See the problem? The reason being, only MSN users can connect to “official” MSN servers. Same with all the others. It’s called vendor lock-in, and well, Jabber is different.

Not fair, is it? I have family that only have MSN accounts, thus, they only chat with other MSN people. This is troublesome, because I won’t use proprietary IM protocols, so, as such, I can’t chat with my own family unless they were to register Jabber accounts (which, actually, a few have). Yet, I can send an email to them just fine. See, email is completely decentralized, while instant messaging isn’t. Jabber solves this problem by becoming completely decentralized just like email. Then, my family can have Jabber accounts with Gmail, while I run my own Jabber server at home, and I can chat with them with no issues. In fact, looking at my roster, the majority of contacts are using Gmail for their Jabber service, but there are also jabber.org accounts, a livejournal account, and a few in-house server accounts. Isn’t this great? Regardless of Jabber provider, I can chat with anyone.

The magic behind this decentralization, is a service called “server-to-server”. When I register an account, say at jabber.org, I can add anyone to my roster, regardless of their provider. What happens, is during the authentication, my provider (jabber.org) contacts their provider (say, gmail.com) asking for the contact’s information. Their provider then notifies the user that an authentication is taking place. If the user approves, their provider contacts my provider saying all is well, and the user is then added to my roster. Think about this for a second. One server is talking with another server, even when out of domain. Would MSN do this? Yahoo!? AIM? ICQ? No way.

I know what you’re thinking, for those of you who are proprietary IM users. Even though Jabber is decentralized, you can only send messages to other Jabber users, thus, still vendor locked-in to Jabber. You can’t send a message to MSN or ICQ users- only other Jabber users. While this is true, this isn’t Jabber’s fault, rather, MSN and ICQ are keeping Jabber from communicating with their servers. Think of it this way: you have a Gmail account, and send an email to a Hotmail user. The email bounces, saying that you are not a user of Hotmail, thus, you cannot send email to other Hotmail users. You would need to register an account at Hotmail to send email to other Hotmail users. Look at how absolutely draconian that is! Email is completely decentralized, yet, Hotmail wants to lock their own users in. That is exactly the game being played in the field of IM. Jabber has solved the issue of vendor lock-in opening up the specification, and making IM completely decentralized, and yet, certain providers refuse to play along. So, for the time being, you can only send messages to other Jabber users, but I have a feeling, given the sheer number of Jabber accounts, that this won’t last for long.

When I heard about the decentralization nature of Jabber, I was totally excited. To me, I thought, this would open up the IM playing field, and if providers didn’t join in, they’ll sink like the Titanic. Well, my thoughts haven’t been too far off. Since the inception of Jabber, according to Wikipedia, Jabber is listed second in a raking of the number of users, trailing only behind AOL. About 90 million Jabber users are estimated. Given that article, this means that nearly a third of all IM accounts are Jabber accounts. I suspect that given time, more and more will switch to Jabber, as I have, and ditch their proprietary cousins. Wouldn’t it be great, if there was completely and totally decentralized IM just as there is email? Hopefully, my XMPP articles will convince you that XMPP/Jabber is superior, and for you to register a Jabber account at a provider of your choice.

In my last XMPP post, I talked about priorities, the single #1 feature in a Jabber client that I look for. If I can’t change the priority number to suit my needs, then I’m not interested in using that Jabber client (Pidgin devs, paying attention?). Well, priorities are cool and all, but they don’t do much without our next Jabber feature- resources.

As I mentioned previously, the XMPP specification allows multiple simultaneous connections. However, when we are connected more than once to our Jabber provider, the server needs a way to tell the connections apart. This is where resources come in. Some providers automatically set a unique resource. However, while definitely a solution to the problem, I actually prefer the ability to change the resource myself, rather than have my provider do it for me. Okay, so how do I change a resource, and why would I want to?

From client to client, this differs, but essentially, the process is the same. When creating a new account, or modifying your current account, there should be a box labeled “Resource”. Change this to fit your needs. As I mentioned earlier, the server needs to tell your multiple connections apart, so, the resource always needs to be unique. If you try connecting a second time, and your immediately disconnected, check your resource. Chances are, it’s conflicting with a connection already made with the same resource name.

Most clients will auto-fill this in for you. For Gajim, the resource is already set to “Gajim” by default, “centericq” for the CenterICQ client and “bitlbee” for the Bitlbee client. As mentioned, I prefer to change the resource to fit my needs. See the screenshot of my Gajim client below:

As I mentioned earlier, some providers prefer to set the resource for you, without your ability to change it, or, you’re given the false sense that your changing the resource, when in fact, a random string of characters called a hash, are being appended anyway. For example, the Google Talk devs have taken this stance of appending a hash after your resource name. The hash is randomly created upon connection to ensure that no two resources are the same. The motivation behind the idea is that lay users will not be familiar with resources and priorities, so the client takes care of everything under the hood. Where the development falls short, is not giving the ability for those who know what they’re doing, the flexibility to change their resource and priority. This is why I don’t use the Gmail.com Jabber service, as I don’t want random resources set for me.

Why change your resources? What’s the big deal? Well, again, we need unique connections for each connection. On the flip side, however, using a resource can tell the users in your roster your physical location, like “Home”, “Work” and “School”, your operating system such as “Mac” and “Linux” or the hostname the client is installed on, like “hercules” and “athena”. There are a number of reasons why you may want to have the control over your resource. Why change the resource? Because you can.

Coupled with priorities, this makes XMPP a pretty powerful reason to switch from your old proprietary IM protocols to Jabber. XMPP gives you the flexibility you need to establish your presence online, rather than just connect a dummy client to a dummy service hoping for the best. As I’ve just recently learned, AIM allows multiple connections, but when someone sends a message to you, it’s sent to every connection made. In my opinion, this is sloppy. XMPP/Jabber cleans it up very well. And we’ve just reached the tip of the iceberg. There are more reasons to switch than you can shake a stick at, and I plan on covering every last one of them, hoping you’ll see the reason to switch to the single greatest IM protocol around.

UPDATE: I have bee corrected by Evan Schoenberg about Pidgin and other clients based on the libgaim/libpurple libraries. These clients do not append a random hash string after the resource name as I thought was happening. Rather, this is a provider issue, specifically, for Gmail.com users. However, I still see no place to change the priority to fit my needs with these clients, such as Gaim/Pidgin, Adium and others. Bitlbee just recently changed their Jabber code to allow such functionality. Also, it has been brought to my understanding that Jabber providers will be setting resource strings in the upcoming XMPP specification. I am unclear of the details, but apparently, it is to fill a security hole with the client setting the resource string. I’ll provide information when I understand the changes and get more details.

Okay, so with that out of the way, I want to talk about one of my most passionate topics- XMPP. I hope with the goal of these upcoming series of posts, to convince my readers why XMPP is a superior protocol to the rest. When all is said and done, there should be no doubt in your mind why you should be using XMPP as your primary method of IM communication. To start, I want to talk about priority.

Before I begin, however, why XMPP and not Jabber? Well, in reality, they are one and the same, and I don’t put preference in using one term over the other, as long as they are being used correctly. But there are subtle differences. XMPP is the core protocol for Jabber, which is the wrapper, for lack of a better term, that is used for Google Talk, Jabber.org and other Jabber servers. Jabber, rather, is used to refer to much more than the protocol. Jabber is a company, server daemon and an open source application. XMPP is just the engine under the hood. So, from here on out, for simplicity sake, and clarity, I’ll be referring to both XMPP and Jabber as “Jabber” throughout this post, and the rest of the series.

With that bit out of the way, let’s discuss the #1 feature, in my opinion, about Jabber, and that’s priority. Let’s create a small scenario. Pretend that you are using ICQ for all you instant messaging needs. When at home, you stay logged in, chatting with your friends and family keeping on touch. Then, you go to work, and login to your ICQ account again. What happens? You are logged off at home, and logged in at work. In other words, you can only be logged into a single instance at any given time with ICQ. Same holds true for most protocols: MSN, AIM, Yahoo! IM and others.

Now you leave work. You log off of your computer, and head home. Because your login at work logged you off at home, and now you have just logged off of your computer, you are no longer logged into your ICQ account. If your client supports reconnecting, then you may be. However, if you are not logged in, what happens when your friend or family member wants to get in touch with you? Sure, they could call your cell, or send you and email. There are probably numerous ways to get in touch, but why be limited with your IM client and provider? If I want to be logged in 24/7 regardless of location, I cannot do this with ICQ, or others, very easily. Fortunately, Jabber makes this easy.

First, Jabber supports multiple connections to your provider, regardless of location or client. This means that you could stay logged in at home, go to work, and login a second time, keeping the connection at home alive. Regardless if you logout at work or not, you will always be connected at home (unless your Internet dies, or other environmental circumstances). Cool, eh? You can be logged in at home, work, school, your friends house, and home again. You want to be connected with family and friends, there is no problem with Jabber.

However, I have a question. Say you are logged in at home twice at your laptop and desktop, as well as being logged in at work. So, you are logged in 3 times. Now, your friend wants to send you a message. Where does it go? Luckily, Jabber addresses this issue. On each connection, you can set a priority number. The highest priority number gets the message. Consider the graphic below (shamelessly borrowed from O’Reilly) which shows a sender and a receiver. The receiver is logged in twice, once on his laptop with a priority 1, and once on his desktop with a priority 2. The desktop receives the message.

So, if your laptop connection had a priority of 5, your desktop connection a priority of 15, and your work connection a priority of 8, then your desktop would get the message, as it has the highest priority- 15. Easy, no? Wherever you are, you want to make sure that that connection has the highest priority out of all your current connections. That way, you’ll get any and all messages that are sent to you. The highest number that you can have is 127, and the lowest 0.

So there you have it. My #1 reason why you should make the switch to Jabber for all your instant messaging needs- changing priority. Can you do this with your legacy protocols? I think not. For me, I run an always-connected centericq in screen on my server. The priority is low at 5 and set to always be away. I use this, as when I’m not at home or work (say in commute), and someone wants to send me an IM, I’m always available, and will be able to retrieve the message as long as I have access to an SSH client. When at home or work, I’m logged into Gajim which is set to a higher priority, to ensure that I receive the message to my current location (home is usually set to 10, and work to 15 (in case I forget to logout of home)). If you check my presence at any given time, usually, you’ll see me logged in twice.

Download here.