[Standards] Carbons of Message Acks and Chat Markers (XEP-0280, XEP-0184, XEP-0333)

Georg Lukas georg at op-co.de
Sun Feb 26 09:05:51 UTC 2017


it looks like we are currently in the process of overhauling Carbons,
and I'd like to improve the rules for Acks and Chat Markers,
specifically to make these also carbon-copied to other devices.

If A fails to send a message to B, the error is carbon-copied:

<message type="chat" from="A/A1" to="B">
<message from="A" to="A/A2"><message/> -- carbon copy of message
<message type="error" from="B" to="A/A1"> -- NACK
<message type="chat" from="A" to="A/A2"><message t="error"> -- carbon NACK

If A successfully sends a message to B, the ACK is not replicated on A's
second device:

<message type="chat" from="A/A1" to="B">
<message type="chat" from="A" to="A/A2"> -- carbon copy of message
<message from="B/B1" to="A/A1"><received/> -- ACK from B
-- no carbon copy of ack because it's bodyless, type=normal

Because the ACK is type=normal and has no body, it does not qualify for
carbon-copying, thus A's second client will never show the nice green
checkmark. This is a consistency and a UX problem.

From a glimpse at 0333, the same problem arises: Chat Markers are not

I'm sure this also affects other XEPs where a carbon copy would be
useful but is not made under current rules.

IIRC, there was a similar debate about which messages should be stored
in MAM (with the implementations just ending up storing everything?).

From here, there are multiple possible ways forward:

1. Change Carbons to allow carbon-copying of body-less "normal"
   messages. This will have side-effects to a number of other XEPs which
   rely on body-less messages, like IBB, Ad-Hoc Commands and PubSub.

2. Change Carbons to explicitly list the payloads we want carbon-copied.
   This will become a maintenance nightmare soon.

3. Change 0184 and 0333 to use type="chat".

4. Add a <copy/> hint to 0334 and use it in 0184, 0333 and wherever else
   CCing seems useful. This would be the most elegant solution, but
   requires touching the most XEPs (0184 is 'Draft', 0333 is in LC).

Comments? Ideas?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170226/e7c8653b/attachment.sig>

More information about the Standards mailing list