[guardian-dev] libotr for gibberbot?

Hans-Christoph Steiner hans at at.or.at
Fri Nov 11 21:25:51 EST 2011


On Nov 11, 2011, at 9:14 PM, Miron wrote:

> On 11-11-11 01:58 PM, Hans-Christoph Steiner wrote:
>> On Nov 11, 2011, at 4:48 PM, Jacob Appelbaum wrote:
>> 
>>> On 11/11/2011 12:36 PM, Hans-Christoph Steiner wrote:
>>>> Its looking more and more like libotr is a good central point for us to be working on for handling improvements related to OTR.  For example, if it turns out to be a solid idea, I will be implementing OTR keys being integrated into OpenPGP keys.  That would happen in libotr for Pidgin and Adium.  I could either spend the time to reimplement that in Java, or make JNI wrappers for libotr and use gpgme-for-java.  The second approach would then also give us a fully functional OpenPGP stack versus the limited one in APG.  It would also give us the Socialist Millionaires Protocol, implemented in libotr 3.2.
>>>> 
>>>> Anyone have any counterpoints to switching Gibberbot to libotr?
>>>> 
>>> Memory corruption bugs! Unless you mean the libotr in Java?
>>> 
>>> Please consider a full re-implementation of OTR in a type safe language
>>> rather than simply switching to native code or code written by the OTR
>>> team; we should try to avoid a privacy software monoculture.
>>> 
>>> Check this out:
>>> https://github.com/afflux/pure-python-otr
>>> 
>>> All the best,
>>> Jake
>> I wish we could use python, but that's not an option for this project.  A full Java implementation of OTR would also be good to have, but it seems that I would then spend my project time on that, and not on improving the usefulness of OTR, which is the scope of this project (PSST: https://guardianproject.info/wiki/PSST).  If someone wanted to implement the Socialist Millionaires Protocol in otr4j, I'd gladly use it.  
> 
> I can take this on.

Excellent!  I'm sure the jitsi devs will be happy too, they are the authors of otr4j.

.hc


----------------------------------------------------------------------------

Programs should be written for people to read, and only incidentally for machines to execute.
 - from Structure and Interpretation of Computer Programs



More information about the Guardian-dev mailing list