[Standards] PEP in MUC, aka MEP

Matthew Wild mwild1 at gmail.com
Fri Jun 26 02:19:19 UTC 2009

Hi all,

An issue that keeps popping up is the current inability of MUC to
relay PEP updates. I personally *really* would like to see this
resolved. So I'm going to start the ball rolling with a proposal.

Firstly though, here is some discussion we had in jdev the other day
about the topic:

The proposal:

When publishing PEP updates, the client sends directed PEP updates as
messages (how to do this is already defined in some of the PEP specs)
to the room. This is similar to how presence works currently, the
server does not send presence updates to MUC rooms on your behalf.

The MUC would then either 1) broadcast the message blindly 2) only
send it to users with the appropriate +notify in their features.
Obviously 1 results in users who may not want PEP updates receiving
them, and 2 requires MUC implementations to track caps and features,
though an in-server MUC module would be able to pool this information
with the main server's own caps cache.

Now I don't suggest that this is a perfect solution. Everyone should
know there is no such thing :)

However here is why I believe this method to be a good one:

 - It is backwards compatible with the existing protocols, meaning we
can get it rolled out this side of Christmas (2012)
 - It allows the user to decide when and where to share their
(possibly private) PEP information
 - MUCs could selectively block or filter PEP notifications from participants

But there are some downsides (to which we could look for solutions):

 - It means publishing the same data multiple times to multiple JIDs
from the client
 - The above mentioned issue of MUC servers dealing with caps does not
appeal to me

Feedback invited.

I'd like to note that a couple of people I have spoken to would rather
see MUC re-invented, using "cleaner" semantics, and in the process
factor PEP into the mix. Again I don't claim MUC to be perfect either,
but it works, and we're using it *today*. The MUC XEP is nearly 7
years old, and is just coming to Final. I am not keen on advocating an
entirely new protocol and seeing implementations mature before we can
finally solve what are now just a few remaining issues with the
current one.


More information about the Standards mailing list