[Telepathy] Fwd: GSoC Project: Add OTR support to Telepathy/Empathy for XMPP

[Will Thompson]

On 01/06/11 06:04, João Paulo Rechi Vita wrote:
> On Wed, Jun 1, 2011 at 01:20, Christian Anderson <christian at avtok.com> wrote:
>> On 05/29/2011 06:56 PM, João Paulo Rechi Vita wrote:
>>> The problem is that Channels only exists for already established
>>> conversations. The client needs a way to get/set the default policies,
>>> that would be on the Connection object.
>>
>> If the client can get/set policies on a Connection object, why not just
>> get/set them on each Channel? (There may be a very elementary answer to
>> this, I'm just not very familiar with Telepathy). Are you suggesting
>> having default policies on each Connection and specific policies on each
>> Channel?
>>
> 
> Yes, default policies on each Connection object (one per Connection
> Manager)

A clarification: there is one connection per active connection to a
server. For instance, I have three enabled XMPP accounts (my personal
one, Facebook, and my Collabora account) right now; one copy of Gabble
is running, with three Connection objects.

When you set your status to Offline, there are no connection objects. To
make these settings persist, you'd make them also be connection
parameters with the DBus_Property flag
<http://telepathy.freedesktop.org/spec/Connection_Manager.html#Flags:Conn_Mgr_Param_Flags>;
Empathy's OTR preferences page would get and update their values on the
Account object
(<http://telepathy.freedesktop.org/spec/Account.html#Property:Parameters> and
<http://telepathy.freedesktop.org/spec/Account.html#Method:UpdateParameters>
respectively), and the Account Manager takes care of setting them on new
and existing connections.

> and specific policies on each Channel object. Note that
> Channel objects only exists for ongoing conversations, that means most
> of the time there will be no Channel objects around. Also, there are a
> few things I think make more sense to be Connection-wise only (for
> instance Advertise, AutoStart, and AutoAccept) since then should be
> checked before the conversation starts (and the Channel is created).

You want the channel to be created immediately, without waiting for
network traffic, I think. This means the Empathy chat window can show
the user what's going on, as in a throbbing padlock or something while
the OTR session is initiated.

I think it makes sense for the current OTR state to be properties on a
channel interface, and also for the Connection to have a property for
auto-starting OTR. This means applications requesting text channels
don't have to care about OTR: they can request the channel, and the
default setting will take effect. The preference has to be stored
somewhere: it may as well be a account parameter/connection property as
described above.

I agree that Advertise :: Boolean lives on Connection.I.OTR.

>>> I agree there is some stuff missing, but just don't like exposing this
>>> protocol-specific nomenclature to the clients.
>>
>> I don't know what "best practice" is. Not exposing protocol-specific
>> nomenclature seems fine to me. How about something like:
>>
>> Enabled: Boolean. Must be true or we don't look at any of the other flags.
>> SupportedVersions: String
>> //"Enabled" and "SupportedVersions" combined gives ALLOW_VX
>>
>> AutoStart: (WHITESPACE_START_AKE | ERROR_START_AKE)
>> Advertise: SEND_WHITESPACE_TAG
>> RequireEncryption: REQUIRE_ENCRYPTION
>>
>> This is just a summary of your proposal except I left out AutoAccept.
>> You're saying that the AutoAccept bit would determine whether or not we
>> prompt the user when we receive an OTR Query Message? Is this necessary?
>>
> 
> Yes, that was exactly my idea regarding "AutoAccept". It's not
> strictly necessary for OTR to work, but I think it could be useful and
> will not add complexity to the API nor to the implementation. On the
> same fashion, I'm not quite sure about the need for "Enabled", but it
> wouldn't hurt. I'm personal feeling is that is better to have the both
> of them in, since the worst that can happen is all clients always
> setting them to True for all CMs.

I guess it doesn't add much complexity to put this into CMs, and it
makes the auto-accept logic much easier for the UI. My instinct would be
to keep auto-accept in the UI, but putting it in the CM does sound good.

>> This could be my ignorance of Telepathy, but doesn't the client need
>> some way to tell the CM that it has accepted a key? In particular, when
>> Alice receives Bob's key during the AKE, her CM will hand it to the
>> client (Empathy, say) and the client will have to determine how to
>> handle the key based on the information that it has stored about Bob and
>> based on its policy. For instance, it might just accept all keys. Or it
>> might prompt Alice if this key has a different fingerprint from Bob's
>> stored key. etc.
>>
> 
> Yes, after the AKE the CM should tell the client the fingerprint of
> the key being used by the peer, so the client can react accordingly.
> But isn't a signal be sufficient for that?

There should be a property on the channel with information about the key
(maybe the path to an object representing the key), and methods for the
UI to call to accept or reject the key as appropriate.

>>> Also, I don't think the authentication
>>> state should be exposed to the clients, since they wouldn't do nothing
>>> useful with this information.
>>
>> Sure, but in that case there should probably be a new message state:
>> PLAINTEXT, AUTHENTICATING, ENCRYPTED, FINISHED
>>
> 
> That's true.

What do you mean by “authentication state”? OTR protocol details with
more information than “not encrypted”/“in
progress”/“encrypted”/“encrypted + authenticated” or so? Having that
kind of information available makes sense to me; I agree that much more
detail is likely to be ignored by clients.

-- 
Will