[Standards] PEP in MUC, aka MEP

Peter Saint-Andre stpeter at stpeter.im
Fri Jun 26 14:50:06 UTC 2009

Hash: SHA1

On 6/25/09 8:19 PM, Matthew Wild wrote:

> 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.

I like this. You send directed presence to the room, so it makes sense
to send directed PEP (often used for "extended presence") to the room, too.

> 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.

IMHO #2 is preferable, if the MUC service is smart.

> 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 client already does that with presence, so also doing it with PEP
(extended presence) is not a great hardship, I think.

>  - The above mentioned issue of MUC servers dealing with caps does not
> appeal to me

The life of a server or component developer is a difficult one.

> 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. 

We had a similar discussion 7 years ago. Some people wanted to replace
groupchat with an IQ-based protocol, but discussions were inconclusive
and no one stepped forward to really work on it. I got sick and tired of
 the squabbling and wrote MUC to be backwards-compatible with the old
groupchat approach. I don't claim that MUC is the most beautiful XMPP
extension ever developer (nor the ugliest!), but I also don't think it's
worth our time to create a new technology that does just what MUC does
except in a more aesthetically pleasing manner.

> 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.



- --
Peter Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Standards mailing list