From rdfsmits at cs.uwaterloo.ca Thu Mar 8 00:04:05 2012 From: rdfsmits at cs.uwaterloo.ca (Rob Smits) Date: Thu, 8 Mar 2012 00:04:05 -0500 Subject: [OTR-dev] pidgin-otr rewrite In-Reply-To: <4F4C0B59.7020103@symas.com> References: <4EECB18F.9030305@symas.com> <4EED7D4C.8030806@bleeter.id.au> <4F4C0B59.7020103@symas.com> Message-ID: <026501ccfce8$e50739d0$af15ad70$@cs.uwaterloo.ca> 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 From hyc at symas.com Thu Mar 8 05:58:00 2012 From: hyc at symas.com (Howard Chu) Date: Thu, 08 Mar 2012 02:58:00 -0800 Subject: [OTR-dev] pidgin-otr rewrite In-Reply-To: <026501ccfce8$e50739d0$af15ad70$@cs.uwaterloo.ca> References: <4EECB18F.9030305@symas.com> <4EED7D4C.8030806@bleeter.id.au> <4F4C0B59.7020103@symas.com> <026501ccfce8$e50739d0$af15ad70$@cs.uwaterloo.ca> Message-ID: <4F5890B8.7060101@symas.com> 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/ From hyc at symas.com Thu Mar 8 06:10:30 2012 From: hyc at symas.com (Howard Chu) Date: Thu, 08 Mar 2012 03:10:30 -0800 Subject: [OTR-dev] pidgin-otr rewrite In-Reply-To: <4F5890B8.7060101@symas.com> References: <4EECB18F.9030305@symas.com> <4EED7D4C.8030806@bleeter.id.au> <4F4C0B59.7020103@symas.com> <026501ccfce8$e50739d0$af15ad70$@cs.uwaterloo.ca> <4F5890B8.7060101@symas.com> Message-ID: <4F5893A6.3030909@symas.com> Howard Chu wrote: > 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. By the way, this feature was already fully described in the README... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From devnull at iamdevnull.info Thu Mar 8 06:52:50 2012 From: devnull at iamdevnull.info (Dev Null) Date: Thu, 8 Mar 2012 11:52:50 +0000 Subject: [OTR-dev] pidgin-otr rewrite Message-ID: <705927527-1331207571-cardhu_decombobulator_blackberry.rim.net-869442645-@b3.c1.bise6.blackberry> I don't have much to add to the conversation development-wise, but as for grouping contacts in finch, you can 'expand' contacts in finch with a space, tag contacts to be moved with t, and move them to the expanded contact with ctrl-x p. -- /dev/null From rdfsmits at cs.uwaterloo.ca Thu Mar 8 15:45:01 2012 From: rdfsmits at cs.uwaterloo.ca (Rob Smits) Date: Thu, 8 Mar 2012 15:45:01 -0500 Subject: [OTR-dev] pidgin-otr rewrite In-Reply-To: <4F5890B8.7060101@symas.com> References: <4EECB18F.9030305@symas.com> <4EED7D4C.8030806@bleeter.id.au> <4F4C0B59.7020103@symas.com> <026501ccfce8$e50739d0$af15ad70$@cs.uwaterloo.ca> <4F5890B8.7060101@symas.com> Message-ID: <029d01ccfd6c$56e70de0$04b529a0$@cs.uwaterloo.ca> > -----Original Message----- > From: Howard Chu [mailto:hyc at symas.com] > Sent: March-08-12 5:58 AM > To: Rob Smits > Cc: otr-dev at lists.cypherpunks.ca > Subject: Re: [OTR-dev] pidgin-otr rewrite > > > OK, I'll doublecheck that. If you have a stacktrace handy that would give me a > head start. I will send this to you separately. > > Did you patch pidgin with this? http://developer.pidgin.im/ticket/14843 That > patch specifically was to address this problem. My mistake, I missed that patch. Good call. > > 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. At this point I think a fork is the way to go. Usability does suffer a bit when you're stuck behind a couple levels of menus. But let me reiterate that it is absolutely awesome that purple-otr exists. Regards, Rob From paul at cypherpunks.ca Thu Mar 8 19:38:01 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 8 Mar 2012 19:38:01 -0500 (EST) Subject: [OTR-dev] pidgin-otr rewrite In-Reply-To: <029d01ccfd6c$56e70de0$04b529a0$@cs.uwaterloo.ca> References: <4EECB18F.9030305@symas.com> <4EED7D4C.8030806@bleeter.id.au> <4F4C0B59.7020103@symas.com> <026501ccfce8$e50739d0$af15ad70$@cs.uwaterloo.ca> <4F5890B8.7060101@symas.com> <029d01ccfd6c$56e70de0$04b529a0$@cs.uwaterloo.ca> Message-ID: On Thu, 8 Mar 2012, Rob Smits wrote: >> 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. > > At this point I think a fork is the way to go. Usability does suffer a bit > when you're stuck behind a couple levels of menus. But let me reiterate that > it is absolutely awesome that purple-otr exists. I would really prefer one plugin for pidgin, not two. It would be nice if the gtk stuff can be layered on top of the purple-otr ? Paul From hyc at symas.com Fri Mar 9 00:19:55 2012 From: hyc at symas.com (Howard Chu) Date: Thu, 08 Mar 2012 21:19:55 -0800 Subject: [OTR-dev] pidgin-otr rewrite In-Reply-To: References: <4EECB18F.9030305@symas.com> <4EED7D4C.8030806@bleeter.id.au> <4F4C0B59.7020103@symas.com> <026501ccfce8$e50739d0$af15ad70$@cs.uwaterloo.ca> <4F5890B8.7060101@symas.com> <029d01ccfd6c$56e70de0$04b529a0$@cs.uwaterloo.ca> Message-ID: <4F5992FB.5020801@symas.com> Paul Wouters wrote: > On Thu, 8 Mar 2012, Rob Smits wrote: > >>> 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. >> >> At this point I think a fork is the way to go. Usability does suffer a bit >> when you're stuck behind a couple levels of menus. But let me reiterate that >> it is absolutely awesome that purple-otr exists. > > I would really prefer one plugin for pidgin, not two. It would be nice > if the gtk stuff can be layered on top of the purple-otr ? I think that would be ideal. At the moment it seems to me this would require some dlopen/dlsym tricks to discover what environment the plugin is in. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc at symas.com Sat Mar 10 03:33:04 2012 From: hyc at symas.com (Howard Chu) Date: Sat, 10 Mar 2012 00:33:04 -0800 Subject: [OTR-dev] pidgin-otr rewrite In-Reply-To: <029d01ccfd6c$56e70de0$04b529a0$@cs.uwaterloo.ca> References: <4EECB18F.9030305@symas.com> <4EED7D4C.8030806@bleeter.id.au> <4F4C0B59.7020103@symas.com> <026501ccfce8$e50739d0$af15ad70$@cs.uwaterloo.ca> <4F5890B8.7060101@symas.com> <029d01ccfd6c$56e70de0$04b529a0$@cs.uwaterloo.ca> Message-ID: <4F5B11C0.2030207@symas.com> Rob Smits wrote: >> -----Original Message----- >> From: Howard Chu [mailto:hyc at symas.com] >> Sent: March-08-12 5:58 AM >> To: Rob Smits >> Cc: otr-dev at lists.cypherpunks.ca >> Subject: Re: [OTR-dev] pidgin-otr rewrite >> >> >> OK, I'll doublecheck that. If you have a stacktrace handy that would give > me a >> head start. > > I will send this to you separately. Thanks, fixed. >> Did you patch pidgin with this? http://developer.pidgin.im/ticket/14843 > That >> patch specifically was to address this problem. > > My mistake, I missed that patch. Good call. I've added it to the list on the gitorious page too, should've been there from the start. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/