On Mon, Sep 16, 2013 at 5:11 AM, Ian Goldberg <[email protected]> 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 <[email protected]> >> 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 > [email protected] > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev -- Nathan Wilcox Least Authoritarian [1] https://github.com/agl/xmpp-client _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
