We have an enterprise installation of QuickBlox (which implements XMPP), and would like to create mirrored accounts for all of our users on our QuickBlox server install. We also want to sync the networks our system's users have created using relationships (eg, "client and provider") that have been built on our system.
In a nutshell, we want to export whitelists that limit chat "opponents" to only those users with whom each of our users already have relationships. If User1 has an existing relationship in our system with User2 and User3 but not User4 through User40, we want to be able to use the QuickBlox API to enforce that within chat by creating a whitelist through the QuickBlox API.
EDIT: We can't use an "honor system" whitelist. That is, the enforcement must be server-side using a method the client cannot circumvent. There must be a hard, unavoidable block between users for privacy concerns.
Use case:
A QuickBlox (or XMPP) server has User1 through User40, inclusive.
User1's whitelist is comprised of [User2, User3] only.
If User1 attempts to contact User15, we want QuickBlox/XMPP to note that User15 is not on User1's whitelist and block that communication as if User1 had bidirectionally blocked that user.
Privacy lists, aka blacklists
I have found places in QB's docs that refer to the XMPP specification docs, and have found the concept of privacy lists, which seem to operate as blacklists:
- https://quickblox.com/developers/Web_XMPP_Chat_Sample#Privacy_lists
- https://xmpp.org/extensions/xep-0016.html#protocol-syntax
These only provide two styles of blacklist privacy:
You can choose a type of blocked logic (Privacy List). There are 2 types:
- Block in one way. You are blocked, but you can write to blocked user.
- Block in two ways. You are blocked and you also can't write to blocked user.
Server Whitelist (dialog-level, not user)
I've also found documentation on whitelists for servers, which appear to operate at a dialog/jid, not user, level:
- https://xmpp.org/extensions/xep-0133.html#edit-whitelist
An entity added to a whitelist MAY be a JID of any form as specified in RFC 6120... a whitelist may prevent inbound communications, outbound communications, or both...
Rosters -- "presence" detail only?
There are also rosters, which are close to whitelists, but they do not seem in my testing to restrict communication between any two users that might not be on each other's roster.
That is to say, I haven't set up a roster in my testing application, and users are able to create group and 1-on-1 chat dialogs in spite of not having explicitly accepted any roster requests. In the Android docs, I found the following on rosters: "[A roster] is the collection of users a person receives presence updates for." That's not blocking in any way outside of presence alerts, I don't believe.
Question
Is there a suggested way to create a pessimistic whitelist for each user, which only contain those users with whom communication is allowed? Or are we forced to create and maintain "inverse blacklists", where we automate the creation of privacy lists for every new user blocking every other user and then use the API to remove those with which each user should be able to communicate?
If we do have to use "inverse blacklists", is there a way to have a default blacklist apply to every new user that initially blocks communication with every other user already in our QuickBlox system?
(Again, we can't use "honor system" lists. If the client must request a whitelist to be active before it can be used, can freely discover and then change active whitelists, or if the client can decline to use a list, that's not secure enough.)