Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts
* Jonas Schäfer [2020-03-17 17:28]: > - Are clients allowed to reply receipt requests when fetching messages from > MAM? I think they are, despite the wording in the text (which IMO only > considers the user browsing an archive), but I guess the wording needs > cleaning up. In my implementation (which mimicks behavior from others, as I've heard), I will build up a list of unacked messages when syncing messages from MAM: - add JID + ID to the list when receiving a message - remove JID + ID when receiving a "carbon copy" of an outgoing ACK (this approach obviously depends on receiving messages in chronological order) After MAM sync is finished, I will send ACKs for all IDs that are still in this list. From some initial measurements, even when syncing a month worth of messages from MAM, the number of outgoing ACKs is very moderate (just a handful), as it will only ACK messages that weren't yet acked by another client. Of course, if you've been offline with all your devices for a week, this number will be significantly higher. > - When syncing multiple messages from an archive, sending a receipt for each > one is expensive and wasteful. A way to send multiple receipts in a single > message would be appreciated. Yes, it would be nice, and it was a sad oversight in the original specification. However, just allowing for multiple ACK payloads in one message will be a breaking change, thus requiring a namespace bump, and the benefit is questionable. I suppose we could do this if we first establish a kind of omni-present mod_receipts_compat server module that will combine/split multi-receipts into old-namespace single-receipts based on the namespace advertised by a client. > - It would be nice if receipts could integrate with MAM better to avoid > fetching all the ACKs. That sounds like a job for MAM Fastening Collation. > - I wonder if it would be worthwhile to have MAM reply to receipts on behalf > of the user. A categoric NO here. Servers are much more stable and long-living than clients. If I have abandoned XMPP, there is really no value in my server sending you receipts to all the messages you sent to me, basically forever. There is real value in knowing that a message arrived at a user's end device. 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
On Dienstag, 3. März 2020 18:45:44 CET Jonas Schäfer wrote: > 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. aioxmpp defines only the schema to use Delivery Receipts; it does not do anything special with it. See below. > 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. There are a few ambiguities and issues around '184: - Are clients allowed to reply receipt requests when fetching messages from MAM? I think they are, despite the wording in the text (which IMO only considers the user browsing an archive), but I guess the wording needs cleaning up. - When syncing multiple messages from an archive, sending a receipt for each one is expensive and wasteful. A way to send multiple receipts in a single message would be appreciated. - It would be nice if receipts could integrate with MAM better to avoid fetching all the ACKs. - I wonder if it would be worthwhile to have MAM reply to receipts on behalf of the user. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ 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
On Tue, Mar 3, 2020, at 12:45, Jonas Schäfer wrote: > 1. What software has XEP-0184 implemented? I just implemented receipts for the Mellium XMPP library (2 clause BSD style license, although possibly changing to Apache 2 in the near future): https://godoc.org/mellium.im/xmpp/receipts > 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. I would prefer a simple way to differentiate between "received" and "received and seen" that's all part of the same protocol. It seems odd to me that the intro makes it clear that this was considered when designing the protocol and decided against, but times change I suppose. > Please describe any suggestions you have for improving the text. nit: "impute" is used in section 4, but it's not a very common English word and we have a very wide range of English language skill in this community. It may be worth using something more common. See also my other email in which I mention the link to Message Archiving. —Sam -- Sam Whited ___ 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 г. в 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 ___
Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts
On Tue, Mar 3, 2020, at 12:45, Jonas Schäfer wrote: > 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. It's a minor nit, but we could replace the reference to Message Archiving with MAM instead. It's a minor change that doesn't actually break any important draft rules as far as I know but makes the spec feel more up to date (for now) and just generally provides users with a more useful link. All this may change in the future, but it seems like good housekeeping at the moment. —Sam ___ 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
On 3 Mar 2020, at 17:45, Jonas Schäfer (XSF Editor) wrote: > > 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. Swift (GPL) > 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. No. Kinda. The rules distinguishing between Bare/Full JID and assuming that full JID messages will only go to the addressed JID are somewhat out of place in the modern world and could do with a rethink, methinks. The ’SHOULD NOT’ in particular seems inappropriate. The ‘must not ack from an archive’ is also somewhat out of place in a world where clients are disabling offline messages in favour of fetching from an archive. In general, I think 184’s interactions with modern routing/message handling haven’t been considered and implementing 184 as-is might be unfortunate. /K ___ 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
ср, 4 мар. 2020 г. в 11:10, Philipp Hörist : > > > > Am Di., 3. März 2020 um 21:19 Uhr schrieb Andrew Nenakhov > : >> >> >> I think this XEP should be obsoleted in favour of XEP-0333 Chat >> Markers, which does all that XEP-0184 does, plus something more. > Why would someone depreacte a spec that is implemented in nearly every client > in existence, for something that does, best case, exactly the same? That's what I was asking when learned about deprecating XEP-0071. 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. -- 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
Am Di., 3. März 2020 um 21:19 Uhr schrieb Andrew Nenakhov < andrew.nenak...@redsolution.com>: > > I think this XEP should be obsoleted in favour of XEP-0333 Chat > Markers, which does all that XEP-0184 does, plus something more. > > Why would someone depreacte a spec that is implemented in nearly every client in existence, for something that does, best case, exactly the same? Regards ___ 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
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 ___
