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?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
