[Standards] Current OTR Info

Sam Whited sam at samwhited.com
Sun May 8 17:17:03 UTC 2016

On Sun, May 8, 2016 at 12:05 PM, Sam Whited <sam at samwhited.com> wrote:
> On Wed, Apr 27, 2016 at 3:48 PM, Chris Ballinger <chris at chatsecure.org> wrote:
>> A quick fix would be to only send delivery receipts if the message could be
>> successfully decrypted.
> I think this makes sense as a recommendation for the informational
> XEP, but I'd love to know if anyone is actually doing it in the wild.
> /cc Daniel

I just sent this response, and then almost immediately did an about
face and changed my mind (I'm fickle that way). I actually think it is
a bad idea to send delivery receipts only if the message can be
decrypted; my reasoning is as follows:

Because the delivery receipt spec was not intended for this (and
semantically is just supposed to express "delivery" not
"readability"), and because there is no current consensus on when
delivery receipts are sent during an OTR session, differnt clients
will do different things; by allowing delivery receipts to be used for
both, we'd be encouraging confusion and a lack of interoperability
between clients (some clients may want to convey delivery and
redability separately, as you mentioned). A practical example of this
being confusing might be something like the following: Imagine I had a
client open and I establish an OTR session with a remote resource and
begin sending messages. I get back delivery receipts after those
messages are decrypted. Then, for some reason, I send a message to
another resource (maybe there was a network blip and the resource I
was talking too loses their connection) that does not support OTR at
all: I continue to get message delivery receipts and never notice
anything has changed, even though the remote resource can no longer
read my messages. This feels poor.

In fact, in the delivery receipts introduction it states:

> Note well that this specification does not distinguish between delivery and display, as was done in the message events protocol, in part because no implementations of XEP-0022 made that distinction. However, in the absence of such a distinction, readers need to understand that this protocol can provide only a notification that a message has been received at a client, i.e. delivered to a client, not that the message has been actively read or understood by a human user (if any).

For this reason I think a separate XEP should be written, and the
recommendation in this informational XEP (if any) would be to send
delivery receipts on receipt of a message, not after decryption.

Thoughts welcome.


Sam Whited
pub 4096R/54083AE104EA7AD3

More information about the Standards mailing list