[Standards] XEP-0184: Message Delivery Receipts and XEP-0333: Chat Markers

Dave Cridland dave at cridland.net
Thu Mar 5 22:21:32 UTC 2020

On Wed, 4 Mar 2020 at 11:45, Marvin W <xmpp at larma.de> wrote:

> XEP-0184 is doing one job, that is to notify the sender when a message
> was delivered to the recipient's client. That's literally what the title
> is. While in setups with MAM and SM, far less messages get lost, the
> pure specification of XMPP does not guarantee every message to be
> delivered to the recipient's client, so it makes sense to have this
> information per message. XEP-0184 does this job perfectly well, so I
> wonder why you are saying it only does half the job.
> XEP-0184 is widely implemented both in receiving and sending.

> The only thing I personally don't like about XEP-0184 is that it doesn't
> allow to ack several messages with one message. I do agree though that
> the overhead of using multiple messages isn't that much and in most
> cases you don't have a bunch of messages to ack at the same time.
Broad agreement to that - I don't see the inability to send a receipt for
and explicit set of multiple messages as a problem, and I think it would
massively complicate the protocol for little gain.

> ---
> In contrast XEP-0333 serves a mostly different purpose: it notifies the
> sender only of the last received/displayed/acknowledged message. This
> means it can not be used as a means to verify that a specific message
> was received, displayed or acknowledged. It also is weird that it

Received: This has potential problems since message loss would defeat the
point, but in general, recent XMPP deployments tend to get messages in
sequence to a client, or not at all - so it is a very close approximation.
A single message lost would still be a problem, of course. So overall, I
can go along with '184 instead.

Displayed: A message displayed really implies that all previous messages
have been displayed to all intents and purposes - they might not have been
rendered on screen depending on UX, but the existence of the message has
been displayed to the user in some form, I'm fine with that. A lost message
would of course break this - but I'm working on the assumption that we
handle this by '184.

> specifies that you have to interact with a message to acknowledge it,
> but then only the last message that was acknowledged is transferred, so
> the user interaction with previous messages can actually get lost. In
> general, I'd say that XEP-0333 is way less mature then XEP-0184 and
> serves an unclear set of goals.

I think Acknowledged is badly thought through. I think we want acknowledged
as per-message, but perhaps I just don't understand the expected UX here at

I'd want to explicitly request an acknowledgement for certain messages, I
think - and I'd be fine if that implied displayed, as now.

The XEP-0333 displayed feature is supported by many clients. The
> received feature of XEP-0333 is not often implemented in sending and
> sometimes also has very weird behavior in receiving (e.g. contrary to
> the XEP, only the message that was referenced in the received marker is
> marked as received, not all previous messages - which makes sense
> because XEP-0333 does not give any guarantee for previous messages, yet
> claims to). The acknowledged feature also seems to be barely used (also
> because it is questionable how to realize it UI wise).
We definitely only do displayed (but we operate in an environment with one
server and '198 on every client, so message loss is really not an issue).

> Therefor deprecating/obsoleting XEP-0184 seems like a very bad idea to
> me, I'd rather remove the received/acknowledged feature from XEP-0333
> and rename it to read markers (which is the only part most implement
> anyway) so we don't have an overlap in features and people stop claiming
> that XEP-0184 might be obsoleted by XEP-0333. Also reducing the feature
> set of XEP-0333 could make it easier to advance to Draft/Final state.
I'd like to:

* Drop received. I like the notion, but I don't think it provides solid
guarantees, and the overlap with '184 isn't persuading me it's worth
* Keep Displayed. Works well and widely implemented.
* Either drop Acknowledged, or make it an explicit request on a marked

The downside of replacing '333's Received with '184 is that '333's
Displayed (and Acknowledged) no longer automatically imply received, which
is a little frustrating. But I don't really see an alternative.

> On 3/4/20 11:04 AM, Andrew Nenakhov wrote:
> > But seriously, 0184 is a half-baked XEP that does only half the job
> > done. XMPP is currently extremely bloated with redundant XEPs, and
> > instead of trimming it down and streamlining it, you suggest setting
> > an already obsolete XEP in stone. If anyone here is worried about
> > bringing this protocol to the masses, it's not the way to go.
> >
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200305/2be5e86b/attachment.html>

More information about the Standards mailing list