[Standards] Better Privacy Lists (and Invisibility)
tomek at xiaoka.com
Wed Sep 12 21:19:07 UTC 2007
Let me summarise our current experience with XEP-0016 Privacy Lists
1. We separated Privacy Lists from RFC3921bis to make it possible to
change it (XEP-0016 is in Draft status now).
2. We have reports, that developers find Privacy Lists hard to use, thus
3. We have developed simpler frontends to Privacy Lists such as XEP-0191
Simple Communications Blocking and XEP-0126 Invisibility
4. XEP-0126 Invisibility shows problems with using Invisibility together
with other communications blocking (such as XEP-0191)
We are starting using Privacy Lists in a similar manner as Pub-Sub - as
a more powerful backend that drives simpler protocols (like PEP).
My experience with XEP-0191 implementations tells me, that this is a
But problems with XEP-0126 shows, that we need Privacy Lists be even
more flexible. We need to have more than one active list at a time,
which XEP-0016 does not support.
I think we could fix it without changing the Privacy List spec.
Instead we could put another layer on top of it, that adds support for
many active list at a time.
1. Server advertises new disco#info feature:
2. New attribute 'order' of list activation packet is then allowed
(in 'urn:xmpp:stacked-privacy-lists' namespace):
<iq from='romeo at example.net/orchard' type='set' id='active1'>
<active name='invisible-to-all' spl:order='first'/>
that would activate list 'invisible-to-all' and insert it on top of
stack. If a packet passes the first active list it is put through second
and so on. Options for the 'order' attribute are 'first', 'last' or
numeric value of the position of the stack (begining from one).
The order is not fixed after activation. If one puts new active list on
position 5, the previously fifth active list will have order of 6.
3. More than one <active/> child on lists IQ get query with additional
'order' attribute in 'urn:xmpp:stacked-privacy-lists' namespace:
<iq type='result' id='getlist1' to='romeo at example.net/orchard'>
<active name='invisible-to-all' spl:order='1'/>
<active name='private' spl:order='2'/>
4. A way to deactivate a list is simple:
<iq from='romeo at example.net/orchard' type='set' id='inactive1'>
Everything else from XEP-0016 works as before.
And if client does not know 'urn:xmpp:stacked-privacy-lists' it would
not even notice the existence.
Question is, whether we should add more than one default list?
I personally think, we don't need to.
I want to submit formal XEP with this proposal, but before, I open to
The Privacy List name 'invisible-to-all' was chosen to show how nicely
XEP-0126 Invisibility fits as another layer over the proposal.
* * *
There are some problems with XEP-0016 Privacy Lists too.
1. With RFC3921 support was mandatory, so there was no need for feature
advertisements. With RFC3921bis it's not, so we need a disco#info
feature for Privacy Lists
2. Outgoing messages and IQs are not blocked when incoming are. This is
inconsistent with XEP-0191 that requires blocking both outgoing and
I vote for requiring blocking outgoing messages in XEP-0016 Privacy
Lists and allowing for outgoing IQs in XEP-0191 Simple Communications
Blocking. (With same error for aoutgoing messages as in XEP-0191.)
More information about the Standards