[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.
>
>
Agreed.


> 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
all.

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
keeping.
* Keep Displayed. Works well and widely implemented.
* Either drop Acknowledged, or make it an explicit request on a marked
message.

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