[OTR-dev] Could OTR be made more fault-tolerant?

[Ian Goldberg]

On Mon, Jun 22, 2015 at 10:16:23AM +0200, Jacek Wielemborek wrote:
> W dniu 22.06.2015 o 04:08, Nathan of Guardian pisze:
> > 
> > 
> > On Sun, Jun 21, 2015, at 10:22 AM, Jacek Wielemborek wrote:
> >> 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?
> > 
> > With ChatSecure, we handle this using XMPP message delivery receipts, so
> > that both ends absolutely know when the message has been received or not
> > through a visual checkmark or X. We also transparently handle session
> > refresh, so that if you move between devices during an OTR chat, or if
> > one side comes online while the other-side is trying to send it a
> > message, the OTR session will refresh, and the queued message will be
> > delivered. Finally, in our v14.2 release coming out this week, you can
> > set your OTR session to "FORCE", and we will queue all outbound messages
> > until a valid OTR session is enabled.
> > 
> > While Ximin and other's work on next-generation message protocols is
> > important, I think the current OTR+XMPP is quite capable, but just
> > poorly implemented by most apps from a usability and user experience
> > perspective.
> > 
> > +n
> > 
> 
> The question is whether this is a protocol or front-end issue. How much
> work would it take to call what you implemented in ChatSecure as a new
> version of OTR and somehow get it integrated with the upstream?

The OTR protocol doesn't get to know things about the IM network
protocol (such as AIM, XMPP, etc.), so XMPP-specific details like
message delivery receipts aren't appropriate for the base OTR layer.

   - Ian