Drop.lol – copy files over the network with WebRTC or TURN relays(drop.lol)
drop.lol
Drop.lol – copy files over the network with WebRTC or TURN relays
https://drop.lol/
28 comments
Thank you. TIL: twilio runs a turn service:
https://www.twilio.com/stun-turn
Via https://github.com/webtorrent/instant.io/blob/master/README....
"Copy secret/index-sample.js to secret/index.js and set the Twilio API key if you want a NAT traversal service (to help peers connect when behind a firewall)."
Are there any open source variants that combines browser p2p and a "permanent" seed server?
I'd like to self-host a solution that let you upload (preferably via webtorrent) and share a file from a browser, but then let the server cache/host the file (preferably with http seeding support) - as well as give you a shareable magic link for classic torrent clients and a http url for browser download.
As far as I can tell, most solution ion are either browser p2p only, or server to browser (download only)?
https://www.twilio.com/stun-turn
Via https://github.com/webtorrent/instant.io/blob/master/README....
"Copy secret/index-sample.js to secret/index.js and set the Twilio API key if you want a NAT traversal service (to help peers connect when behind a firewall)."
Are there any open source variants that combines browser p2p and a "permanent" seed server?
I'd like to self-host a solution that let you upload (preferably via webtorrent) and share a file from a browser, but then let the server cache/host the file (preferably with http seeding support) - as well as give you a shareable magic link for classic torrent clients and a http url for browser download.
As far as I can tell, most solution ion are either browser p2p only, or server to browser (download only)?
> I'd like to self-host a solution that let you upload... from a browser, but then let the server cache/host the file... as well as give you a shareable magic link for torrent clients... and a http url for browser download.
Not self-hosting or open-source, but: One could upload objects to S3 and generate a .torrent file to download it from a BitTorrent client or download it via HTTP. Both these features are available at no extra cost (except for the bandwidth, of course).
Unfortunately, S3 has stopped supporting .torrent downloads from newer regions (post 2016). Also, the per-torrent object size is limited to 5GiB, plus enabling public and anonymous access to the torrent-able object is required, which is understandable but might be not feasible for most use-cases.
https://docs.aws.amazon.com/AmazonS3/latest/dev/S3TorrentRet...
Not self-hosting or open-source, but: One could upload objects to S3 and generate a .torrent file to download it from a BitTorrent client or download it via HTTP. Both these features are available at no extra cost (except for the bandwidth, of course).
Unfortunately, S3 has stopped supporting .torrent downloads from newer regions (post 2016). Also, the per-torrent object size is limited to 5GiB, plus enabling public and anonymous access to the torrent-able object is required, which is understandable but might be not feasible for most use-cases.
https://docs.aws.amazon.com/AmazonS3/latest/dev/S3TorrentRet...
Cool, but none of these services seem to be operational at the moment.
(Which is somewhat strange given that they are supposed to be run mostly in the browser.)
(Which is somewhat strange given that they are supposed to be run mostly in the browser.)
I’ve had great success with Sharedrop, but it’s at https://sharedrop.io, not .net as the OP linked.
One reasons services might have shut down is running the TURN server. An added annoyance over what would otherwise just be static files.
One reasons services might have shut down is running the TURN server. An added annoyance over what would otherwise just be static files.
My bad. The mirror is at https://snapdrop.net [0].
[0] https://news.ycombinator.com/item?id=21439659
[0] https://news.ycombinator.com/item?id=21439659
Ok thanks, I'll check out Sharedrop.
Regarding the TURN server, is that something that is specific to the service? It seems to me that a more general approach would be preferable, i.e. not connected to any particular service.
Also, I'm wondering how IPFS is doing these days.
Regarding the TURN server, is that something that is specific to the service? It seems to me that a more general approach would be preferable, i.e. not connected to any particular service.
Also, I'm wondering how IPFS is doing these days.
As much as I'm a fan of these FOSS WebRTC solutions, nothing quite worked for me reliably in a room of people with a variety of devices and technical knowledge.
I use https://fileroom.io/about but it is not FOSS, it does use their own servers for storage (you have to believe they delete the files) and the project looks dead overall.
But this drop.lol thing does not allow "click to browse" and that is rather cumbersome on mobile. Also, users should be able to asign a name?
I use https://fileroom.io/about but it is not FOSS, it does use their own servers for storage (you have to believe they delete the files) and the project looks dead overall.
But this drop.lol thing does not allow "click to browse" and that is rather cumbersome on mobile. Also, users should be able to asign a name?
> But this drop.lol thing does not allow "click to browse" and that is rather cumbersome on mobile.
Which is funny, isn't using a standard <input type="file"> much more straightforward than actually accepting a drag and drop?
FWIW I've been seeing this pattern all over the place lately, where drag-and-drop is so emphasized that the click-to-browse option is hidden (or entirely missing).
Which is funny, isn't using a standard <input type="file"> much more straightforward than actually accepting a drag and drop?
FWIW I've been seeing this pattern all over the place lately, where drag-and-drop is so emphasized that the click-to-browse option is hidden (or entirely missing).
If you're on the CLI and need to quickly get a file from one machine to another, check out my https://patchbay.pub service. There are now a couple open source implementations that can handle the file sharing case.
See also: magic-wormhole [1] (written in Python)
[1] https://github.com/warner/magic-wormhole
[1] https://github.com/warner/magic-wormhole
As a Dutch person this domain name made me laugh. Nice tool though.
Why is this funny to a Dutch person in particular?!
Drop is our national licorice candy, and lol means fun (not just as the acronym).
It means drool
Was looking for this comment ;)
Doesn't work for me.
Tried Chromium (Linux) -> Chromium (Android) - fails.
Tried Firefox (windows) -> Chromium (Linux) - fails.
This works beautifully. I wonder how secure it is.
WebRTC is end-to-end encrypted, but the handshake goes over the server in cleartext. So you need to trust the server, but not the TURN relays.
I made a similar version awhile back: https://qqsend.me
It uses AES encryption to encrypt the contents of the data so that any TURN relays couldn't see the contents of what was being transferred.
The key material between sender/recipient are transferred via the hash-param of the URL, which AFAIK isn't sent to the server and is hidden.
It uses AES encryption to encrypt the contents of the data so that any TURN relays couldn't see the contents of what was being transferred.
The key material between sender/recipient are transferred via the hash-param of the URL, which AFAIK isn't sent to the server and is hidden.
The data going over TURN is always encrypted in WebRTC, so relays can never see what you send (at least in all normal implementations).
The handshake can be sent out-of-bound like you say, but if you are not at the same physical place or have some pre-trusted way to transmit them you always need to trust something.
Even if you send it over something that is previously e2e-encrypted like signal or keybase you always need to trust that channel, so unless you actually are at the same physical place to do the handshake over a non-remote channel or have setup the channel earlier I don't think there is a way to do it "truly securely". The same is true for basically all e2e-encrypted systems that don't have a way to establish an out of bounds channel of trust (like for example the web PKI structure or the debian web of trust).
If you were to use existing web PKI (every participant having their own domain) and require all participants to encrypt with their DV/OV/EV validated keys that might work, but that also seems like a lot of work and cost for messaging and sending files.
Also, I'm not sure what threat model you are mitigating by encrypting the payload on an already e2e-encrypted channel since you load third party JS without SRI, don't have a CSP and don't have HSTS. Basically there are a few steps I'd take before worrying about having a minimal server forwarding the handshake. This seems like you have not considered what the threat model for your service actually is.
The handshake can be sent out-of-bound like you say, but if you are not at the same physical place or have some pre-trusted way to transmit them you always need to trust something.
Even if you send it over something that is previously e2e-encrypted like signal or keybase you always need to trust that channel, so unless you actually are at the same physical place to do the handshake over a non-remote channel or have setup the channel earlier I don't think there is a way to do it "truly securely". The same is true for basically all e2e-encrypted systems that don't have a way to establish an out of bounds channel of trust (like for example the web PKI structure or the debian web of trust).
If you were to use existing web PKI (every participant having their own domain) and require all participants to encrypt with their DV/OV/EV validated keys that might work, but that also seems like a lot of work and cost for messaging and sending files.
Also, I'm not sure what threat model you are mitigating by encrypting the payload on an already e2e-encrypted channel since you load third party JS without SRI, don't have a CSP and don't have HSTS. Basically there are a few steps I'd take before worrying about having a minimal server forwarding the handshake. This seems like you have not considered what the threat model for your service actually is.
The handshake could be encrypted with something like https://saltyrtc.org.
I might not just understand the cryptography here, but how does that protect against the server or a third party with access to the handshake to act as a relaying party (basically doing a MITM attack)?
Does it actually not need to trust the server or have any preexisting trust in the other party?
Does it actually not need to trust the server or have any preexisting trust in the other party?
Love these sorts of tools that don't require login or registration, and are usable immediately! Great job.
Other such services shared on news.yc previously: https://sharedrop.net, https://file.pizza, wormhole et al [3][4].
Just a reminder that, WebRTC doesn't leak your public-IP if you're behind a VPN [5].
---
[0] https://news.ycombinator.com/item?id=9568939
[1] https://news.ycombinator.com/item?id=19603947
[2] https://tools.ietf.org/html/rfc8445
[3] https://news.ycombinator.com/item?id=17356023
[4] https://news.ycombinator.com/item?id=14649727
[5] https://news.ycombinator.com/item?id=12527956