[Standards] Call for Experience: XEP-0184: Message Delivery Receipts

Andrew Nenakhov andrew.nenakhov at redsolution.com
Fri Mar 6 11:22:08 UTC 2020

пт, 6 мар. 2020 г. в 15:51, Georg Lukas <georg at op-co.de>:
> * Andrew Nenakhov <andrew.nenakhov at redsolution.com> [2020-03-06 11:10]:
> > It is not possible to determine with Delivery Receipts either. If you
> > were offline when they were sent, you will not receive them.
> > If the recipient was offline when the messages were sent, a client
> > won't send the receipts too. So, it is only relatively good in a
> > situation when both chat participants are online.
> This is interesting. In my client, I always request delivery receipts
> for chat messages, and I always send a receipt for a message that
> requested one.
> Why / how do you make that depend on the availability of the other
> party? Are you using service discovery on the individual client to
> determine whether they actually support the feature? That would break in
> funny ways with Carbons / offline storage / MAM.

We're just sending chat markers when the client deems it necessary.
User downloads latest messages via device sync protocol - we're
sending delivered to newly received messages. User opens a previously
unopened chat - we send displayed. Because it's 2020 and we're making
a modern chat app.

> Does your server not store delivery receipts in offline storage / MAM?
> Then the server should be fixed (as should be 0313).

Storing delivery receipts in MAM is not really good, as it bloats the
archive with non-messages and slows its performance. 0313 says that it
SHOULD store messages that contain a <body> element, and while it MAY
store other types of messages, I'm quite happy with how it works and
it definitely should not be fixed in this regard.

You are, of course, welcome to break your own archives, but we won't do this.

> > Servers, on the other hands, ARE designed to be constantly connected,
> > so it should be a server's job to keep track of such things (and we
> > actually do exactly this).
> In theory, you could make a server that plays 0184/0333 proxy/bouncer,
> acknowledging to an external sender when the message got delivered to a
> client, e.g. if it knows by means of 0198 acks or a similar protocol.

In our implementation, we're keeping track of all the conversations a
user has, and storing metadata like 'delivered', 'displayed' (for
outgoing messages) and 'unread' counter for incoming messages. So far,
so good, all done using XEP-0333 Chat Markers. When a new client
connects, it immediately sees a list of recent conversations, all with
correct markers and unread messages count (plus voip calls, etc, but
that's a story for another day).

Andrew Nenakhov
CEO, redsolution, OÜ

More information about the Standards mailing list