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

[Jacek Wielemborek]

W dniu 22.06.2015 o 12:17, Ian Goldberg pisze:
> 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

Okay, but on the other hand, this is a problem likely to hit any
transport layer regardless of whether it's AIM, XMPP or something else
as long as it is possible that the client software would be restarted. I
believe that OTR should handle that. Also, doesn't OTR already have the
capability to not only act as a filter (encrypting messages), but also
send those on their own by communicating to the backend?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20150622/5ed4d532/attachment-0001.pgp>