[OTR-dev] OTR Encrypted File Transfer, Spec Draft

Dev Random c1.otr-dev at niftybox.net
Mon Jun 10 19:41:38 EDT 2013


On 06/10/2013 04:15 PM, Hans-Christoph Steiner wrote:
> 
> On 06/10/2013 06:45 PM, Paul Wouters wrote:
>> On Wed, 5 Jun 2013, Hans-Christoph Steiner wrote:
>>
>>> Rate limiting will affect both XMPP in-band and OTR in-band the same.  Only an
>>> out-of-band file transfer would get around that.  So we'll need to find a way
>>> to deal with that gracefully regardless of whether its in-band XMPP or OTR.
>>
>> Why not provide a URI that defines the transport mechanism? If we are
>> now already discussing the limits of one kind of file transfer
>> mechanism, we're bound to need different ones over time.
>>
>> Providing a URI could also mean I can encrypt it and put it up on an ftp
>> server.
>>
>> Paul
> 
> I like that idea, so you'd have something like:
> 
> XMPP-side-channel://
> XMPP-in-band://
> otr-in-band://
> https://
> ftp://
> sftp://

This seems to fit with the idea to have HTTP-like headers and verbs.  So
you could do something like:

OFFER otr-in-band:/filename1.ext

and if peer approves, their user-agent does:

GET otr-in-band:/filename1.ext

> 
> etc.
> 
> .hc
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
> 




More information about the OTR-dev mailing list