[Standards] Multi-Client and PAM (XEP-0376: Pubsub Account Management)

Georg Lukas georg at op-co.de
Wed Sep 7 08:56:53 UTC 2016


Hi,

PAM was pointed out to be a major building block for MIX, but it is
lacking in regard to multi-client and filtering support. While not
strictly required for the basic operation of MIX and PAM, a question
that needs to be solved mid-term is: WHICH of the user's clients need to
know WHAT information (nodes) from WHOM (i.e. JIDs). This post
summarizes a discussion from the xsf@ MUC that tries to provide a
possible solution to these three dimensions. I don't know if it should
be integrated into PAM at some point or become a separate add-on XEP,
IMHO this depends on how the yet unspecified parts of PAM will sort out.

Everything a user wants to see on any of their clients is subscribed to
by PAM, providing a first filter to the WHAT. This is insufficient
because some clients won't be able to understand all topics, and
especially mobile clients shouldn't be flooded with traffic that is not
relevant to them. My assumption is that further filtering could be done
by PAM per-client, based on the client's Entity Caps (do not send a
client nodes for which it doesn't advertise support). Still, further
filtering might be wished for.

The WHO is currently not accounted for at all. There are use cases for
per-account ("A friend's User Tunes offend me") and per-client ("I want
to mute the XSF MIX on my mobile") filtering.

The PAM spec doesn't yet describe when a client is integrated into PAM's
local fanout, but my understanding so far is that it's either based on
an implicit mechanism like the client sending presence, or an explicit
trigger from the client like a "+notify" list. For efficiency reasons,
filtering should happen on the server, and begin atomically with the
start of the client subscription. This either requires an explicit
stanza from the client to PAM, or a PAM-side storage of different clients
and their filtering preferences.

However, maintaining a list of user clients on the server is a hard
problem (you never know when to expire entries), and sending a long list
of subscription preferences on each connection is a bad use of
resources.

To solve both parts of this problem, the idea of using the mechanics of
Entity Caps came up: define an encoding for the subscription list(*),
hash that, add the hash to your presence or something that is only
delivered to your local server, let PAM query you if the hash is not
known.

The subscription list should specify which subjects to receive, and
from which JIDs. XEP-0016 is a good example for how not to do it, so a
KISS approach seems reasonable. My take would be:

 * a whitelist of nodes (WHAT) based on client features and settings
 * an optional blacklist of JIDs per-node (WHO; so that you are auto-
   subscribed to new MIXes and data sources, but are able to mute them)

Each client would maintain that list locally, and PAM could cache it for
whatever time is deemed appropriate. This is an idea that still needs
additional work to spec out, and it does not take care of the "global"
muting of sources yet.


Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160907/00cd92dc/attachment.sig>


More information about the Standards mailing list