On 06/10/2013 07:41 PM, Dev Random wrote: > 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
Yes! Then there could also be a failure mode to renegotiate if the transfer does not complete for any reason. So it would try OTR-in-band first, if that fails because of rate limiting, for example, then it would bump to XMPP-side-channel with TLV8. Maybe there could be a UDP mode via STUN servers as a firewall failsafe if you really need to get the data thru, privacy leak or not. That UDP mode could still be encrypted using TLV8. Perhaps these would also be possibilities: dropbox:// google-drive:// mega:// etc. .hc _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
