▲ 52 points
back
27 comments
Sounds like Magic Wormhole (https://magic-wormhole.io/). The readme acknowledges Warner at the end.
Key differences seem to be resumable transfers and proxy support.
Another is a single binary, whereas MW is in Python, but there’s now https://github.com/magic-wormhole/magic-wormhole.rs
I appreciate that the project acknowledges its inspiration. I wish it were more common for projects to provide detailed comparisons with similar ones for people trying to choose.
I’ve found croc to be more reliable than MW in across different network architectures — croc has worked in places where MW has not. I’m not sure why.
Hm. I had the exact opposite experience. Weird.
Hard-coded to use his relay server and then asking for donations for bandwidth?
croc is great. been using it for unimportant transfers for years. If you want to donate money then start with syncthing which is decentralized and even more useful. could syncthing add croc-like command that was as simple and quick?
Seems reasonable, no?
I keep a list of mostly browser based and some cli, p2p file sending tools in like croc. https://gist.github.com/SMUsamaShah/fd6e275e44009b72f64d0570...
How can one be sure that the relay does not record all the data flowing through it? There's not a second independent channel where the key is exchanged between sender and receiver.
The transfer is end2end encrypted using a PAKE key change which is aithenticated using the 3 words you enter in the reveiving end
Thank you. I imagined that the 3 words were just a rendez-vous token that the receiving end must hand to the relay to retrieve the right data. I understand that it also includes a password to validate the key.
Are 32 bits enough to serve both functions?
Yes 32 bit is enough because in PAKE its used for authenticstion not encryption. Which means you get exactly one attempt to brute force after which the procedere will fail
I use croc instead of magic wormhole as of a year ago now. In my testing the throughput is higher than magic wormhole because it uses multiple TCP connections to transfer the files.
one thing that gets me is this should be one of the most basic tasks between two machines and it has been increasingly, systematically abstracted from us, to control what channels it goes through, if it even goes through at all. so kudos to this app but this should be easy at an OS level and it isn't, by design. likely for the same reason airdrop is not a thing in china
Fair, though I think a large part of why this has always been more difficult than it should be is the fundamental design of TCP and IP. The former encodes notions of “roaming client” and “durable server” in ways incompatible with devices that periodically want to assume either role, and the latter (at least IPv4) encourages network segmentation in such a way that reachability and discoverability are harder than people might think.
The centralized powers that be definitely deserve a share of the blame to be sure, but some of it is architectural.
File transfer isn't an OS level problem. There are already a million utilities that let you get a file from computer A to computer B if they are reachable over IP. Connecting the computers in a secure way is the hard part, hence the need for all the workarounds.
For most people, it is part of the OS though. Windows comes with Client and Server services activated by default even on the Home edition for some reason. The functionality is dumbed down and hidden though, while onedrive - which requires registering a windows account - is shoved in the user's face.
It was easy, via Airdrop, but the CCP doesn’t like people being able to share files in a decentralized manner in groups, and Apple ceases to exist as we know it if they don’t do whatever the CCP wants, so it was nerfed.
CCP in the USA? What?
If you have IPv6, it’s easy. In IPv4 land… Good luck.
Croc has broke down for me quite a few times when transferring large files. I switched back to MW.
Similar to dynpipe. But you can also send from website dynpipe.com and mix terminal and web.
What does this give me that unison doesn't?
Unison is dead, this project is alive.
there is absolutely nothing that indicates that it is. Have you considered that it might be complete? Software doesn't need to keep accumulating cruft for it to stay alive. Sometimes it just does the job and is finished
I mean i still see commits and afaict it just works for me. How much active development does a service like this need?
As someone else mentioned a while ago, I think unison suffers from 'lisp curse'.. it just works. [0]
this has been fine working since the 80s
pc1> tar c <SRC_FOLDER_OR_FILES> | nc -l 12345
pc2> nc <IP_OF_PC_1> 12345 | tar xv -C <DST_LOCATION>No auth? I like to live dangerously too lol.
Jokes aside, the probability of it being exploited is low though.
Also, this assumes pc1 has a publicly, where as with Croc and MW, you can transfer files between two PCs on both behind different NATs.