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

[Greg Troxel]

Ian Goldberg <ian at cypherpunks.ca> writes:

> 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:
>> > 
>> > 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.

It might be nice to have the equivalent of an RFC addressing OTR/XMPP
integration in terms of best practices.  I can see your point about that
being out of scope for OTR proper, but it also seems like struggling in
code for each of N XMPP implementations isn't the right place either.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20150622/16d1778e/attachment.pgp>