Pedro Melo is wondering about negative presence priority:

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.
[Negative priority]

I agree with Pedro that it’s not clear how clients should render negative-priorty presence. This post outlines one possible approach. Just so that we have some concrete protocol to discuss, consider a PBX that injects the following presence on your behalf:

<presence from=“joe@example.com/phone“>
  <priority>-1</priority>
  <status>On the phone</status>
  <show>away</show>
  <c xmlns=“http://jabber.org/protocol/caps“
     hash=“sha-1“
     node=“http://jabber.com/bots/pbx“
     ver=“PwgGa/jZx9sUeueZsjT/xBlJfqo=“/>
  <reach xmlns=“http://jabber.org/protocol/reach“>
    <addr uri=“tel:+1-303-555-1212“/>
    <addr uri=“sip:joe@example.com“/>
  </reach>
</presence>

Let’s step through this bit by bit.

• Priority: -1, obviously, since that’s what we’re here to talk about. We would rather have messages be sent offline than come to this resource. It’s never the most available resource for this user.
• Status: We’re off-hook.
• Show: use the away icon. Which actual image should we show, though?
• Entity capabilities: a pointer to information about the software that sent the presence. The node URI is a semantically-relevant descriptor of the client, and the ver attribute is a hash of the features and other information about that client.
• Reach: how else can this device be reached? In this case, a POTS phone number and a SIP URI. This namespace is from the deferred XEP-0152, and is just here to give a little more flavor to the presence.

Assume that this is the only presence for this user at the moment. Now, imagine the client of a subscriber to this person, with a user interface that looks something like this:

This person is seeing me as offline for IM, and my phone is off-hook. There is an image for each of my negative-priority resources; presumably when I mouse over the image, something interesting will pop up, like “On the phone”. If I click on the image, I might be given options like “Call”, which could use the tel: URI in the reach section. One potential issue is what to do if there are too many negative-priority resources - that’s something for the UI designers to deal with, though.

But, how do we actually decide what image to show? There are several ways:

1. Hard-code a mapping between the (caps node, show) pair to a resource in the subscriber’s client. This would work, but is obviously limited for the future.
2. Hard-code a mapping between the (caps identity, show) pair of the device and a resource in the subscriber’s client. This is similarly limited.
3. Do an IQ to the publisher to ask what it’s current image is. With this one it’s hard to know when to cache, so scalability suffers.
4. Use one of the avatar XEPs (like 0153), and include an image reference in the presence. This doesn’t work because the avatar is for the identity of the person sending the presence, not for the software or device.
5. Create a new namespace that has a URL for the current presence icon. This would work just fine, and normal web caching would get us everything we need. It would increase the size of every presence stanza, though.
6. Add a couple of new fields to the XEP-0232 software information that comes along with the caps. There would be a field for each presence state that you care about, where the value of that field is a URL to an image.

This last approach is obviously the one I favor. The caps result would look like this:

<iq from=“joe@example.com/phone“
    to=“subscriber@example.com/work“
    id=“disco1“
    type=“result“>
  <query xmlns=“http://jabber.org/protocol/disco#info“
         node=“http://jabber.com/bots/pbx#PwgGa/jZx9sUeueZsjT/xBlJfqo=“>
    <identity category=“client“ type=“bot“ name=“PBX“/>
    <x xmlns=“jabber:x:data“ type=“result“>
      <field var=“FORM_TYPE“ type=“hidden“>
        <value>urn:xmpp:dataforms:softwareinfo</value>
      </field>
      <field var=“icon“>
        <value>http://jabber.com/pbx.png</value>
      </field>
      <field var=“icon_available“>
        <value>http://jabber.org/pbx_available.png</value>
      </field>
      <field var=“icon_away“>
        <value>http://jabber.org/pbx_away.png</value>
      </field>
    </x>
  </query>
</iq>

In this case, there is a general-purpose icon field, and then one icon_[show] field for each show that we will be sending. Whenever the subscriber gets a new negative-priority presence update, it looks in its caps cache, pulls out the field for the appropriate show, and pulls the image URL through an HTTP client that does caching (or does it’s own manual image caching). The image is scaled into the desired size, and displayed in the user interface. If these fields are added to XEP-0232, we should probably specify a desired image size, like 128×128 pixels.

We have started to see our customers and partners send negative presence, and are feeling the pain of client UI that doesn’t know how to deal with it. The first step for us is to figure out the correct protocol to deal with the UI issues. We’ll push this into MomentIM as soon after that as release cycles allow.

After I wrapped-up my Fall VON panel discussion with Avaya, BT, and HP I switched gears to do an interview with VON TV. The five minute video shares some of my thoughts on the value of presence, why protocols don’t matter, and how Jabber simplifies adding presence to applications and services. Check out my early morning mug in Jabber’s “TV” debut.

Download

Yesterday at the Enterprise 2.0 conference, I participated in a panel discussion entitled “Presence 2.0“. Since the panel included some of the usual suspects from various past discussions, I decided to use the 2.0-ness of the title as an excuse to share some of the things we’ve been thinking about what presence might mean in the future. In particular, that we as an industry tend to make the problem too hard. Once users have several hundred people on their contact list, their desire for tweaky rules and individual configuration options starts to wane.

One way around this is a concept I’ve started calling “EigenPresence” (it’s important enough to me that I re-branded my blog to reflect the concept). The reputation for my digital identity is made up of multiple small pieces (on/offline, geographic location, mood, etc.), which can be combined into a single presence stream. If you were to integrate this stream over time, you would have the reputation associated with my identity. To answer Alec’s question, yes, I see Facebook, MySpace, Twitter, and the like as different bits that get integrated into this stream to build up my reputation.

I’ve posted my slide deck(5.6MB) from the panel, if you’d like to see them.

We were chatting the other day with an industry analyst and he started reeling off the “Web 2.0″-ish companies he’s working. We asked him about presence, and how these companies are going about making their services live.

The response was surprising and practically made us yell, Why in the world would they do that? You see, many of these companies view presence as core to their offering. Totally agree with them there.

As a core component many of these folks have gone about the business of trying to build their own presence server. The theory seems to be that “our application relies upon the ability of our users to know the presence of their buddies, and we therefore must own the presence engine.”

I beg to differ. Your service also needs a web server, and a bunch of hardware, and network connectivity, etc. Do you need to build all of those components yourself? I would argue that for many of these companies, presence is backend functionality, the application they build on top of it and how they market it should be their core focus.

At Jabber, Inc. we’ve already done the hard work with a massively scalable presence server that will interoperate with any network and just about any device. You can embed Jabber presence into just about any application and aggregate the presence from other devices and applications as well.

To illustrate the point, we recently closed a deal with a Web 2.0ish company which had been using an open source presence server (which is a nice way to get started.) But once they realized that their application and the success of their business was predicated on the ability to support millions of users, they had to go shopping and arrived at Jabber, Inc. because we’re the only store on Massively Scalable Avenue.