As I said earlier, some day down the road <acknowledged/> can actually be useful:

But I could see this feature useful for something like voice/video messages to indicate that it has been played by the recipient. At least, Telegram does have such feature (not in group chats though, there it makes no sense and would result in a lot of unwanted traffic).

But from the current sentiment I think it'll be another XEP. On Tue, 26 Mar 2024 at 17:11, Dave Cridland <dave@cridland.net> wrote:

I entirely missed this, and have no understanding of the rationale, but:

1) I'm somewhat ambivalent about removing <received/>, but it's certainly well implemented by my anecdotological studies. 2) Removing <acknowledged/> seems OK, but I've considered various use-cases for which an explicit, user-driven, acknowledgement is useful. But I've never actually implemented it, so... 3) It's really not. Some clients and intermediaries need to know whether they should expect a marker or not. No need to check this prior to sending a <markable/>, true, but useful to track missing markers afterward.

Where was the discussion of this, and (more broadly) how does one know what the discussion and rationale and consensus is if not on this list?

Dave.

On Sun, 10 Mar 2024 at 13:20, Daniel Gultsch <daniel@gultsch.de> wrote:

...

Version 0.5.0 of XEP-0333 (Displayed Markers (was: Chat Markers)) has been released.

Abstract: This specification introduces a method to let the sender, or multiple participants in a group chat, know that a client has displayed messages up to a certain point.

Changelog: * Remove <received/> to not replicate functionality. * Remove <acknowledged/> because it was not implemented in the last 10 years and apparently is not needed. * Remove Disco feature. Opting in via <markable/> is enough (dg)

URL: https://xmpp.org/extensions/xep-0333.html

Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

Well, on the other hand, since the only scenario I can imagine using <acknowledged/> in the wild has significantly different semantics from readdisplayed markers, I think that this is not really necessary in this XEP. On Tue, 26 Mar 2024 at 17:34, Daniel Gultsch <daniel@gultsch.de> wrote:

On Tue, Mar 26, 2024 at 1:11 PM Dave Cridland <dave@cridland.net> wrote:

...

3) It's really not. Some clients and intermediaries need to know whether they should expect a marker or not. No need to check this prior to sending a <markable/>, true, but useful to track missing markers afterward.

Where was the discussion of this, and (more broadly) how does one know what the discussion and rationale and consensus is if not on this list?

I can add it back. When I showed this to people in the XSF room I guess most people just considered the "does it hurt to opportunistically include the <markable/>" side of things. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org