The thing that usually annoys me about these services is they tend to give you an intractably complex URL to share with the recipient. This poses a problem because every time I need such a P2P transfer, I’m communicating with someone over the phone and they need the file on a computer (which may not even be their own, so email is also cumbersome).
https://file.pizza does this better than most, as the URL consists of real words. But all the words are ingredients in English which comes back to being an issue again.
https://pairdrop.net is my go-to, since it allows creating temporary “rooms” with just five letters, which are easy to share over the phone.
Still, I continue to wait for the holy grail of a P2P service which would allow me to initiate a connection via CLI and get a simple URL to share with someone who could download the file from a web browser, saving me from having to babysit the browser tab. There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link.
One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key. So your security must either come from PAKE (like magic-wormhole and friends), or from the good behavior of some intermediary. And PAKE requires a peer who knows the plaintext and will only execute the protocol once, which means it really needs to be the person you're connecting with and not an intermediate webserver.
I think it's a 2-out-of-3 trilemma: end-to-end encryption, short codes/URLs, offline/non-interactive workflow: choose two. Or framed differently, if you require proper encryption, then either the code/URL must be long enough to hold the full key, or you must use an interactive (PAKE) protocol which means both agents must be running at the same time (babysitting).
Your last point is an interesting one: we could build a form of magic-wormhole where the sender's CLI waits, the recipient gets a URL, the URL points to a web page which performs the client side of the protocol. The server wouldn't host the file, just the decryption agent. Basically wormhole receive in a browser. That would match many of your goals.
However I'd be hesitant to do this with magic-wormhole because it opens up a vulnerability we don't currently have: the web server hosting that page could silently swap out the JS with a version that retained a copy of the plaintext, perhaps only when the browser is coming from a specific IP. You can't audit a webserver for consistent+correct behavior the way you could with e.g. the contents of a Debian distribution.
That said, the usability gains of the recipient not needing a CLI tool installed might be worth the tradeoff for some folks.
> a "simple URL" isn't big enough to hold a full-entropy encryption key.
I don’t care about that most of the time. When I do I’m unlikely to trust some random web service anyway (how do I know the author didn’t turn rogue the day before and decided to send a copy of every file to their own server?).
The service could offer a choice, where picking the short link comes with a big red warning. That could even be hidden under some setting on the page, since it’s the sender who needs to understand the implications.
> the usability gains of the recipient not needing a CLI tool installed might be worth the tradeoff for some folks.
That’s exactly what I’m looking for. Whenever I need one of these services, there is 0% chance the person on the other side would know how (or have the patience) to install a command-line tool.
> I'm the author of magic-wormhole
Thank you for taking the time to expand so thoroughly from experience.
> One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key.
If you trust the server not to MITM you, then you don't need the encryption key in the URL. The URL only needs to be long enough so it cannot be guessed by an attacker, 64 bits should be plenty. Once the peers connect to the common URL, they can generate an arbitrarily large key by performing ECDH through the server. (This is where you assume that the server is not doing MITM.)
> There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link.
There are exceptions to this; I've been making copyparty[1], an httpd which lets you start downloading a file that is still being uploaded[2]. If you catch up with the uploader, it'll throttle the speed so the browser doesn't drop the connection. Uploads and downloads can be done through browser and/or cli.
I recall there was at least one other alternative with similar functionality somewhere on the awesome-selfhosted list, but I'm failing to find them right now... It was prominently mentioned in the project's readme, but maybe that's no longer the case.
if you stop sending data entirely, browsers tend to drop and reopen the connection after a few minutes, assuming something got stuck along the way. Throttling seems to prevent that nicely.
Unfortunately this seems like it’s something I’d need to host myself, and that’s something I specifically don’t want to do. I only need to share on occasion, and always want to do it with the least hassle possible.
Yep, and the server bandwidth can become a bottleneck if the peers are fast enough, so true peer-to-peer is still the better choice, or something webtorrent-based if multiple people are grabbing the same file.
But there's been enough last-minute submissions of DJ material by now that I'm still happy it was added as an option :-)
That’s a lot of red! I didn’t know about this one, thank you for the share. I suspect I still won’t use it over PairDrop because the web page is too busy, the “Check out my other projects” completely draws the eyes, and I want something that’s clean and not distracting for the receiving end.
> the holy grail of a P2P service which would allow me to initiate a connection via CLI and get a simple URL to share with someone who could download the file from a web browser
git clone https://github.com/jech/galene-file-transfer
cd galene-file-transfer
go build
./galene-file-transfer -to john https://galene.org:8443/group/public/somethingdifficulttoguess/ file.tar.gz
It wasn’t the lack of commits which made me think this was abandoned, but everything else (outdated instructions, issues and pull requests open with no reply, giant warning at the top of the README…).
If it were completed, the author should have closed/rejected every issue and pull request and removed this large warning at the top of the README:
> THIS PROJECT IS STILL IN EARLY DEVELOPMENT IT USES EXPERIMENTAL
CRYPTOGRAPHIC LIBRARIES AND IT HAS NOT HAD ANY KIND OF SECURITY
OR CRYPTOGRAPHY REVIEW THIS SOFTWARE MIGHT BE BROKEN AND UNSAFE
Plus, install instructions are outdated. As soon as I tried them, `go` complained of using a deprecated method.
So everything points to it no longer being under development.
Not much development can be done about experimental cryptography, you just use it and that's all. Cryptographic review can't be written either. Also you said you don't want much cryptography.
> Not much development can be done about experimental cryptography
That’s not the bit that matters, it’s the “this project is still in early development” and “this software might be broken”. Those are the things which hint at the project not being done.
That is the opposite of what I want, everything about it is harder to share over the phone. Magnet links are not exactly short and now I’m asking people to install a BitTorrent app too, on a computer which might not even be theirs.
The file.pizza one doesn't look like it's peer-to-peer. You upload a file to their server, and then they provide a download URL you can share. Kind of the opposite of peer-to-peer. I would expect a "P2P" file transfer product to not require any intermediate storage besides the sharing user's and the recipients'.
https://file.pizza does this better than most, as the URL consists of real words. But all the words are ingredients in English which comes back to being an issue again.
https://pairdrop.net is my go-to, since it allows creating temporary “rooms” with just five letters, which are easy to share over the phone.
Still, I continue to wait for the holy grail of a P2P service which would allow me to initiate a connection via CLI and get a simple URL to share with someone who could download the file from a web browser, saving me from having to babysit the browser tab. There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link.