[Standards] Comments on Chat Markers

Kevin Smith kevin at kismith.co.uk
Thu Jul 4 10:45:24 UTC 2013

After reviewing the Chat Markers proposal for Council, I have two main concerns.

1) It's not clear to me that by adding a <read/> equivalent to 184,
using MAM and chat states that we wouldn't have a simpler solution
with more re-use of existing paradigms. This comment isn't blocking.

2) It seems to me that this proposal is providing users with the
highest assurance of delivery ("This message has been read and
acknowledged by the user"), when it's possible that some of the
acknowledged messages were never delivered. This seems serious to me
in situations like:

<User A> Something terrible has happened, please send help.
[S2S blips, message gets lost]
<User A> There's high winds here.
[S2S is back, message gets delivered]
User B now acknowledges the 'high winds' message as read.
Because of the 'up to this point' nature of the proposal, User A has
now had it acknowledged that User B has read the message about needing
to send assistance.

There seem to be multiple ways to address this - one is to use an
approach more like 184, with per-message acks. Another is to say that
this proposal requires reliable transport, and that every message
needs to have 184 as well as chat markers in order for the markers to
be believed. Another is to put a banner across the top of the chat
markers spec saying that the acks it provides are only heuristic and
can't be used to assure users of messages being delivered or read.

I think it's worth addressing this somehow, using one of the above
suggestions or some other, before this is published as implementation
as-is could conceivably lead to fatal misunderstandings in some of the
situations XMPP gets used.


More information about the Standards mailing list