PresenceAPI

From MashupCamp

Presence APIs Session Notes

How presence is and will be represented in exposed APIs is interesting to Mashup developers. A lot of useful mashups for business and personal consumption could use presence information - but what is it? IM is the most common experience people have with presence information; usually with the common "away" and "active" icons. The concept of a contact list is common too. As an architect for Sprint, I'm interested in what people in the community want to do with presence and how they visualize the concept expanding.

In this session we talked about anything that interested us about presence. On the white board, I offered up three areas to start: types of presence, security, and metadata.

Primarily people thought presence was human availability - but there could be a lot of different states. Work vs. home was one variation. People wanted to be able to distinguish between their business lives and personal lives - and people would probably would bubble out other spheres within these areas. Also the state could depend on the contact list and who you allow to see what about your state. State has a relationship to traditional role identity concepts. The ability to lend or spoof presence was desirable by most people.

As an example of a sub-presence, people may want a shopping presence, both business and personal - where there are states of shopping readiness broadcasted for ads. Plazes http:\\www.plazes.com was an example offered on a connection platform. People could also want different presence information for children and the ability to filter - which lead to a discussion of blocking or a filter broker agent. OpenID http:\\www.openid.net might be used as a mechanism to aid in filtering. Ham radio APRS has an optin/out mechanism that could be looked at.

Metadata standards would help - perhaps an rss or atom feed standard. People in the discussion group wanted location information like lat, log, state, and the possibility of having a proprietary payload. The ability to specify by what means the user wants to be contacted and being able to filter that on the contact list was a good idea. A common syntax would be helpful. The problem of how to sync up or aggregate presence information was discussed. Also the problem of how to correlate actions by the user with state.

All sorts of ideas were discussed on how Mashups could consume presence information, including an app to show MashupCamp's attendees and their state -- which would naturally lead to another discussion session -- what are the states of a MashupCamper?

-- Nan Hickman

Thanks to Dave Nielsen of StrikeIron who passed me the notes from our white board.

--Nhickman 19:33, 20 July 2007 (EDT)