Difference between revisions of "XEP-Remarks/XEP-0280: Message Carbons"
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
[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 = | |||
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. | |||
= 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. | |||
Revision as of 18:58, 2 April 2018
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.
Server-Side Processing Rules
The current rules are vague and not quite adequate. 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.