Presence and IntComm WG

[Neal McBurnett <>]

On the call today we discussed the question of how a user could assert
presence selectively.  I.e. so that some other users could see it but not
all others.  Here is my attempt to write down the question so someone more
knowlegable [like Peter, hint hint] could help us out.  Please chime
in, folks, if I leave important aspects of the question out....

An example bit of context was a user who planned to be out of town for
a week, with their own normal client hardware turned off or
disconnected, but wanted another computer somewhere to assert presence
for them.  Another was finding ways for the infrastructure to update
rich presence (e.g. location, based on wireless connectivity) and
again how to do that in a selective way.  I picture that as implying
some sort of user agent within the infrastructure (a plug-in for a
server?) rather than being a feature in end-user chat client software.

A quick google search brought up "JEP-0126: Invisibility" (a "best
practice")

 http://www.jabber.org/jeps/jep-0126.html

It seems to provide a way to do this for simple presence.

For rich presence, JEP-0163: Personal Eventing via Pubsub
discusses a lot of this.

  http://www.jabber.org/jeps/jep-0163.html

Nota Bene:

 WARNING: This Standards-Track JEP is Experimental. Publication as a
 Jabber Enhancement Proposal does not imply approval of this proposal
 by the Jabber Software Foundation. Implementation of the protocol
 described herein is encouraged in exploratory implementations, but
 production systems should not deploy implementations of this protocol
 until it advances to a status of Draft.

It provides solutions for this Scenario:

      An owner-publisher 

 who publishes the following information:
         1. Tune information that anyone may see (i.e., an access model of 
"open")
         2. Activity information that only presence subscribers may see 
(i.e., an access model of "presence")
         3. Geolocation information that only contacts in her "Friends" group 
may see (i.e., an access model of "roster" with a group of "Friends")
         4. Bookmark information that only the account owner may see (i.e., 
an access model of "whitelist")

      Note: A PEP node with an access model of "whitelist" and no entities on 
the whitelist effectively results in a node that enables private data 
storage; for details, see the Private Data Storage section of this document.

As noted previously, pubsub is not widely implemented yet, so
applicability may still be limited.  Though in fact this JEP seems to
be trying to simplify things (it seems almost like a profile of
pubsub) to encourage clients to add support.

So, Peter, is this the right place to be looking?  Any other sage
advice on this general topic?

Cheers,

Neal McBurnett                 http://mcburnett.org/neal/