Server Aided Communications Blocking

Revision as of 11:11, 6 October 2015 by Flow (talk | contribs) (→‎New or add-on XEP)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The following tries to give an overview of the current discussion around Privacy Lists and Blocking Command. It does not try to stay neutral but instead provides the different opinions. Feel free to add yours too, but do not delete statements you don't agree with.


  • XEP-16 Privacy Lists
  • XEP-191 Blocking Command


The existence of two solutions for server aided communications blocking leads to a bad user experience.


Privacy Lists


  • Flexible


  • Iterate over list until rule is matched

Blocking Command


  • Simple
  • Efficient lookup of blocking critera


  • Does not allow to block per Roster group
  • Does not allow to block per subscription state
  • Blocking configuration is the same for all sessions of the users

Suggested Solutions

Deprecate Privacy Lists

Deprecate Blocking Command

Privacy Lists are more powerful and (mobile) users need a way for server side communications blocking of stanzas from contacts they are not subscribed to. Blocking command promised to deliver a better user experience, but in the end, the existence of two XEPs for nearly the same purpose lead to a bad user experience. After all privacy lists are not that complicated. And their performance disadvantage over blocking command should no matter in a decentralized XMPP world with many small XMPP services.

New or add-on XEP

The "List" approach of Privacy Lists makes things complicated (and is not really required), but on the other hand Blocking Command does not cover some important use cases. Users should be able to block stanzas from XMPP entities they are not subscribed to on a mobile device, while they may want to receive all stanzas on their desktop. It also appears users want to be able to block on per Roster group base. Therefore create a new or add-on XEP which extends Blocking Command by:

  • A facility to specify blocked Roster groups
  • A facility to specify blocked subscription states (e.g. 'none').
  • A facility to provide multiple blocking configuration (similar to how Privacy Lists supports multiple lists)

While throwing away the unnecessary (?) features of privacy lists

  • ordered list
  • fine grained blocking (message, presence-in, presence-out, iq)

but keeping it's efficiently by allowing for fast lookups if a stanzas should be blocked.