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

From XMPP WIKI
Jump to: navigation, search
(Added more issues.)
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
+
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.
  
= More message types, beside 'chat' =
+
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.
  
http://mail.jabber.org/pipermail/standards/2013-January/026988.html
+
= Server-Side Processing Rules =
  
A filtering mechanism might or might not be appropriate.
+
The current rules are vague and not quite adequate. [https://github.com/xsf/xeps/pull/434 An alternative proposal (#434)] is being worked on.
  
Pro: more flexible
+
= Client-Side Processing =
  
Contra: bloats an XEP that works for 99% of users.
+
Carbons MUST NOT be accepted from JIDs other than the user's bare account JID!
  
= Carbonated MUC private messages =
+
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).
  
http://mail.jabber.org/pipermail/standards/2015-May/029819.html
+
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).
  
= UI Notifications for normal/carbon messages =
 
  
http://mail.jabber.org/pipermail/standards/2015-April/029722.html
+
= 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.