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: http://logs.jabber.org/[email protected]/2009-06-23.html#16:14:45 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. Matthew.
