Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File transfer #18

Open
olabini opened this Issue Sep 16, 2015 · 12 comments

Comments

5 participants
@olabini
Copy link
Contributor

olabini commented Sep 16, 2015

The feature of file transfer is quite complicated, and we will implement it using several different issues, for implementing the different parts of XEPs we need - and also define the potential new standards we would need to support good encrypted support.
The issues tracking this work are:

  • #377 - Out of band transfers
  • #378 - Stream Initiation
  • #379 - File transfer profile for stream initiation
  • #380 - SOCKS5 Bytestreams
  • #381 - In-band bytestreams
  • #382 - Support transferring folders
  • #383 - Support encrypted transfers
  • #384 - Design the experience of file transfer

We will for the moment NOT implement Jingle support - it's a large, complicated beast, and since we are not planning on supporting audio or video, Jingle feels a bit like overkill.

For the encrypted data, we will in general derive the encryption key from the OTR extra symmetric key. We will likely not use the "usage" field of the extra symmetric key for anything else than the most basic tying things together.

@olabini olabini added the feature label Sep 16, 2015

@olabini olabini modified the milestone: Later Oct 7, 2015

@olabini olabini removed this from the Later milestone Jan 29, 2016

@olabini olabini modified the milestone: Years Mar 16, 2016

@olabini olabini removed the within-years label Mar 16, 2016

@olabini

This comment has been minimized.

Copy link
Contributor Author

olabini commented Sep 13, 2016

We need to investigate what this means in terms of XMPP support. We also need to interface with the symmetric key functionality in OTR3. Finally, we need a nice user flow for how this will happen, both on the receiver and the sender side. I'll tag @SweetVirginia for this things.

@tcz001

This comment has been minimized.

Copy link
Contributor

tcz001 commented Sep 14, 2016

I did some investigation before about this issue, xmpp has some extension spec, in-band transfer will use up most of the bandwidth between client and server, the other way is to setup a p2p channel for this, which may not be able to apply in some NAT environment.

@xSmurf

This comment has been minimized.

Copy link
Contributor

xSmurf commented Sep 14, 2016

Almost every XMPP server also provides a SOCKS proxy for this as part of one of the XEPs. And usually available through service discovery. That's probably the way to go.

@olabini

This comment has been minimized.

Copy link
Contributor Author

olabini commented Sep 14, 2016

The big problem is not the regular file transfer, but how to make it in a backwards compatible way while using OTR - it doesn't seem like there is much support for this, so we might have to figure out a "mini"-standard for it.

@xSmurf

This comment has been minimized.

Copy link
Contributor

xSmurf commented Sep 14, 2016

Right, but where I was getting at is that you can use the SOCKS Proxy for negotiating a connection between the two users, after that the proxy doesn't care what the stream of bytes looks like.

@olabini olabini self-assigned this Oct 3, 2016

@olabini

This comment has been minimized.

Copy link
Contributor Author

olabini commented Oct 12, 2016

Me and @SweetVirginia spend some time yesterday talking about this issue. There are a few different things we would want it to do:

  • Make it possible to send folders as well as files
  • Avoid lots of popup-windows. Give the information as much as possible in the chat window itself
  • Fall back to un-encrypted transfer - but only for the cases where the other party doesn't support encrypted transfer

Additionally, it might be useful if we have Tor support if we can use Tor hidden services to send stuff.

@olabini olabini changed the title Have actually encrypted file transfer File transfer Oct 12, 2016

@olabini

This comment has been minimized.

Copy link
Contributor Author

olabini commented Oct 12, 2016

We will need a large number of things implemented to support this, so I'll create smaller issues to track the different pieces of the work.

@Flowdalic

This comment has been minimized.

Copy link

Flowdalic commented Oct 31, 2016

I suggest putting the focus on Jingle based file transfer (XEP-0234, -0260, -2610) and not on the legacy ones, i.e., SI file transfer. It sure is nice to support SI too, but Jingle is the way to go. Also Jingle has at least some basic primitives for encrypted sessions. See the element in XEP-0166 and draft-meyer-xmpp-e2e-encryption-00. A formal published specification (a XEP) of encrypted jingle-based file transfers is missing, but something the XMPP community looks for. Help sure would be welcomed.

@olabini

This comment has been minimized.

Copy link
Contributor Author

olabini commented Oct 31, 2016

Would you mind mentioning why you are arguing for Jingle? There seems to be a huge amount of complexity in Jingle, for features that CoyIM will never support - which means adding all that complexity is really risky.

The encrypted sessions doesn't really match the behavior you need for real encrypted file transfer either, which is why I didn't feel they were relevant for us.

@Flowdalic

This comment has been minimized.

Copy link

Flowdalic commented Oct 31, 2016

Would you mind mentioning why you are arguing for Jingle?

I'd expect that the legacy file transfer XEPs become deprecated at some point in the future. You only want the SI file transfer XEPs for backward compatibility with some older or not up-to-date libraries. Unfortunately, with Smack only supporting the SI file transfers, there is an existing widespread library which falls into this category.

There seems to be a huge amount of complexity in Jingle, for features that CoyIM will never support

You don't need to implement all of Jingle for jingle-based file transfers. I'd expect the effort to implement them similar to implementing the legacy SI file transfer XEPs

The encrypted sessions doesn't really match the behavior you need for real encrypted file transfer either, which is why I didn't feel they were relevant for us.

I'm not sure if I got that. But as I said: A XEP for encrypted jingle-based file transfers is missing. I'm sure one could be developed using the existing Jingle primitives.

@olabini

This comment has been minimized.

Copy link
Contributor Author

olabini commented Oct 31, 2016

No, the difference in implementation is pretty significant. I would expect there to be 2-3x as much code for something that is compatible with the Jingle XEPs.

@Flowdalic

This comment has been minimized.

Copy link

Flowdalic commented Oct 31, 2016

Well that's not my experience. But your mileage may vary. Anyway I just wanted to point out that the default file transfer mechanisms of XMPP are going to change from the legacy ones to jingle-based ones. I'm not sure if right now is the time to only focus on the jingle ones, but that time will eventually come. And if there ever will be an open standard for encrypted file transfers, then it will be based on Jingle.

@juniorz juniorz modified the milestones: Years, 0.4.0 Release Nov 7, 2017

@juniorz juniorz added this to to do in Next release Nov 10, 2017

@juniorz juniorz removed this from to do in Next release Nov 10, 2017

@juniorz juniorz added this to to do in Next release Nov 10, 2017

@juniorz juniorz moved this from to do to in progress in Next release Nov 10, 2017

@olabini olabini removed this from the 0.4.0 Release milestone Feb 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.