пт, 6 мар. 2020 г. в 15:51, Georg Lukas <ge...@op-co.de>: > > * Andrew Nenakhov <andrew.nenak...@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Ü https://redsolution.com _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
