145
edits
Difference between revisions of "XEP-Remarks/XEP-0045: Multi-User Chat"
Jump to navigation
Jump to search
XEP-Remarks/XEP-0045: Multi-User Chat (view source)
Revision as of 09:00, 26 January 2018
, 09:00, 26 January 2018no edit summary
| (3 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
in http://xmpp.org/extensions/xep-0045.html#enter-history, which is not found in XEP-33 (nor XEP-33s schema). | 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 = | ||
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. | 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: | |||
# you recently sent a message to the MUC, '''AND''' | |||
# the received message is from your participant JID, '''AND''' | |||
## the message ID matches ''(a nice MUC, but not required by the XEP)'' '''OR''' | |||
## the message body matches ''(not conclusive, some MUCs auto-pastebin)'' '''OR''' | |||
## the received message is the first line of the sent message ''(transports like IRC split multi-line messages into one-liners)'' '''OR''' | |||
## 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 <x> 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 = | = MUC PM messages are not distinguishable from other MUC messages = | ||
http://mail.jabber.org/pipermail/standards/2015-May/029819.html | http://mail.jabber.org/pipermail/standards/2015-May/029819.html | ||