[OTR-dev] pidgin-otr rewrite

[Rob Smits]

Hi Howard,

I've spent some time looking at your libpurple plugin. Overall I think it
turned out very well. A lot of the original functionality remains, and it
has an expectedly consistent behaviour between Pidgin and Finch.

 I did see some issues. If you need more information from me about these I
would be happy to provide: 
-On the OTR menu associated with the contact list, there's a "Get Private
Key" menu item that will actually display your fingerprint (and not private
key) -When running in Pidgin, closing the "Manage Fingerprints" window
causes a crash -When running in Pidgin, the conversation status listed in
the OTR menu associated with the conversation is not always up to date

One of the things that added some complexity to the GUI in pidgin-otr 3.2.0
was handling "grouped contacts" properly. By this I mean a contact that has
more than one option on their "Send to" conversation menu. (You can create a
contact like this in Pidgin by choosing "expand" on the context menu for a
buddy in the contact list, and drag some other contacts into this new
grouped contact. I'm not sure about the specific steps for doing this in
Finch, but grouped contacts are supported.) 

Currently the libpurple plugin doesn't handle these grouped contacts
perfectly.  For example, let's say Alice has a grouped contact Bob (with
contacts Bob1 and Bob2). If Alice starts an OTR conversation with Bob1, and
then she receives a message from Bob2, I didn't see any indication that this
new incoming message is unencrypted. Also, for the OTR menu associated with
a grouped contact conversation, it is not clear whether the menu items will
affect Bob1 or Bob2 (it did not appear to always be the Bob that was
selected in the "Send to" menu).

I'm not sure if the goal if the libpurple plugin is to handle things like
grouped contacts perfectly, but if it doesn't, perhaps a warning message
indicating this would be helpful (i.e., when starting a conversation with a
grouped contact).

OTR protocol version 3 will add another layer of complexity to this. When
looking at this from the perspective of pidgin-otr, a PurpleConversation can
have multiple OTR connection contexts associated to it. When negotiating an
OTR conversation, each party includes a persistent instance tag (generated
once and saved to disk). The idea is that if you are logged in multiple
times, you should have distinct instance tags associated with each session.
If OTR receives a message intended for an instance tag that doesn't much its
own, it will discard the message. The idea here is to avoid the issues that
exist with OTR protocol version 2 when someone tries to initiate a private
conversation with someone who has multiple OTR-supported clients logged in
(under IM protocols that always send to all logged in sessions, this can
cause a continuous loop of re-sends between the parties. On other protocols
you will get OTR errors). 

When instance tags are in the picture, you similarly would indicate when an
incoming message has a different status (i.e., private vs. unverified). You
should be able to select a particular instance to send to. The
in-development version of pidgin-otr also has the ability to always select
the "best" instance (by privacy level), or the most recent instance.
Depending on the IM network, instances can also add some issues. If an IM
network does not always deliver all messages to all logged in sessions, when
you chose an instance that is not the most recent one, the other party may
not actually receive the message (recall that if the OTR session that
receives the message sees that it is actually intended for a different
instance, it will just drop the message... and if an IM network does not
always deliver to all logged in session, you can see how this is a problem).

So I'm not sure we would want to switch to a pure libpurple plugin as the
"official" Pidgin plugin. With the GTK plugin we can, for example, make the
status of conversations with a grouped contact very obvious, without even
requiring that the user opens a menu. But having an OTR plugin available now
that works with Finch is great.

To summarize:
-Great work on the libpurple plugin
-Grouped contacts should be addressed (even if that means outputting a
message to indicate they are not fully supported) 
-Protocol version 3 fixes the potential for infinite OTR re-negotiations,
and you should consider supporting this in the future 
-The instance tags in v3 do add complexity, and not things you can ignore

Regards,
Rob

> -----Original Message-----
> Sent: February-27-12 6:02 PM
> Subject: Re: [OTR-dev] pidgin-otr rewrite
> 
> Howard Chu wrote:
> 
> Has anyone here tried it out? Any reactions to the UI changes I made?
> 
> --
>    -- Howard Chu
>    CTO, Symas Corp.           http://www.symas.com
>    Director, Highland Sun     http://highlandsun.com/hyc/
>    Chief Architect, OpenLDAP  http://www.openldap.org/project/
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev