[Standards] XEP-0313 MAM implementation for MUC

Mickaël Rémond mremond at process-one.net
Fri Jul 31 16:57:58 UTC 2015


On 31 Jul 2015, at 18:31, Daniel Gultsch wrote:

>> So, I think it may be interesting and more flexible to state that the 
>> from
>> attribute will contain the room/nick JID and to add a special tag for 
>> real
>> JID. For consistency, we can reuse the same approach we have for 
>> presence
>> on non-anonymous room: x tag with xmlns
>> http://jabber.org/protocol/muc#user
> Yes I had the very same problem when implementing MUC-MAM on the 
> client
> side. I had very brief discussions with some people at that time but 
> we
> never got to a point where we could actually implement stuff.
> Our (or my) conclusions from back then are:
> The real jid should be included if the mam requester is the original 
> sender
> of that message or if at the time the message was written the mam 
> requester
> would have had access to the real jids. (non-anonymous or requester 
> was
> admin at that time)
> The last one will quite possible be impossible to achieve since you 
> can not
> store historic room configurations. So I would suggest to take a more
> general / easier approach to send the real jid if the muc was 
> non-anonymous
> back then and still is. (That prevents admins from discovering the 
> real jid
> retrospectively but thats something we will have to live with I guess)

I agree that it would be nice to keep the history of the MUC 
configuration, but isn't this an overkill requirement ?

My point is that MAM MUC is a bit like static chat room page. A bit 

but being marked with proper semantic, and with incremental retrieval.

It means as a client developer, you can integrate archive coming from 
the server almost like standard messages.

For that use case, handling the check at the time of access may be 
reasonable enough: If you are admin and can see JID now, you still can 
investigate an abuse yesterday for example.

So, wouldn't the check being done at time of access to the archive be 
reasonable enough ?

Mickaël Rémond

More information about the Standards mailing list