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 > [email protected] > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
