Server Aided Communications Blocking
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.
- Iterate over list until rule is matched
- 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
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)