Could OTR be made more fault-tolerant?

[Michael McConville]

On Sun, Jun 21, 2015 at 04:24:48PM +0200, Jacek Wielemborek wrote:
> One of my friends constantly complains about OTR giving him no feedback
> when he sends messages to me while I'm offline over XMPP (Pidgin). Then,
> when I turn on the computer, I have no OTR session currently active and
> all I'm getting is an error message that I got a message that I cannot
> decrypt. This makes me ask him "what have you sent two days ago when I
> was offline" at best and at worst, messages get lost. I'm getting the
> impression that there should be support either from the library or the
> UI to make this easier.

There's no way for his client to know whether yours ended the session.
You could have just briefly lost connectivity or closed your laptop with
the session still open, so there's no obvious action for his client to
take. I agree that false positives are likely less annoying than false
negatives, though.

> Another problem that we are constantly getting is that when we try to
> communicate after a few hours of inactivity, it often happens that one
> of us switched between the machines (e.g. by suspending the laptop and
> turning on the PC that also uses the same XMPP address) and the session
> key is no longer valid. To avoid this, I usually manually refresh the
> OTR session whenever significant amount of time passed, but I'm getting
> the impression that I'm walking around a problem inherent to OTR.
> 
> Perhaps there should be some "pinging" mechanism in place or when a
> undecipherable message gets received, an error message should be sent?
> The client could then discard such an error if he keeps a trusted
> session on another channel, basically doing what I'm doing when the
> problem happens. What do you guys think about this?

Interesting idea. The simplest way to do this might be in the Pidgin
plugin rather than the OTR protocol/library. XMPP message receipt
support should be included in Pidgin 3.0:

	https://developer.pidgin.im/ticket/6940

It wouldn't be as robust as an addition to OTR, but it could be close.
It's more realistic, too. Of course, it wouldn't work for most protocols
other than XMPP, but it seems that an overwhelming majority of OTR users
use XMPP.