[Standards] MIX-PAM: private PEP node for joined channels

Linus Jahn lnj at kaidan.im
Wed Nov 20 20:41:44 UTC 2019

On Tue, 19 Nov 2019 09:51:00 +0000 Daniel Gultsch <daniel at gultsch.de> wrote:

> Am Sa., 16. Nov. 2019 um 17:48 Uhr schrieb Linus Jahn <lnj at kaidan.im>:
> > I'm currently working on XEP-0405 / MIX-PAM. I'm replacing the roster
> > mechanism by a private PEP node. The basics are working now, but I'm
> > not sure what's the best way to make presence sharing with the channel
> > configurable.
> >
> > The roster mechanism allowed the client to disable presence sharing with
> > the channel by setting subscription=none. How do you think it's best to
> > do this with the PEP node?
> >
> > The PEP node could be made editable to the user (similar to the roster
> > entry before). Then a custom rule for the server to only allow the
> > 'share-presence' attribute to be modified would be needed.
> >
> > The other option I can think of is adding an IQ command to enable or
> > disable presence sharing. Executing it would then trigger PEP
> > notifications to be sent to the user.
> >
> > I think in both options this should already be configurable in the
> > <client-join/> request, so a client does not need to send two requests
> > when joining a channel with disabled presence sharing.  
> Thank you for bringing this back to the table.
> I don’t have strong feelings about this but my current thinking is
> that it doesn’t have to be PEP.
> I think we can all agree that a dedicated IQ command to flip the
> send-presence flag would be less confusing and less error prone on the
> server side. Continuing that line of thinking further I don’t see a
> good reason why the channel list should be stored in PEP in the first
> place. It's going to be read only for the client anyway; and on the
> server side there is going to be a lot of special processing. Also the
> PEP notification wire format has a lot of overhead.
> Modeling the channel list after blocking command and roster (custom
> IQs, first get will subscribe you automatically) might be more
> straightforward for everyone. It also forces you into the "get entire
> list on login" method (so you don’t forget). Furthermore a dedicated
> mechanism might lift the "oh now I have to implement pubsub" burden
> from server implementers, (Even though you might technically get
> around with only implementing partial pubsub)
> cheers
> Daniel

I don't think that implementing PubSub is a real problem since PEP uses only a small subset of
PubSub and PubSub is required for MIX anyway already.
Also why should you use a custom protocol with the exact same concept for every PubSub-like
feature. Wouldn't this basically mean to duplicate the roster or blocking command code in
implementations for MIX.
Of course it's more work to implement basic PubSub / PEP than just implementing a single IQ as for
the blocking command, but once you've got PubSub many things are easier and can rely on that code,
I think.

Also the 'blocking command' way isn't so flexible. Ideally I would like to send one request to the
server to receive all updates of all of my implicitly subscribed nodes after logging in. (I'm not
entirely sure whether this is currently possible with PEP and MAM though?)
The blocking command way would mean when logging in, the client needs to request all items of all
subscribed 'nodes' (roster, blocking command, MIX, etc.) in single requests.
Of course you could say let's do something like roster versioning for each of them to not produce
unnecessary traffic, but doing this for every of them in a custom way doesn't seem to be correct.
If you don't want to save the joined MIX channels in a way as a client, you can still request all
channels of the node on each connect.

About the traffic overhead of PubSub: I'd think that it's in the end lower than the overhead for
requesting all joined channels on every login for the average user. The joined MIX channels
probably won't change very frequently.

I'm not sure if PEP was intended to have server-managed nodes, so maybe this could lead to
additional work for existing server implementations.

I agree that a dedicated IQ command for setting the send-presence flag is a good idea.

I would like to hear some more comments though before I continue.

Best regards,

More information about the Standards mailing list