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