[Telepathy] Telepathy Support for OTR

[Simon McVittie]

On Wed, 22 Dec 2010 at 03:11:19 +0430, WolfRage wrote:
> My purpose here is to patch this bug #296867 (Launch Pad) which is bug
> #16891 on the Free Desktop Bugzilla.

FWIW, Telepathy's official bug tracking is via freedesktop.org, so we generally
consider fd.o bug numbers to be the important one; Launchpad bugs are
specific to Ubuntu (or other projects hosted on Launchpad, which we're not).

We usually do this sort of discussion on a fd.o bug report so it's easier to
find (mailing list archives split by month aren't very useful for long-running
projects). If you don't mind, I'll direct subsequent discussion to the
relevant bugs - anyone who's interested in following it can add themselves to
the bugs' Cc lists.

You may find it easier to discuss things in email / on bugs if you abbreviate
org.freedesktop.Telepathy to ofdT throughout :-) I've done that when quoting
you, for a bit more clarity.

> ofdT.Connections.Interface.OTR.Advertise(b) {PROPOSED}

(It's Connection, not Connections.)

This would presumably be a ConnectionManager parameter [1] with the
Conn_Mgr_Param_Flag_DBus_Property flag indicating that it's also the name of
a D-Bus property [2]?

[1] <http://telepathy.freedesktop.org/spec/Connection_Manager.html#Method:RequestConnection>
[2] <http://telepathy.freedesktop.org/spec/Connection_Manager.html#Flags:Conn_Mgr_Param_Flags>

> Default settings for the Securable properties of a OTR aviable channel
> will be:

(D-Bus terminology: these are properties.)

> ofdT.Channel.Interfaces.Securable.Encrypted(b)=FALSE
> ofdT.Channel.Interfaces.Securable.Verified(b)=FALSE
> ofdT.Channel.Interfaces.Securable.Upgradeable(b)=TRUE

(It's Channel.Interface, not Interfaces.)

Upgradeable=TRUE doesn't seem to tell us whether it's possible to make
Encrypted become true, or whether it's possible to make Verified become true,
or both. Perhaps Encryptable, Verifiable as separate properties?

> ofdT.Channel.Interfaces.Securable.EncryptionRequired(b)=FALSE {PROPOSED}

This is presumably requestable (includable in a channel request) but can't
otherwise be changed?

I'm not sure that we need this property - we could just say that putting
Encrypted=TRUE in a channel request means encryption is required? In practice
the recommended thing would be to say Encrypted=TRUE, Verified=TRUE (to require
both), or not mention either of them (to have the default behaviour -
opportunistic encryption if you don't mind server-side logs becoming useless,
or no encryption if you want server-side logs to be useful).

I suppose if you'd enabled opportunistic encryption, it might even make
sense to say Encrypted=FALSE in a channel request, to turn off opportunistic
encryption for this one channel (so that it can usefully be logged by your
server), but that's pretty obscure.

> ofdT.Channel.Interfaces.Securable.EncryptionInterface(s)="OTR" {PROPOSED}

Shouldn't the value of this property be a D-Bus interface name, such as
ofdT.Channel.Interface.OTRAuthentication?

> ofdT.Channel.Interfaces.Securable.EncryptionState(u)=0 {PROPOSED}

Moved from the Encryptable proposal, presumably?

> ofdT.Channel.Interfaces.Securable.AuthenticationChannel(o)=ofdT.Channel.Interface.OTRAuthentication {PROPOSED}

I assume you mean "the object path of a channel implementing
OTRAuthentication"?

For generic E2E support, this would in fact have to be the object path of
a channel implementing both ofdT.Channel.Type.PeerAuthentication and the
interface mentioned in the EncryptionInterface property (which would
be either OTR or XTLS to start with).

> Please note: I am recommending that ofdT.Channel.Interfaces.Encryptable
> {DRAFT} be renamed, or that some of the properties and methods be moved
> to ofdT.Channel.Interfaces.Securable as DRAFT properties.

Encryptable should indeed be called Securable - I made that change while
adding a partial version of it to the spec. For E2E support, you'll probably
need the rest of the interface.

The DRAFT thing only works at a per-interface granularity, so the way to do
this would be to have something like this:

ofdT.Channel.Interface.Securable (stable)
ofdT.Channel.Interface.Securable.DRAFT (not stable)

and move properties from the draft to the stable one as they become stable.

> 1. git://gitorious.org/wolfrage-telepathy/otr.git  My git branch for Spec, re-based with Origin.

For those following along at home, the web interface for that branch is
<http://gitorious.org/wolfrage-telepathy/otr>. Some quick notes about that:

Your commits that say "Re-basing the file forward" seem to have lost their
original commit messages? Commit messages should briefly describe what changed
(first line) and why (subsequent lines, after an empty line). Browse
through the git history to see how they work in practice.

You seem to have committed the conflict marker lines (starting with <<<<<<<,
=======, >>>>>>>), which isn't how they're meant to work (and will break
processing of the XML). When you get conflict markers, it means that changes
made in one commit conflicted with changes from another commit, and git
couldn't work out what the desired result is. The intention is that you work
out how to merge the two sets of changes ("resolve the conflict"), delete
the conflict markers and commit the result.

For instance, if a commit from you and a commit from Cosimo both added some
text, the right conflict resolution might be to add both bits of text - unless
your text and Cosimo's text contradict each other or are redundant, in which
case you might choose one and delete the other.

    S