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

Daniel Gultsch daniel at gultsch.de
Tue Nov 19 09:51:00 UTC 2019

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)


More information about the Standards mailing list