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: [email protected] -- Nathan of Guardian [email protected] _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
