It's not clear to me how this differs from Magic Wormhole, which is in wide use already. If it's a Golang implementation of the idea, there's already an interoperable Golang Magic Wormhole: https://github.com/psanford/wormhole-william.
- resuming transfers [1]
- ipv6 support [2]
- local transfer without public relay [3]
- simple installation for windows [4]
- sending folders without zipping (i.e. send in place) [5]
*some features, like ipv6 support, were generously tested/coded/inspired by others.
[1]: https://github.com/warner/magic-wormhole/issues/88
[2]: https://github.com/warner/magic-wormhole/issues/354
[3]: https://github.com/warner/magic-wormhole/issues/48
To me this is the killer feature. It's not terrible to transfer files between different dev computers - the users probably have the understanding or software to make that happen.
It is really hard to send your mom large files.
* I believe (someone else can confirm) that you can generate a single-binary `wormhole-william` for Windows that will interoperate with magic-wormhole.
* I believe v6 support works in wormhole as well.
How does your resumption feature work, cryptographically?
Thanks!
If you don't have the Go toolchain installed we provide prebuilt binaries on the github release page: https://github.com/psanford/wormhole-william/releases
Files are collections of "blocks". This allows files to be read in parallel (reading block at position X) and written in parallel (writing block at position X). Resumption works by having the recipient determine empty blocks (positions filled with 0's) and then requesting the sender to only send required blocks (specified by positions).
This has a trade-off - there are no "progress" files needed (which might not get removed if you don't know about them and don't want to resume) but it also means you can't send a file filled with 0's.
To be clear, this can't support a file that contains a block worth of 0s anywhere in the file? That seems like a severe limitation
Although, the recepient should have encrypted blocks, right? So its only when the output of the hash is all 0's that it should conflict with the resumption algorithm
I think I was sleepy because I errored in saying that. You can send a file with 0's without a problem.
The only little bug is if you resume a transfer of a file that is filled with zeros then the recipient will re-request blocks it already has (because they are zeros) so that parts of the file get sent twice (worst-case scenario). It is a bug, but a small one IMO that has never manifested in my reality (via issues or my own use). Happy to accept PRs to fix it though!
The files can
1. Contain backreferences to the target files whose progress they represent (full path).
2. Be stored in a well-known location, so the program can sweep through all of them at start-up or shut-down and garbage-collect all those whose target file no longer exists.
magic-wormhole has most everything (currently its missing capabilities for multiple file transfers and file resuming), but it requires installing lots of the Python ecosystem which is tricky for non-developers (and Windows users)
there's already an interoperable Golang Magic Wormhole