Difference between revisions of "XEP-Remarks/XEP-0280: Message Carbons"

From XMPP WIKI
Jump to navigation Jump to search
 
m (Remove outdated section)
Tags: Mobile web edit Mobile edit
 
(5 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.
[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.


Line 7: Line 9:
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.
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.


= Server-Side Processing Rules =
= Client-Side Processing =
 
'''Carbons MUST NOT be accepted from JIDs other than the user's bare account JID''', or else:


The current rules are vague and not quite adequate. [https://github.com/xsf/xeps/pull/434 An alternative proposal (#434)] is being worked on.
* [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]


= Client-Side Processing =
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).


Carbons MUST NOT be accepted from JIDs other than the user's bare account JID!
Possible MUC-PM resolution, "partner" is the sender JID of "received" and the recipient JID of "sent" Carbons:


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).
# 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).
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 =
= Handling of MUC-PMs =

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.

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, MAM should be used.

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.

Client-Side Processing

Carbons MUST NOT be accepted from JIDs other than the user's bare account JID, or else:

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:

  1. If the forwarded message contains an <x xmlns='http://jabber.org/protocol/muc'> payload, it's a PM
  2. If the partner's bare JID is a known MUC (joined, listed in bookmarks), it's a PM
  3. If the partner's bare JID is in the roster, it's probably a normal message (shakes fist at Gajim)
  4. If still undetermined, send a disco#info IQ to the partner's bare JID and delay processing of the Carbon (yes, ewwww!)
  5. 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.

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.