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

[João Paulo Rechi Vita]

Hello Danni, thanks for the info! Comments inline.

2011/6/3 Danielle Madeley <danielle.madeley at collabora.co.uk>:
> On Fri, 2011-06-03 at 00:04 -0300, João Paulo Rechi Vita wrote:
>
>> > 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.
>> >
>>
>> Isn't this the normal behavior for text channels? Does channels are
>> created when the user opens the IM window, or when she starts typing
>> (with the "peer is typing" notification message) ?
>
> Typically requesting a channel is done when you do some action like
> double clicking the contact. This creates the channel on the bus ASAP,
> which is then passed to the Handler, which will do something like create
> the window.
>
> At this stage the handler will query for properties on the channel, like
> whether you need a password to join (Chan.I.Password) or need to set up
> some E2E encryption.
>

So this is when our side is starting the conversation. Then at this
point the handler will check OTR properties and according to them
trigger the following actions:

 - If RequireEncryption is set, it will send and OTR query message on
the channel, and wait for the peer response. If the peer starts the
AKE, all good and we proceed normally (possibly starting SMP to
authenticate the peer). If the peer answer with a plain-text message,
the user is prompted whether she wants to end the conversation or
continue without encryption (on the latter disabling the
RequireEncryption property on that channel and for that conversation
only).

- If RequireEncryption is not set, when the user requests to send the
first text message, it will check the Advertise connection parameter
and if set, add the OTR whitespace tag to the message.

> When someone else messages you, a channel is created in response to
> this. This is again passed to the Handler, which can create a window and
> then look up properties in the same way.
>

And at this point the following can occur:

- If the incoming message is an OTR query message and AutoAccept  is
enabled, it'll send the first AKE message to the peer, accepting the
OTR session request. If AutoAccept is not enabled, it'll prompt the
user whether to accept the OTR session request.

- If the incoming message is plain-text with a whitespace-tag
attached, and AutoStart is enabled, it'll send the first AKE message
to the peer. If AutoStart is not set, it'll display the message
normally to the user, and may show some indication on the UI that the
peer supports OTR (note that if Advertise is set, it'll still add the
whitespace-tag on the first outgoing message, which may trigger the
peer to start the AKE).

- If the incoming message is plain-text without a whitespace tag, then
no OTR information is known and the client handles this conversation
as usual (giving the option for the user to trigger a OTR session
request, to check if the peer supports it).

-- 
João Paulo Rechi Vita
http://jprvita.wordpress.com/