sam at samwhited.com
Fri Dec 19 19:51:02 UTC 2014
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
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Standards