Image of the glider from the Game of Life by John Conway
Skip to content

Why XMPP Part 2- Saving Your Resources

I try to get creative with my post titles. I think I failed at this attempt.

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:

gajim_resource.png

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.

{ 10 } Comments

  1. Aadaam using Safari 419.3 on Mac OS | July 13, 2007 at 9:36 am | Permalink

    Distinguishing resources by resource strings will be deprecated in the upcoming version of XMPP.

    As for the resource hash appended to the end, it's probbaly not pidgin's fault, but it's a GTalk "feature": in core XMPP standard (rfc 3920-21), it is written that a server CAN force a resource ID, and so does google.

  2. Peter Saint-Andre using Firefox 2.0.0.4 on Mac OS | July 13, 2007 at 10:39 am | Permalink

    @Aadaam: It is NOT TRUE that distinguishing resources by resource strings will be deprecated. However, we are going to recommend (but not require) that servers generate resource strings on behalf of clients -- there are some security concerns related to client-generated resource identifiers.

  3. Jelmer Vernooij using Epiphany 2.18 on Debian GNU/Linux | July 13, 2007 at 2:30 pm | Permalink

    Just to clarify: BitlBee has never used libgaim/libpurple. It was based on an older version of gaim, but except for a major part of the oscar implementation, it doesn't contain any of the gaim code anymore. The Jabber implementation was written from scratch.

    Other than that, keep up the XMPP blog post. They're an interesting read!

  4. Askrates using Firefox 2.0.0.4 on Ubuntu | July 13, 2007 at 4:12 pm | Permalink

    I really like the idea of being able to set resources manually. However, it just occurred to me after looking at your screenshot that most people would be absolutely clueless when presented with a box marked "resource". It can be misinterpreted very easily.
    I suggest hiding options like this under an "advanced" tab, or at least doing something to make it more usable.

  5. Bogomips using Firefox 2.0.0.4 on GNU/Linux | July 14, 2007 at 4:40 am | Permalink

    @Jelmer
    But isn't one of the advantages of resources the fact that you can add someone to your list with someone@someserver.com/work and messages sent to that person would only be delivered to the client that had the "work" resource set?

    Wouldn't server side (or even client side) random resource string generation take away that advantage?

  6. Evan Schoenberg using Safari 522.12 on Mac OS | July 15, 2007 at 7:29 am | Permalink

    Pidgin does allow you to specify the resource and to specify a priority associated with your status.

    As aadam indicated, *every* Google Talk connection is going to have a server-generated or server-modified resource name; this has nothing to do with the client in use. Pidgin and all other libpurple clients (including Adium) allow specifying of the resource you want to use.

    It'd be nice if you'd edit your post to indicate that Pidgin, Adium, and other clients are just as capable in regards to resource and priority as the other XMPP clients you describe. As it is, it is highly misleading.

  7. Aaron using Firefox 2.0.0.4 on Ubuntu | July 15, 2007 at 7:37 am | Permalink

    @Evan- Quite to the contrary. I see no where within the client where I can change the priority to fit my needs. The first connection gives a priority of 0, then each subsequent connection increases by 1. This is all generated in the client itself. The same is true for libgaim/libpurple clients.

    Upon further investigation, you're right about the resource. I can change this when I want, and only the Gmail.com provider appends the random hash, rather than the client. This is good news. At least that is something in the right direction. I have updated the post to reflect the correct nature of these clients.

  8. Jelmer Vernooij using Epiphany 2.18 on Debian GNU/Linux | July 15, 2007 at 5:15 pm | Permalink

    @Bogomips
    BitlBee doesn't have randomized resource strings at all. I agree with Aaron's comments on being able to set resources and BitlBee fully supports customizing resources or directing messages at specific resources.

  9. Hoàng Đức Hiếu using Firefox 2.0.0.6 on Ubuntu | August 11, 2007 at 12:48 am | Permalink

    @#5 by Askrates:

    Fortunately Gajim has a really helpful toolstip for the Resource input box, if the user doesn't find it too lengthy to start reading.

  10. Kent using Konqueror 3.5 on GNU/Linux | March 23, 2008 at 1:09 am | Permalink

    Just found this blog while looking for an explanation for something.
    As of today, I noticed gtalk is now coercing the hand-coded resource ID into a manipulated one with the random signuture, completely invalidating the whole notion of it representing a distinct endpoint, and now totally messing up my PSI conversations. ( psi treats every resource identifier as a distinct client/person so one can have 2 conversations with the same person via different resources simultaneously as it only uses the priority to identify which entity to make the primary connection to, not to relay every separate message )

    Personally I think its a shocking shame google should so blatantly mess up the Jabber protocol like they have, its as bad as Internet Explorer back in the day adding their own custom weird random non-standard extensions which as we see now, have held the internet back from developing properly. ( ie: their non-standard file transmission system completely incompatible with the standard )

    I'm going to have to start trying to push people from gTalk onto /real/ Jabber clients just to avoid the pain google is introducing.

{ 1 } Trackback

  1. [...] “Why XMPP Part 2- Saving Your Resources”, Aaron [...]

Post a Comment

Your email is never published nor shared.

Switch to our mobile site