On 12/17/2014 11:46 AM, Winfried Tilanus wrote: > In response to my comment that it left a lot of information > unencrypted he suggested to start a second OTR protocol in XMPP, one > that does proper service discovery and properly encrypts everything > of the stanzas that should be encrypted. Optionally embedding the > plain version within it when you need to transverse to an other > protocol.
Agreed (that there should be an XMPP flavor of OTR); I'm not so sure that embedding the plain version within the XMPP discovered version would be helpful, this sounds like an edge case that won't often happen in 'real life' to me. One of the major problems with XMPP in general as I see it, is that extensions try to cover too many little edge cases that aren't ever likely to arrise and be a "one size fits all" solution. This leads to them being difficult to implement properly, which leads to incompatibilities and fragmentation among clients. Keeping things simple, and straightforward is the way to go IMO, especially in a security sensitive environment. That being said, embedding the normal OTR exchange isn't that complicatedm it just seems unnecessary to me; sorry, got a little sidetracked there. > Well... I think the first step should be documenting the most common > case, OTR'ing the content of a message in the OTR way.... Also agreed. Let's pump out a basic informational XEP that describes the state of OTR today, and in the mean time we can be discussing how we want to expand it in future. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
signature.asc
Description: OpenPGP digital signature
