This looks nice. However, when it does the automatic fallback to WebSockets, will the file be sent unencrypted? The FAQ does not mention encryption, it only says that data is not stored on the server...
There's this situation that comes up again and again: It's 2019 and I want to send a (potentially large) file from my phone to my computer, or from my computer to my wife's computer. How do I do it?
- USB connection? I don't want to dig out my cable and climb under the desk to plugin the USB cable.
- Samba share? Forget it.
- FTP server app? Works, but usually quite slow and painful.
- Start a HTTP server to serve the directory? That works, but seriously?
- Sending via E-Mail or Dropbox? Oh FFS, both devices are connected to the same WiFi access point, how can it be that uploading the file to a cloud hosted across the world and downloading it again from my other device is the simplest approach?
So far, Sharedrop is the simplest solution I know that works across any device that has a modern browser and that allows me to send the file directly from one computer to the other, without the need for logins or accounts or external software or arcane command-line incantations.
(The WebRTC Datachannel stack is horrible and mostly neglected by browser vendors, especially Google, but that's another story...)
Windows now has "Nearby Sharing"[1], which should at least solve this problem between Windows computers. I think the idea was that it would eventually also be available on Android, but I haven't yet seen an implementation of it.
Of course of you're using the Apple ecosystem, there's AirDrop...
The main issue with file transfer is that it's a context where security and usability are nearly mutually exclusive features. To me we still have to address point #1 which is how to get data in a transparent way from A to B (and C, D, etc.), whether none, one or more of them are on a PAN, LAN, WAN etc. Once the specifications are set, one can think of security and where to implement it in a way that doesn't affect usability. If I had to share a file on all my machines, I'd expect the software to let me drop/copy it into a directory knowing that anything put there will replicate on all my machines no matter where they are, that is, managing fixed/dynamic IPs, VPNs, machines momentarily off, etc. Same for less or more restricted transfers such ass for example passwords files or public documents. Everything should be transparent so that if I set up a similar system on granma PC I know that once she puts something into a public folder it's being shared with everyone (with her being warned about it beforehand) while a family only folder would have the content automatically shared (sent, replicated, backed up, etc) only to family members. To me it is very important that the software shows an abstraction of how would we operate in real life: public documents here and private others there, which would be very easy to understand: passwords, keys etc should be used only once to set up the system, unless they're revoked.
But before all that, we must solve the #1 issue (see above). IPv6 should help to solve that, but it seems to me that implementing it as it should be would impact too many businesses currently profiting from simply being the cable that connects A, B, C, D etc.
I have found btsync (now Resilio Sync) the best available p2p solution, albeit requiring sync app installation, still you need some app anyway, being it the browser, file manager etc..
It uses local network when available and of course internet when not. It also does iOS.. if only more apps were supporting FileProvider functionalities, so you don't have to import-duplicate all the synced data first.
It requires installing proprietary software on all devices though, while your browser already brings along an open source and mostly standardized P2P stack.
There are open source alternatives like syncthing, which is still not as user friendly.
Also single file sharing seems interesting, but this is not what you usually do on daily basis... You just want to drop some file to shared folder most of the time, or to have a ton of different files synced automatically.
I've tried syncthing as well as btsync (now called resilio); it's not just less user-friendly. It tends to be _much_ slower and eat tons of CPU due to a different algorithm. Resilio has a free tier that works fine for me, and I don't have an inherent issue with a proprietary program that works well. It's a very convenient solution, I haven't had issues, and highly recommend it.
I did this all the time between my computer and my brother's computer as a kid. They were on the same network (dad had the whole house wired for ethernet when they gut rehabbed it) and we just used Windows file explorer to drag and drop files from one computer to the other.
You really shouldn't need any server-side at all for something like this these days (thinking about firebase).
Webtorrent should be mature enough.
We did something similar back 5 years ago for our BSc thesis project, using a DHT and Namecoin for distributed key exchange. Abandoned and obsolete, but in case anyone's interested: https://github.com/rymdjs
No you don't, sort of don't. When you look at the Bugout [1] library, you see that they're using the infrastructure of WebTorrent to fix that.
I emailed the author and he said he's working on a form of infrastructure in which the infrastructure takes care of this problem.
So yea, you don't need a signaling server then. I'm pretty sure the extended version of this idea also includes STUN servers. And I think you'd always need to pay for TURN servers as the NAT is then simply disabling P2P all-together [2].
[2] Context for people who are like what are all these terms?
In WebRTC when you have 2 computers behind different corporate networks trying to connect they need to go through a router. A router performs Network Address Translation (NAT), the internal IP (usually 192.168.178.xxx, definitely not always) needs to become the public IP. The problem is that when both networks are too complicated in its structure, then WebRTC cannot work in undoing this layer of translation.
In order to circumvent this, they tunnel your data through a server that has a public facing IP. They call this a Traversal Using Relays around NAT (TURN) server. IMO, you could just see it as an intermediary that shoves data from A to B and vice versa. However, IMO this defeats the point of P2P as you need a 3rd-party helping you to get the data to the other side.
Note: other relevant ideas are signaling servers (i.e. knowing each other's reachable address through an intermediary server)
and STUN servers (a server that tells you your own public facing IP address).
I would argue that this is still "a way to establish a connection between the two browsers" and therefore does not contradict my comment, but this does seem very interesting and I will look into it further.
Man, my thinking got lazy these days. I read an argument a while back on HN saying that WebRTC is not purely P2P, I was basically insta-responding to that.
Yes, and it's tricky to make a smooth UX out of it in a web browser setting but the technology is absolutely there.
IIRC we managed to make it server-less (in the true sense) apart from the need of a Namecoin gateway.
Typically you would use a signalling server coupled with STUN/TURN to discover peers and establish WebRTC connections/routes but it's not required. You could take a look at Rymd above, IIRC the principles are described in the paper. Here's also a minimal PoC that I found by a quick duck:
Shameless plug: As an alternative to solutions like WebTorrent, if you do need to rely on a signaling server but don't want to send your signaling data (ICE candidates containing IP addresses in this case) unencrypted over a cloud service like Firebase, it's possible to use an end-to-end encrypted protocol for this use case: https://saltyrtc.org/ The good thing about this protocol is that you don't need to trust the server.
(Of course it would be nice if we could just send an UDP broadcast or announce the device via mDNS/Avahi, but browsers do not allow direct network socket access, due to reasons™.)
PC and Android on same hotel wifi didnt find each other. Understandable, scanning QR code paired devices nicely.
Did speedtest.net
on PC: 14/10 Mbit down/up with 8ms ping.
on AN: 35/ 7 Mbit down/up with 13ms ping.
Transfering AN -> PC at 3 Mbit/s
When refreshed site on PC to try another direction my PC is stuck on "loading". After restarting browser it went trough, but now my Android is stucked at loading. After completely closing firefox in Android I was finally able to pair again to do speedcheck in other direction:
Transfering PC -> AN at.... 20 MB file transferred, by eye, 20% and got stuck.
You're encountering basically what I've seen myself when trying to use any of these P2P services. Most of them don't work at all, and those that do seem to work too slowly to transfer a file of any reasonable size, even on the same WiFi. I have no problems with any other transfers, including torrents, which all run at full speed. But WebRTC stuff just never works for whatever reason.
It's really great that people are still using it, after almost 6 years since the release! It was first announced here on HN: https://news.ycombinator.com/item?id=7468328. Fun fact: on the same day Facebook announced Oculus acquisition ;)
Also, sorry that the service was down for some of you yesterday - it's using a free Firebase account that has a limit of 100 connections - usually it's enough.
I've been using file.pizza for the exact same thing. Can't evaluate sharedrop right now because it is dead, but I find that the aesthetic of file.pizza makes it very approachable for a lot of people, though some people might consider it untrustworthy because of it.
I've been using this for months now, it's great to quickly transfer files via WiFi on the same network. Right now, I guess it received the HN hug of death.
I've switched to this for sharing files. It's not p2p, which has some disadvantages but is very convenient because you don't need to keep a tab open, is encrypted, and made by Mozilla.
I don’t like webrtc based solutions because the speeds are subpar.
My phone and iPad are on the same WiFi network and both have a link speed of roughly 400mbps.
Using trebleshot(a oss file sharing tool like shareit/midrop) I was able to get 30-40MBps which is pretty insane speed if you ask me.
But sharedrop didnt’t work. It failed with “could not establish direct WiFi connection with peer” error and with snapdrop that someone else suggested I could only get speeds of up to 15mbps(or roughly 2MBps).
I only use trebleshot on android and trebleshot via the web interface to transfer between iOS and android. It’s the fastest tool I have ever used and I strongly recommend it if you are looking for a tool like that.
TLDR being, webrtc based tools for p2p file sharing suck.
I love the "Air Drop" feature from apple and I'm very happy we can do this on linux now without the need to explain someone how to open a socket in the terminal ;-P
FAQ: https://github.com/RobinLinus/snapdrop#frequently-asked-ques...