XEP-Remarks/XEP-0045: Multi-User Chat

= Stable Message IDs =

As of 2018, server implementations are required to keep the message ID when reflecting client messages. This can be determined by the presence of the 'http://jabber.org/protocol/muc#stable_id' feature on the MUC JID or MUC domain.

= Ambiguities =

http://mail.jabber.org/pipermail/standards/2014-April/028805.html

= Introduces 'ofrom' Extended Stanza Addressing (XEP-33) type =

in http://xmpp.org/extensions/xep-0045.html#enter-history, which is not found in XEP-33 (nor XEP-33s schema).

= Matching Your Reflected Message =

So you sent a message to a MUC and want to immediately display it as "on the way" (good UX). Some time later (usually within some seconds) you receive a message from the MUC which might or might not be your sent message.

Find out if a relfection is your actual message, in six easy steps! The message is your reflection if:


 * 1) you recently sent a message to the MUC, AND
 * 2) the received message is from your participant JID, AND
 * 3) the XEP-0359 origin ID matches (probably not a transport) OR
 * 4) the message ID matches (a nice MUC, but not required by the XEP) OR
 * 5) the message body matches (not conclusive, some MUCs auto-pastebin) OR
 * 6) the received message is the first line of the sent message (transports like IRC split multi-line messages into one-liners) OR
 * 7) the sent message is very long (>400 bytes) and the received message is a prefix of it (IRC transpors split very long one-liners too!)

(this mechanism doesn't cover MUCs which don't reflect the message ID and do autopastebin. Screw them!)

= Am I still there? =

Current MUC / server implementations do not send offline-presence packets to participants on service restart. Therefore, a client will think it is still joined to a MUC indefinitely.

There is no portable/reliable mechanism to check if the client is still joined, and no clean way to re-sync the state if it is not joined.

This problem needs to be solved at the MUC service / service-hosting server level eventually, but a workaround is needed on the client side.

Maybe a periodic presence packet can be sent to the MUC, checking the result (either a reflected presence update or a full join).

= MUC double join =

It's not specified what should happen if an entity sends an initial presence when it's already joined. Implementations should behave towards the joining entity like it successfully joined. That means, if a presence update containing an  element is received from a participant, the server should send back the full presence list, the requested amount of history and the room subject.

= MUC PM messages are not distinguishable from other MUC messages =

http://mail.jabber.org/pipermail/standards/2015-May/029819.html