[Standards] XEP-0126 invisibility interpretation
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.
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.
<iq from='sparks at jabber.org' type='set' id='example1'>
<target jid='roommate1 at home.net'/>
<target jid='roommate2 at home.net'/>
<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'>
And when I'm done working and want just normal default presence/
<iq from='sparks at jabber.org' type='set' id='example453'>
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-
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/
More information about the Standards