[OTR-dev] OTR, Pidgin & Guaranteed message delivery

Nathan Wilcox nathan at leastauthority.com
Tue Sep 17 11:15:11 EDT 2013


On Mon, Sep 16, 2013 at 5:11 AM, Ian Goldberg <ian at cypherpunks.ca> wrote:
> On Sun, Sep 15, 2013 at 08:02:58PM -0700, Gregory Maxwell wrote:
>> On Sun, Sep 15, 2013 at 2:43 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> > Ian is right that there's really no such thing as guaranteed delivery
>> > in IM systems
>>
>> At the level of an OTR protocol it could, however, be guaranteed that
>> all messages are delivered or that service is completely denied. (e.g.
>> by including the hash of the oldest unacknowledged prior message in
>> every message, and the far end requesting any missing messages, then
>> only displaying messages in order).
>
> The network model for OTR is that the underlying IM system may drop
> messages, but any messages it delivers will be delivered in order.  It
> would make for a really weird conversation if messages on an IM network
> were delivered out of order.  That said, we've had reports that
> SecondLife's messaging system reorders messages.  If OTR sees a old
> message delivered after a new one, the old one is dropped.
>
> So yes, we could add a reliability layer on top of whatever IM network
> we have, but I personally think that's out of scope.  If you really want
> a reliable IM network, you can just use one, no?
>

How would this work in practice?  Suppose I'm using an XMPP service
that does retries across sessions (store and forward), and the other
party restarts their client.  Now they have a new OTR instance in a
new process which receives a message.  What does the end user on that
end see?  What do I, as a user, see?

In practice, it *seems* common that I see messages like "the other
side sent a message we can't decrypt" at times near when users leave
or join.  I have plenty of anecdotal evidence, verified by
cut'n'pasting from both sides of the connection, that there are often
messages the sender sees as having sent, which the recipient does not
see (although they may see protocol error messages).  (Note: My
anecdotal evidence is conflated between pidgin+otr, adium+otr, and a
Go xmpp+otr+tor client [1] which may not be based on libotr.)

So, what I'm hoping for is authenticated message receipts, so that as
a user, when I type something, I see a difference in the UI between
when that message has been decrypted and acknowledged on the remote
side, versus when it has gotten lost in the sometimes clogged
plumbing.  (I realize if receipts are dropped a sender may incorrectly
believe a message was not delivered, but IMO, mistakenly repeating
oneself is much better than mistakenly dropping something.)

A few questions:

Does OTR protocol have this facility?  How about libotr?  I haven't
spent the time yet to be clear on which observed behaviors are
UI/client stuff versus libotr.


>    - Ian
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev



-- 
Nathan Wilcox
Least Authoritarian

[1] https://github.com/agl/xmpp-client



More information about the OTR-dev mailing list