ShareDrop – P2P File Transfer Using WebRTC
sharedrop.io
sharedrop.io
FAQ: https://github.com/RobinLinus/snapdrop#frequently-asked-ques...
- 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...)
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.
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.
Also check Syncthing. They have a very nice interface that skips the cloud...
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.
Of course of you're using the Apple ecosystem, there's AirDrop...
[1] https://support.microsoft.com/en-us/help/4091344/windows-10-...
One fear was to become a peer in a (copyright infringing) p2p-network, unknowingly just by visiting a random website.
WebRTC can be very useful but I think browsers should ask for special permissions like they do for camera access etc.
[0] https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-l...
But if this is interesting, checkout https://instant.io which uses the webtorrent protocol.
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
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].
[1] https://github.com/chr15m/bugout
[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 fully agree with you.
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.
I need to read more carefully.
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:
https://github.com/svarunan/serverless-webrtc
Once you have a connection to someone in the network you're in the domain for traditional P2P solutions and protocols.
EDIT: Just realized melvinrost explained this better below (:
(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™.)
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/sWhen 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.
Well, the search continues...
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.
A quick search on HN shows that this was first posted 6 years ago as a "Show HN" - looks like it's come a long way since then: https://news.ycombinator.com/item?id=7468328
DOMException: Failed to set the 'binaryType' property on 'RTCDataChannel': Blob support not implemented yet at https://www.sharedrop.io/assets/vendor-6deb0f828efb7a002b3c4... at https://www.sharedrop.io/assets/vendor-6deb0f828efb7a002b3c4... at https://www.sharedrop.io/assets/vendor-6deb0f828efb7a002b3c4...
Crypto is done on the client. The key is in the share URL and is not sent to the server.
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
Can you share the technical details behind this? Also, what is your business model? Freemium?
Have we killed it?