[guardian-dev] OTR4j and OTRv3

Dev Random c1.devrandom at niftybox.net
Fri Jan 11 00:00:49 EST 2013

Hash: SHA1

On 13-01-10 03:59 AM, Abel Luck wrote:
> Dev Random:
>> On 13-01-09 03:33 PM, Abel Luck wrote:
>>> Hey guys,
>>> What's the status of the OTRv3 implementation in OTR4j?
>>> The two main improvements are two improvements we totally need!
>>> 1. When logged in from multiple spots (e.g., laptop and gibberbot), they
>>> no longer fight for control of the OTR session
>> We need to implement this. It allows multiple OTR connections to each
>> of the peer's presences. It has an impact on UI. We should either:
>> * Add a UI element choosing the remote presence to talk to, or:
>> * Send outgoing messages to all presences
>> I personally think the first choice will work out better, especially in
>> a mobile environment. I'm estimating 20-40 hours of work.
> Ella ^ hear that?

Uh oh, I said that backwards.  I think it's better to send messages to
all presences - the second bullet above.

Also, the estimate is of the Gibberbot work, not of otr4j work.  I'm not
sure about the otr4j part - would have to look more deeply into how
sessions are handled.

>> I have updated: https://dev.guardianproject.info/issues/331
>>> 2. TLV type 8 - arbitrary encrypted data! (for file sharing, encrypted
>>> voice, etc)
>> This is actually pretty easy to implement in otr4j. The more
>> interesting part is implementing apps on top of it. I have high hopes
>> for something like:
>> https://dev.guardianproject.info/projects/gibberbot/wiki/Sharing
> Do you have an estimate for how long to implement TLV type 8 support in
> OTR4j?

I estimate 10-15 hours.  It requires computing the additional key, and
adding new sending/receiving methods.  I think it will be easier than
the multiple-presence work.
>>> Eleanor mentioned that OpenITP's next funding round is coming up soon
>>> and this would be a great candidate for a feature bounty.
>>> Any chance the OTR4j team would be interested in this?
>> I think the heavy lifting is more on the Gibberbot side, but having
>> someone design a clean API extension to otr4j will help.
> Hm, I didn't expect this. I figured there would be lots of work
> required on the OTR4j side before GB got around to making use of the new
> version.

The otr4j code is relatively clean, and these changes don't seem to
require any major restructuring

> ~abel

- --

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/


More information about the Guardian-dev mailing list