Difference between revisions of "XEP-Remarks/XEP-0280: Message Carbons"
(Created page with "= Carbons - inbound messages to bare jid = http://mail.jabber.org/pipermail/standards/2014-April/028807.html = More message types, beside 'chat' = http://mail.jabber.org/pi...")
m (Remove outdated section)
Tags: Mobile web edit Mobile edit
|(9 intermediate revisions by 4 users not shown)|
|Line 1:||Line 1:|
Latest revision as of 20:00, 23 August 2021
This is a page for information about XEP-Remarks/XEP-0280: Message Carbons, including errata, comments, questions, and implementation experience.
Recommended Activation Order
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.
Carbons MUST NOT be accepted from JIDs other than the user's bare account JID, or else:
- CVE-2017-5589+ Multiple XMPP Clients User Impersonation Vulnerability
- CVE-2019-16235+ Multiple Vulnerabilities found in Dino
- 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 <x xmlns='http://jabber.org/protocol/muc'> 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 disco#info IQ to the partner's bare JID and delay processing of the Carbon (yes, ewwww!)
- If the disco#info response contains <feature var='http://jabber.org/protocol/muc'/> 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.
- 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.