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

Jump to navigation Jump to search
no edit summary
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Carbons - inbound messages to bare jid =
[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.


http://mail.jabber.org/pipermail/standards/2014-April/028807.html
= Recommended Activation Order =
http://mail.jabber.org/pipermail/standards/2014-April/028823.html


= More message types, beside 'chat' =
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.


http://mail.jabber.org/pipermail/standards/2013-January/026988.html
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 =
 
The current rules are vague and not quite adequate. [https://github.com/xsf/xeps/pull/434 An alternative proposal (#434)] is being worked on.
 
= Client-Side Processing =
 
Carbons MUST NOT be accepted from JIDs other than the user's bare account JID!
 
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).
 
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.

Navigation menu