Difference between revisions of "XEP-Remarks/XEP-0045: Multi-User Chat"
| (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 | ||
Revision as of 09:00, 26 January 2018
Stable Message IDs
http://mail.jabber.org/pipermail/standards/2014-July/029012.html
Possible Solution: http://geekplace.eu/xeps/xep-muc-extensions/xep-muc-extensions.html#mid
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:
- 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
http://mail.jabber.org/pipermail/standards/2015-May/029819.html