Negative priority

One of the things I mentioned in my XSF Membership application was my endless curiosity about negative priorities in XMPP.

When most people talk about XMPP, they focus on the Instant Message network thats built on top of the XMPP federated network. Some also focus on the aspects of application automation. But even this second group rarely dwells into the wonderful and mystic world of the negative priority.

For those out of the loop, the <presence> stanza you send at the start of the session to signal your availability has some child elements. The most common ones are <show> that tell the other users your status (like away, busy, and the rarely respected do not disturb) and <status> that holds your claim to fame on the "I'm smart and witty in 100 chars or less"-category.

The other standard attribute is <priority>. Priorities range from -128 to 127. If you omit it, your priority is set to 0. Servers use the priority to decide which of your multiple connections (usually called resources) will receive messages without a specific resource in the destination to attribute. So if you send a message to [email protected]/a_resource, then the message is delivered specifically to the resource a_resource, but if you send (as you should on the first message) to [email protected] then the server decides which resource will get the message based on the resources priorities. You can find the all the dirty details in RFC 3921, in particular section 11.1, paragraph 4.1.

The second part of the last paragraph is where things become interesting for negative priorities. If you send a <message> to my bare JID (without a resource), and the only resources available have a negative priority, the server will treat you as an offline contact and store the messages in offline storage.

So negative priority resources work as a non-chat connection, that you can use for other purposes, like automation or application-to-application communication.

The usual bots that you see online have their own JIDs and you talk to them over chat-based interfaces. But with negative priorities you can have a different kind of bot, one that connects with your own JID, but with a negative priority. To distinguish these two types, I'll call the second one an agent. It acts on your behalf inside the XMPP network.

Imagine that you write a agent that has access to your calendar and task list. Given that this agent also has access to your roster, you could use that as an access control mechanism to allow your buddies agents to consult your calendar, negotiate meeting requests based on a free time calendar, or even delegate a task to you.

Or another one: you have a agent running on each computer that you own, and you configure it to export certain directories. Again, you can use your roster group structure to define who has access to what. You can re-arranje your buddies in your main roster, the agent receives the roster push and immediately adjust his ACL.

The possibilities are pretty much endless and this is a area where very little work and study has been done until now.

But there are some road blocks ahead. The first one is that most clients out there don't deal properly with negative priorities. If a buddy of mine only has negative priorities, my IM client must show him as offline. Most clients right now, don't do that.

Worse: when I was trying this over the weekend, I was able to crash some clients (I could see them logging off and login back in continuously).

But that's ok. There was no reason (and right now, there still isn't a good one) for client authors to worry with this. Nobody was using negative priorities. And I'm sure most authors will fix this as time goes by.

Next up: communication with your agents.