Re: [Standards] XEP-0184: Message Delivery Receipts and XEP-0333: Chat Markers
>> 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. That has been pretty much exactly my TODO list for three years or so. I was leaning heavily toward just dropping ACKs. Plus I'd like to allow people to send display markers opportunistically into group chats. (Which is another reason why 0333 and 0184 a different and we shouldn’t just make 0184 obsolete.) cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0184: Message Delivery Receipts and XEP-0333: Chat Markers
On Wed, 4 Mar 2020 at 11:45, Marvin W 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-unsubscr...@xmpp.org >
Re: [Standards] XEP-0184: Message Delivery Receipts and XEP-0333: Chat Markers
ср, 4 мар. 2020 г. в 16:46, Marvin W : > In contrast XEP-0333 serves a mostly different purpose: it notifies the > sender only of the last received/displayed/acknowledged message. And that is the right way to do it. In the decades of using XMPP intensely I have probably had a dozen of incidents when there was a lost message among sent of delivered ones. So notifying only about the last received/displayed message saves a lot of traffic. And for those few instances when errors do happen (as I said, once a year on average), the most elegant way was to use attachment/reactions mechanism to attach an error to this message. > 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 way XMPP works allows to consider previous messages as 'delivered'. > The acknowledged feature also seems to be barely used (also > because it is questionable how to realize it UI wise). Actually, it's pretty easy. You have a voice message, it is delivered to a contact, displayed, but not played. Once a user plays it to the end, a client can send an ack. Then a sender sees that a voice message was played by a recipient. Of the existing messengers it is done very well by Telegram. We definitely plan to do that with Xabber. The only meaningful improvement to 0333 should be to state that such acknowledgement should not be sent to LAST message, as such use definitely supposes a more granular approach to acknowledging messages. > 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. So you're ready to break a useful and working XEP just to stop me from (rightfully) claiming that XEP-0184 is obsolete? No wonder XMPP is such a mess. :-D -- 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] XEP-0184: Message Delivery Receipts and XEP-0333: Chat Markers
At the risk of AOLing, I think I agree with pretty much everything Marvin says here. /K > On 4 Mar 2020, at 11:45, Marvin W 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. > > 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. > > --- > > 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 > 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. > > 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). > > 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. > > 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-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0184: Message Delivery Receipts and XEP-0333: Chat Markers
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. 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. --- 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 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. 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). 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. 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-unsubscr...@xmpp.org ___
