Nathan of Guardian: > > > 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.
I think it'll be better to support IOCipher this way, but we can also use the approach that is used in ChatSecure right now: a subclass of "Transfer" that replaces java.io.File with IOCipher's info.guardianproject.iocipher.File. >> 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. Streaming would help video a lot more than audio, since the file sizes are a lot larger, so things like calculating the SHA1 checksum will take a lot longer. >> 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? Sure, that's easy. devrandom and I were talking about this. It should be possible to send the checksum hash in any response related to that transfer. So for example, the checksum could be running in parallel to the streaming, then when complete, the checksum would be included in the response to a GET request at any point in the middle of the streaming. This could be tricky to deal with when streaming video, since the phone would already be taxed doing the video and the streaming. It might end up that the checksum isn't complete by the time the final GET request comes in. Then to keep the protocol consistent, it would have to hold the final GET response until the checksum was complete. That might then cause a hiccup in the playback at the end of the file. .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: [email protected]
