See https://instant.io [0] for a similar file sharing service, but over BitTorrent over WebRTC (not sure if it requires a relay TURN server when peers are behind symmetric NAT) [1][2].
"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.
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.
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?
> 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).
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.
It's a few things, drop is the word for licorice and lol is the word for fun. It's also one letter off 'droplul' which would be a swear word for asshole, literally: licorice dick.
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.
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?
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