[Standards] XEP-0126 invisibility interpretation

Rachel Blackman rcb at ceruleanstudios.com
Fri Feb 16 17:11:41 UTC 2007

> It's not clear to me right now how [in]visibility lists would  
> interact with privacy lists. However, it *is* clear to me that this  
> stuff is getting awfully complicated. :-) We have privacy lists,  
> [in]visibility mode, [in]visibility lists, block lists (a subset of  
> privacy lists), etc. That is way too much complexity and we need to  
> simplify, simplify, simplify.


I still agree that the functionality of setting presence 'macros' on  
the server-side is sensible.  The 'work' or 'home' or whatever.   
Perhaps what makes more sense is 'presence masks,' which could  
encompass everything.  A mask would simply say what the presence is  
for a given group or contact, when that mask is active, as well as  
how messages should be handled.

For instance...

A mask could define that your presence is entirely hidden from a JID  
or roster group.  ('Invisible')
A mask could define that your presence is shown as a specific show/ 
status pair to a specific JID or roster group.
A mask could define that your presence is passed through to a  
specific JID or roster group.
A mask could define that you simply won't accept messages from a  
specific JID or roster group, and don't even wish to get offline  
messages until you're out of this mask.
A mask could define that you are entirely blocking messages from a  
specific JID or roster group, and don't wish to EVER get the offline  
messages. ('discard' for messages)
A mask could define a default, fallback behavior.

The 'default' mask would effectively be a single default behavior of  
allowing presence and messages through.

I could now, for instance, make a mask of 'Work-Busy.'  In the Work  
mask, it displays my real status to anyone in the 'XSF' or 'Cerulean'  
groups of my roster, shows that I'm online (but display 'DND') to my  
roommates by individual JEP and my family by group, and then for  
everyone else, show me as offline and hold my messages until I'm out  
of 'Work-Busy' mode.

Some psuedo-XMPP...

<iq from='sparks at jabber.org' type='set' id='example1'>
   <query xmlns='http://example.com/dummyprotocol/presence-masks'>
            <target group='XSF'/>
            <target group='Cerulean'/>
            <target jid='roommate1 at home.net'/>
            <target jid='roommate2 at home.net'/>
            <target group='Family'/>
               <status>At work, busy!</status>
            <target jid='annoyingguy at someserver.com'/>

The first ruleset, for 'XSF' and 'Cerulean,' defines empty message  
and presence packets... that means basically 'do everything  
normally.'   Presence is passed through from the client, and messages  
are passed back to the client.

The second ruleset, for my two roommates and my family, still allows  
messages to be sent to me but defines a specific presence to send to  
them.  (So they see I'm working... even if I change my presence to  
'Whoohoo!  We made milestone!  PARTY!' for where my co-workers can see!)

The third rule is some annoying guy whose messages I don't ever want,  
so there's a 'discard' element.  (The server should, probably,  
respond with an appropriate XMPP error code informing him he's  
presently blocked, if he tries to send me a message.)  As this rule  
lacks a presence element entirely, presence is simply never sent to  
him while in this mask.

The fourth rule (with an empty target) is the fallback for everyone  
else.  Lacking a presence element, it simply doesn't send my presence  
to anyone.  And lacking a message element, it uses the default server  
behavior for if I were as offline as I appear (which is probably to  
spool offline messages until I am available).  If I still wanted to  
receive messages immediately, I'd put in a <message/> element and  
still just leave out <presence/>, so I'd appear offline but messages  
would still immediately pass through.

Then, I'd just:

<iq from='sparks at jabber.org' type='set' id='example2'>
   <query xmlns='http://example.com/dummyprotocol/presence-masks'>

And when I'm done working and want just normal default presence/ 
privacy/etc behavior,

<iq from='sparks at jabber.org' type='set' id='example453'>
   <query xmlns='http://example.com/dummyprotocol/presence-masks'>

Obviously, this is pre-caffeine psuedo-XMPP and would need  
significant polishing.  But my point is, I think it's possible to  
define a reasonably simple and straightforward system that  
encompasses privacy, invisibility /and/ the directed presence  
requests that have come up in this conversation.  I will even clean  
up the idea and submit a proto-XEP if necessary, but I'm quite sure  
someone else can write it up (and thus take the blame in the end).  ;)

Incidentally, apropos of nothing else, the XEP-0186 'Example 2:  
Service Discovery Response' example is wrong.  Though that's a minor  
thing; it shows a 'get' from Bilbo to the shire-server for the shire- 
server's response.

http://www.xmpp.org/extensions/xep-0186.html#disco ;)

Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/

More information about the Standards mailing list