Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts
пт, 6 мар. 2020 г. в 15:51, Georg Lukas : > > * Andrew Nenakhov [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 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 ___
Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts
* Andrew Nenakhov [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. Does your server not store delivery receipts in offline storage / MAM? Then the server should be fixed (as should be 0313). > 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. It could also translate between 0333 and 0184, with the obvious shortcomings of the mapping that were discussed in this thread. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts
пт, 6 мар. 2020 г. в 13:39, : > > Hello! > > No, it's impossible to determine, if the message was delivered with Chat > Markers, 'cause Chat Markers allows you to send marker not for every message. > So, if you didn't receive "RECEIVED" marker for a message but received the > marker for the next one, you have to consider the first message also > received. That sounds stupid, but that's what XEP says. > > So, to be sure that message was really delivered, we need Message Delivery > Receipts. 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. Anyway, the idea to ensure delivery between clients is just plain wrong, because they are not designed to be constantly connected. 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). -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts
Hello!No, it's impossible to determine, if the message was delivered with Chat Markers, 'cause Chat Markers allows you to send marker not for every message. So, if you didn't receive "RECEIVED" marker for a message but received the marker for the next one, you have to consider the first message also received. That sounds stupid, but that's what XEP says.So, to be sure that message was really delivered, we need Message Delivery Receipts. 4 мар. 2020 г. 1:18 пользователь Andrew Nenakhov написал:We have it implemented in 'read' mode, so all our clients can receive delivery receipts, but never send them. I think this XEP should be obsoleted in favour of XEP-0333 Chat Markers, which does all that XEP-0184 does, plus something more. вт, 3 мар. 2020 г. в 22:46, Jonas Schäfer : > > The XEP Editor would like to Call for Experience with XEP-0184 before > presenting it to the Council for advancing it to Final status. > > > During the Call for Experience, please answer the following questions: > > 1. What software has XEP-0184 implemented? Please note that the > protocol must be implemented in at least two separate codebases (at > least one of which must be free or open-source software) in order to > advance from Draft to Final. > > 2. Have developers experienced any problems with the protocol as > defined in XEP-0184? If so, please describe the problems and, if > possible, suggested solutions. > > 3. Is the text of XEP-0184 clear and unambiguous? Are more examples > needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? > Have developers found the text confusing at all? Please describe any > suggestions you have for improving the text. > > If you have any comments about advancing XEP-0184 from Draft to Final, > please provide them by the close of business on 2020-03-17. After the > Call for Experience, this XEP might undergo revisions to address > feedback received, after which it will be presented to the XMPP > Council for voting to a status of Final. > > > You can review the specification here: > > https://xmpp.org/extensions/xep-0184.html > > Please send all feedback to the standards@xmpp.org discussion list. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
