Difference between revisions of "XEP-Remarks/XEP-0280: Message Carbons"
Jump to navigation
Jump to search
m (Remove outdated section) Tags: Mobile web edit Mobile edit |
|||
(8 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{remarks}} | |||
[https://xmpp.org/extensions/xep-0280.html Message Carbons] are a way to synchronize live chat history between multiple online clients of the same user. To catch up when the client just comes online, [https://xmpp.org/extensions/xep-0313.html MAM] should be used. | |||
= | = Recommended Activation Order = | ||
http:// | Carbons should be enabled before MAM, and before sending presence (if so desired). This should ensure that there is no race condition between incoming messages and client synchronization. | ||
In the long term, Carbons+MAM might be replaced/updated by some common mechanism that also ensures that a client knows the MAM-ID of sent messages. | |||
= Client-Side Processing = | |||
'''Carbons MUST NOT be accepted from JIDs other than the user's bare account JID''', or else: | |||
* [https://op-co.de/tmp/CVE-2017-5589.html CVE-2017-5589+ Multiple XMPP Clients User Impersonation Vulnerability] | |||
* [https://gultsch.de/dino_multiple.html CVE-2019-16235+ Multiple Vulnerabilities found in Dino] | |||
* [https://monal.im/blog/cve-2020-26547/ CVE-2020-26547 Missing verification of origin of Carbons in Monal] | |||
Before processing a Carbon, the client must determine whether the message was a MUC-PM or a regular chat message (this might require an IQ round-trip to the sending entity). | |||
Possible MUC-PM resolution, "partner" is the sender JID of "received" and the recipient JID of "sent" Carbons: | |||
# If the forwarded message contains an <tt><x xmlns='http://jabber.org/protocol/muc'></tt> payload, it's a PM | |||
# If the partner's bare JID is a known MUC (joined, listed in bookmarks), it's a PM | |||
# If the partner's bare JID is in the roster, it's '''probably''' a normal message (shakes fist at Gajim) | |||
# If still undetermined, send a <tt>disco#info</tt> IQ to the partner's bare JID and delay processing of the Carbon (yes, ewwww!) | |||
# If the <tt>disco#info</tt> response contains <tt><feature var='http://jabber.org/protocol/muc'/></tt> then it's a PM, otherwise it's a normal message. Cache the disco result for next time! | |||
For regular messsages, the client should process the Carbon similarly to a normal message (it might modify notification behavior, but this is not guaranteed to work). | |||
= Handling of MUC-PMs = | |||
A server should not send Carbons for incoming MUC-PMs, but it should send 'sent' Carbons for outgoing ones - to the clients that are joined to the MUC with the same nickname. | |||
Client: | |||
* For 'sent' MUC-PMs, if the client is joined, it should log the message as if it sent it itself. | |||
* For 'received' MUC-PMs, the client should ignore them if joined (it will receive a proper copy from the MUC), or allow the user to join the MUC. |