Ian Goldberg <i...@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.
pgpJcW589V5kY.pgp
Description: PGP signature
_______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev