My contribution to XKCD’s #949
joachim-breitner.de
joachim-breitner.de
The usage proposed here is a "no-strings" attached approach. Ideally you want something you can trust, hence free software, and that does not store anything.
The way UbuntuOne (and maybe other providers) just give you a link anybody can use is much better imho.
2) New incognito window
3) Paste, enter
4) Download, no sign-up required
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.
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).
followed by
> python -m SimpleHTTPServer
is a bit of a contradiction.
Dropbox has some pretty serious limitations for transferring files; you're limited on file size, you have to upload to their servers, you're subject to their definition of objectionable content, and sharing a particular file too much (for their definition of too much) will cause them to take down the file.
>Dropbox has some pretty serious limitations for transferring files; you're limited on file size, you have to upload to their servers, you're subject to their definition of objectionable content, and sharing a particular file too much (for their definition of too much) will cause them to take down the file.
Link to this being a real problem for someone?
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"
The disadvantages are that I need to create a torrent file with my ip in announce field for each file I want to share and that the recipient must have torrent software (all of my friends incidentally do).
Perhaps I could simplify the torrent creation using the correct announce field with a nifty right click - 'Send to' script. edit: Looks like it would be possible with a combination of https://github.com/bittorrent/btc , http://www.robertnitsch.de/projects/py3createtorrent and a batch file.
The advantages are built-in checksumming, no intermediate upload server, interoperability with various torrent software, ability to stop and resume the transfer at any time and very good transfer rates (for some reason I've had terrible performance with those browser-to-browser services like e.g. sharefest)
You have to set some restrictions on who can share what with how many people and how often. Even torrent trackers that do not store any files other than the tracker become targets. I really would love it if there was a way to type "scp /home/freehunter/your-granddaughter-laughing.mpg //grandma/home/grandma/videos" with UPnP to get around grandma's dial-up NAT. Unfortunately, the closest we have is Dropbox (requires an account) or BitTorrent (requires dodging law enforcement and porn popups).
I also recall that KDE had a panel applet that pretty much did the same thing on the 3.x days (not sure it's been ported to 4.x)
So for big files with multiple downloaders, it can be sometimes not as good as you want it to be.
With things like google docs, I've found that file sharing has become a lot less necessary. We're sort of moving into a very file-less space, and I'm kinda fine with it.
See https://github.com/brechin/FileTeaSend Tested with Python 2.6. Only external requirement is requests.
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.
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.
Plus even if you do borrow someone else's box, can you be sure that they'd even be grateful that you're using up their bandwidth?
Ssh is a dangerous protocol to leave open to the WAN, so setting up an ssh server properly, while not a time consuming job, will still take longer and more effort than simply deleting a few files afterwards.
- 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
STUN will get though the NAT most of the times. With the latest browsers, Firefox to Chromium is a bit dodgy, but there are workarounds. But Chromium to Chromium is perfectly fine.
(Serious question.)
Supports up to 50mb files for now.