cough onewaybits.com cough (shameless self promotion)
Supports up to 50mb files for now.
My contribution to XKCD’s #949
41–50 of 56 posts
Re: My contribution to XKCD’s #949
#42You can always uses a p2p data transfer with WebRTC. All you need is a browser.
It is way more complicated than that. WebRTC is all great and shiny but there is strong obstacles to build correct data transfer applications on top of that:
- You still need a server to do the "signaling" part
- NAT are everywhere and will fail your p2p connections sometimes (14% of WebRTC calls according to Google, back in may) [1]
- Ultimately there is a problem with JavaScript API that does not allow you to download big files seamlessly
The signaling part can be solved in many ways but the server approach is the easiest and probably the most efficient/reliable one. For more informations I recommend checking an article on the infrastructure needed for WebRTC applications [2]
The NAT problem is solved by ICE via STUN and TURN [3]. TURN is the ultimate fallback, it is a media relay. TURN servers are bandwidth expensive and most of them require credentials in a way that does not fit WebRTC properly.
Finally, there is the browsers problem. None of them provide a proper and standard way to give you the ability to download a stream of data coming from JavaScript (although after checking the issue, sharefest may have solved this problem, but I don't know if it works properly with firefox). There the File API in Chrome but it is not supported in Firefox. There is the blob URI but you need the whole file to create this object. This mean that your application will slow down your browser in the case of a big file sharing [4]. Ideally I wanted to see the stream API be implemented but it seems it's not going to happen, so we need something else [5].
In conclusion, no, it's not as easy as you think it is. To have a proper file sharing application you will need to address ALL of these problems. Moreover, it's good to note that these problem are not specific to WebRTC applications. Indeed, most of these are problems we have with the Internet in general. WebRTC is just an API on top of existing solutions.
I hope this answer was not too negative but informative enough :)
[1] http://webrtcstats.com/first-webrtc-statistics/
[2] http://www.html5rocks.com/en/tutorials/webrtc/infrastructure...
[3] https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...
[4] https://github.com/Peer5/ShareFest/issues/8
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=891286
EDIT: formating/typos
Re: My contribution to XKCD’s #949
#43WeTransfer (wetransfer.com) is pretty popular in the Netherlands. It's easy to use, only requires an e-mailadress and allows you to send files up to 2GB and as an added bonus it's quite pretty. I really love it's simplicity.
WeTransfer solves this problem, without needing an user account. I don't know why people wouldn't use it.
Re: My contribution to XKCD’s #949
#44So he's built a file sharing tool which requires an SSH server to work? So why not just use sshfs, scp or rsync? I don't mean to stamp on someone's creativity, but SSH already has a whole bunch of tools for transferring files - all of which already work pretty well.
Because with file-share, the file is never stored on the ssh-server; it is transferred the instant the other sides starts the download. The SSH-Server is required to share the file at a publicly available address (which my own computer is likely not). So no need to clean up files after the download, for example, or even to have any free disk space.
If you need an SSH server to begin with, then there's still some setting up you need to do before hand. The pain of having to delete a few files afterwards is really nothing compared to renting a Linux box, setting up SSH accounts with fail2ban and/or SSH keys; and so on.
So file-share doesn't even work as a pain free solution like you suggest it does.
As I said before, I don't like to stamp on another's creativity. I'm just saying that there are better tools for doing this which already come pre-installed with most Linux distros, UNIX's and OS X.
Re: My contribution to XKCD’s #949
#45The problem isn't 'sending a file', it's 'peer to peer communication', which is hard without an intermediary and/or shennanigans due to ubiquitous NAT. I image in the everyone-has-an-IP universe of ip6, this will no longer be an issue.
ipv6 will still have this issue, because _no fucking way_ will i put a directly-accessible-from-anywhere computer on a network. the "how do i serve a directory" problem is _so_ solved: `python -m SimpleHTTPServer` or: dropbox (it's not hard to install, as much as xkcd whinges about it) google drive email This is a solved problem.
> This is a solved problem.
There is strong technical obstacles but yes the problem is more or less solved in different ways.
The point of Randall Munroe here is to emphasis the gap between the fact the Internet made possible a lot of incredible things but sharing a simple file is still a hassle. And IT IS, creating an account is not what you can call a no-hassle process (I would probably say, do not forget about Term Of Services, but I understand no one read them nowadays).
Re: My contribution to XKCD’s #949
#46Wow, thanks for pointing me to https://filetea.me
Re: My contribution to XKCD’s #949
#47Munroe did not mention Skype. Tons of people have accounts there, and it transmits files like ICQ did back in the day.
Re: My contribution to XKCD’s #949
#48You can always uses a p2p data transfer with WebRTC. All you need is a browser.
OK, I've got a browser window open right here. Now what? (Serious question.)
Re: My contribution to XKCD’s #949
#49I've got a CLI that lets you upload a file through FileTea. I'll clean up the source and post it soon.
See https://github.com/brechin/FileTeaSend Tested with Python 2.6. Only external requirement is requests.
Re: My contribution to XKCD’s #949
#50The problem isn't 'sending a file', it's 'peer to peer communication', which is hard without an intermediary and/or shennanigans due to ubiquitous NAT. I image in the everyone-has-an-IP universe of ip6, this will no longer be an issue.
ipv6 will still have this issue, because _no fucking way_ will i put a directly-accessible-from-anywhere computer on a network. the "how do i serve a directory" problem is _so_ solved: `python -m SimpleHTTPServer` or: dropbox (it's not hard to install, as much as xkcd whinges about it) google drive email This is a solved problem.
I was being a bit idealistic, but in theory that's the story.
Yeah, xkcd handwaved away a couple of other solutions too: use a chat client to transfer a file? "no-one uses this obsolete one!"; use a file upload site? "I'm scared of porn popups and they don't work properly anyway"