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

[Christian Anderson]

On 06/04/2011 07:36 PM, João Paulo Rechi Vita wrote:
> When writing down the whole API I've realized that "in progress"
> should actually be broke down into tree states: REQUEST_SENT,
> REQUEST_RECEIVED, and AKE_STARTED.
>
> After finding my way through telepathy-spec XML syntax, I've managed
> to write down whole API proposal and uploaded it at
>
> http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/spec/Connection_Interface_OTR.html
> http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/spec/Channel_Interface_OTR.html
>
> I left key storage and peer authentication information storage
> completely for the UI, that's why it doesn't appear on the proposal
> above.
>
> I've also uploaded my sketch of the state machine, since it may help
> following the spec:
> http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/state_machine.jpg
>

Thanks for the concrete proposal!

Small questions:
*Should PeerKeyReceived broadcast the type of the received key? Did you
decide not to have d-bus objects corresponding to the keys?
*Why are Versions and RequireEncryption duplicated on the Connection and
the Channel but the other properties are not?
*I think you should specify the meaning of the boolean in the
PeerAuthenticationConcluded signal.

I also have a number of questions related to handling "OTR overtures".
There are 5 ways that a peer, implementing the OTR spec, might initiate
communication with us:
1. A whitespace-tagged message.
2. An OTR error message.
3. An OTR query message.
4. A DH-commit message.
5. Version 1 key exchange message

You have introduced the states REQUEST_SENT and REQUEST_RECEIVED to give
the client the freedom of accepting and rejecting sessions on the fly.
Is it worth the extra complexity? Why not just handle each of the 5
queries based on our channel's policies? As it stands, there are some
issues arising from these two states. For instance:

*What happens if I call RequestSession while in the REQUEST_RECEIVED
state and then realize I want to accept my peer's session request?
*What happens when I receive a session request while in the FINISHED state?

I think these states add unneeded complexity. I think they are logically
problematic because it is quite possible for me to have both "SENT" and
"RECEIVED" a request.

What I imagine as an alternative is handling each of the 5 overtures
based on the policy flags that are set in the associated connection. I
am still not sure how each of the 5 overtures is handled depending on
the 4 possibles values of (AutoStart | AutoAccept). Could you specify
exactly what those two flags mean?

christian