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

Sergey Dobrov binary at jrudevels.org
Tue Sep 13 15:16:12 UTC 2016


Hi,

This is a good one. I would just like to add that pubsub now declares 
filtering by type of event (new item/retract/change node configuration) 
on the node level but it's also not going to work very well in an 
multi-client environment? Would be also nice to be able to make this 
filtering per client?

Thanks.

On 07/09/2016 10:56, Georg Lukas wrote:
> 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
>
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>


-- 
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.


More information about the Standards mailing list