[guardian-dev] first prototype of OTRDATA in pure otr4j
Nathan of Guardian
nathan at guardianproject.info
Sat Mar 21 10:19:47 EDT 2015
On Fri, Mar 20, 2015, at 10:12 PM, Hans-Christoph Steiner wrote:
> I finally got the OTRDATA transfer working in pure otr4j. I've been
> working
> on ripping out all that code from ChatSecure, where it is working well,
> and
> generalizing it into an API that is as easy as possible for other apps to
> include.
>
> You can see the work I have so far in my git fork:
> https://github.com/eighthave/otr4j
Fantastic progress... just to point out for others, this is all part of
our unified OTR4J update effort (https://github.com/otr4j/otr4j), and
the first time we've had OTRDATA support outside of the forked+dated
version within the ChatSecure code.
Additionally, OTRDATA support is currently available in a dev branch of
the iOS OTRKIT code as well:
https://github.com/chatsecure/otrkit/tree/otrdata thanks to Chris
Ballinger.
> Right now, the API just works directly with java.io.File instances, but I
> hope
> to also extend it to allow the use of InputStreams and OutputStreams
This is a requirement obviously for use of this with IOCipher, so it is
more than a hope - it is a need.
, and
> having the data actually stream to the other side as it is being written.
> This will be much better for interactive data, like push-to-talk voice
> chat,
> since the data will start being pushed to the other side as soon as it
> comes in.
That's a great improvement I agree. This would also work with the stream
oriented video capture work I have been doing, so we can send short,
small videos back and forth quickly.
> In the current implementation, sending a hash of the whole file in the
> OFFER
> request is required. That means that before the recipient can start
> playing
> the file, these steps must happen:
>
> 0. record an entire audio message to a file
> 1. read the entire file and calculate a checksum
> 2. send an OFFER request
> 3. respond to GET requests from recipient
> 4. recipient must wait until entire file is received
> 5. read the entire file and calculate a checksum
> 6. now file is ready to play
>
>
> I propose an optional streaming mode like this:
>
> 0. start recording an audio message
> 1. send an OFFER request while writing the file to disk
> 2. respond to GET requests from recipient
> 3. recipient can start playing the chunks immediately
> 4. recipient keeps playing until End-Of-File is received
Is there a possibility to send a HASH at the end to make sure all bits
have been received properly?
>
> .hc
>
> --
> PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81
> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81
> _______________________________________________
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email: guardian-dev-unsubscribe at lists.mayfirst.org
--
Nathan of Guardian
nathan at guardianproject.info
More information about the guardian-dev
mailing list