[OTR-dev] pidgin-otr rewrite

[Howard Chu]

Rob Smits wrote:
> 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)

I wasn't sure what to title this. If you don't already have a keypair for the 
chosen account, it will cause it to be generated, so in that case, it really 
is "Getting" the key. It was too awkward to try to preserve the pidgin-otr 
menu structure here.

> -When running in Pidgin, closing the "Manage Fingerprints" window
> causes a crash

OK, I'll doublecheck that. If you have a stacktrace handy that would give me a 
head start.

  -When running in Pidgin, the conversation status listed in
> the OTR menu associated with the conversation is not always up to date

Did you patch pidgin with this? http://developer.pidgin.im/ticket/14843 That 
patch specifically was to address this problem.

> 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.)

AFAIK, Finch has no UI to move contacts into groups, but it will work with 
groupings created elsewhere (e.g. in Pidgin).

> 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.

OK. I would guess this can be fixed, at least.

> 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).

OK. Looks like neither finch nor pidgin send a signal to update the 
conversation features in this case, so the plugin doesn't get any notification 
or chance to update. So this needs to be patched there to make it work well.

> 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).

I'll keep that in mind as a fallback. ;)

> 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.

OK, I understand. I tried to preserve as much as possible of the GTK plugin 
functionality, but some of the custom button/menu stuff just wasn't feasible.

> To summarize:
> -Great work on the libpurple plugin

Thanks for your review.

> -Grouped contacts should be addressed (even if that means outputting a
> message to indicate they are not fully supported)

OK.

> -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

I'll look into the version 3 stuff.

So I guess the conclusion here is that purple-otr should just exist on its own 
as a fork of pidgin-otr, and will not be merged back in to the pidgin-otr code 
base? It's clear that we can't preserve *everything* that the GTK UI can do, 
and if people can't live without those bells and whistles, then there doesn't 
seem to be any other choice.

> 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/

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/