[Telepathy] Telepathy Support for OTR

[Sjoerd Simons]

On Wed, 2010-12-22 at 03:11 +0430, WolfRage wrote:
> Hello Developers of Telepathy,
> 
> This is the beginning of many emails to come as we discuss and iron out the details of OTR support in Telepathy.

\o/ :)

> This is my thought process or plan so far: If the CM that is being used
>  has OTR built into then OTR will be available, but not started, it can
>  be activated via the D-Bus. By available I mean that the CM will
>  provide the preferences below signifying that the capability for OTR
>  exists. User's will have preferences implemented through:

Hard to look at things just by the property names, especially for those
on the list that haven't discussed things with you on the telepathy irc
channel :) (btw it's org.freedesktop.Telepathy.Connection, not
Connections)

>  org.freedesktop.Telepathy.Connections.Interface.OTR.Advertise(b)
>  {PROPOSED}

This is, i assume, about actively advertising OTR in direct text chat by
using the spaces and tabs morse code thingy (and not about advertising
it in, say, your xmpp disco capabilities)?

>  org.freedesktop.Telepathy.Connections.Interface.E2ESecurity.Opportunistic(b)
>  {PROPOSED}

And this one would be about opportunistically enable E2E security
without the user asking for it.


> Default settings for the Securable properties of a OTR aviable channel will be:
> org.freedesktop.Telepathy.Channel.Interfaces.Securable.Encrypted(b)=FALSE
> org.freedesktop.Telepathy.Channel.Interfaces.Securable.Verified(b)=FALSE
> org.freedesktop.Telepathy.Channel.Interfaces.Securable.Upgradeable(b)=TRUE
> org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionRequired(b)=FALSE {PROPOSED}
> org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionInterface(s)="OTR" {PROPOSED}

Does this refer to yet another interface on the channel that indicate
some OTR specific bits about the encryption ? And if so which ones?

> org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionState(u)=0 {PROPOSED}
> org.freedesktop.Telepathy.Channel.Interfaces.Securable.AuthenticationChannel(o)=org.freedesktop.Telepathy.Channel.Interface.OTRAuthentication {PROPOSED}

That should just be pointing to a channel object path, not an interface.

As a general nitpick i'm not sure if Securable isn't too general,
something that would indicate that this is e2e security would be good.

> The Object org.freedesktop.Telepathy.Channel.Type.PeerAuthentication
>  {DRAFT} will be inherited by
>  org.freedesktop.Telepathy.Channel.Interface.OTRAuthentication
>  {PROPOSED}
> 
> The Object org.freedesktop.Telepathy.Authentication.Proposal {DRAFT}
>  will be inherited by
>  org.freedesktop.Telepathy.Authentication.Proposal.OTR {PROPOSED}

Why is there a need for OTR specific interfaces here? How does OTR
autthentication/verification differ from say XTLS? Also if we're calling
the channel property Verified we should probably use that jargon in
these names as well.
> 
> Please note: I am recommending that
>  org.freedesktop.Telepathy.Channel.Interfaces.Encryptable {DRAFT} be
>  renamed, or that some of the properties and methods be moved to
>  org.freedesktop.Telepathy.Channel.Interfaces.Securable as DRAFT
>  properties.

That's fine that's why it's a draft.

> I am looking for feedback on what people's thoughts on this plan so far
>  are, also any suggestions and ideas that people have for input will be
>  reviewed by myself. 
> 
> I still have a lot of developer reading to do, I have been working my
>  way into and through the documentation for OTR, and Telepathy. I also
>  need to do some code familiarization for Butterfly, but things are
>  progressing smoothly as I have time I will continue to absorb all that
>  I can. I have so far taken the e2e-encryption spec branch that was
>  created by cosimoc and re-based it against the current spec branch. I
>  will continue to keep my branch up to date as I work, I hope that
>  re-base at least once a month, to reduce the headaches when we finally
>  to try to merge the OTR branch back in.

Please don't take the big-bang approach, start requesting merging for
bits and pieces ASAP. It's fine to have DRAFT specification in
telepathy-spec and ditto in CMs. For the process to work well, merging
bits and pieces that can be reviewed is important :)

>  There is obviously still lots
>  of work to be done just on Spec alone before I begin to program
>  anything. I plan on programming support for OTR in Butterfly CM first
>  as it is programmed in python, the language I am most comfortable,
>  then I will port it to Haze (libpurple) and latter to the other CM's. 



-- 
Sjoerd Simons <sjoerd.simons at collabora.co.uk>
Collabora Ltd.