Show HN: Payload – Cross-platform desktop app for LAN file transfers (payload.app)
I built Payload to make file transfers easy for less-technical users who need large/fast transfers, so I have focused on auto-discovery, drag-and-drop, visually distinct device icons.
It's using Tauri (an "Electron alternative" built on Rust) which keeps my binaries small and bundles to .msi, .dmg, .deb and .appimage. No CLI, iOS or Android support (yet).
The network stack is a separate binary written in Go. It uses mDNS for local network discovery and TLS over TCP or Quic, with a public Ed25519 keypair for each device. The protocol is ad-hoc and symmetrical control stream using JSON and binary data streams. Planning to open source these parts eventually..
Transfers should saturate the local network link. It reaches ~116 MB/s wired at my home, but if you have a >1000 Mbit link, I'd be curious to see how much speed you can squeeze out.
See also:
32 comments
[ 2.9 ms ] story [ 78.9 ms ] threadI want to understand how this is better than Samba or NFS.
The long answer is that transfers and shared storage are fundamentally different use-cases (imo). Shared storage usually means you grant and revoke access to a subdir (ACLs), which are (1) often overly permissive and (2) exposes a file structure that isn't necessary for the other side.
Transfers OTOH is an ephemeral action where sender picks files from their file system, receiver decides the destination directory (so file systems are not exposed in either direction).
That said, if you are looking for shared storage, check out https://www.spacedrive.com/. It's also built with Tauri.
It's nontrivial for me either. Until Windows got a native SSH client, it was the same problem every time: do I install like an FTP server somewhere and use Explorer, or set up a samba server on my linux box or how even do I copy more than a few megabytes... I don't understand how normal people can do this if even I have trouble, especially between two different OSes. Probably usb sticks are the answer, but then normal people don't have micro-to-female-A converters to connect flash drives to a smartphone, or know that you can even do such a thing.
And so that's why I maintain https://dro.pm and, e.g. when implementing encryption (which I didn't end up implementing because it was literally impossible given the ~2020 state of browser support), one of the main requirements is compatibility. If it's not going to work on any potato, I might as well not have it half the time, because on my own hardware I can usually just ssh. Unless you really want to transfer more than a few gigabytes of data, this works reliably (good old 90s <input type=file>, no JavaScript magic in that part) and the occasional wait is better than having to do sorcery with custom software on both ends, also because I usually don't own the non-linux endpoint.
I’m not aware of a Windows version of this that “just works”. SMB has a lot of weird error edge cases, especially when firewalls are involved. I’ve used the Win10+ OpenSSH service to transfer files a number of times, myself.
- Did you transfer a large e.g. a large directory (I haven't optimized for large amount of files) or just a single file? If so, was that file large enough to let the speed ramp up?
- Did you happen to notice high CPU or memory usage during the transfer? Expected memory usage of payload-agent.exe is ~7-20 Mb. CPU can sometimes be a bottleneck if Payload decides to use Quic (but it should prefer TLS/TCP under normal conditions and 40 MB/s is still too slow).
..or free to file a bug report at https://github.com/betamos/payload
I'll check it out. FWIW, I've just been using a dedicated syncthing folder for this purpose.
(Does have browser JS limitations, but then for serious copying I would use something like ssh anyhow. Don't want an hour-long transfer to fail halfway through because javascript had a hiccup.)
I have to try if it is the same case with Payload.
A user would have much bigger problems if their LAN has been compromised. I assume turning off the encryption would speed up the transfers, especially if moving things between rusty disks.
Encryption shouldn't bottleneck a CPU (I think), and why would disk performance matter? Only the transmission is encrypted.
Anyway.. Your point still stands. The true answer is a combination of "why not" and I'd like to extend outside of LANs in the future.
SyncThing works across the Internet. If you think your GUI is better, why not integrate the syncthing backend? If you think your LAN transfer is faster, why not contribute that code to syncthing?
In another comment, I explained why I think transfer and storage are fundamentally different: https://news.ycombinator.com/item?id=32102205
SyncThing would be perfect to integrate with SpaceDrive but makes less sense for Payload, today.
Another feature that you may enjoy is if you close the lid or have to rush out in the middle of a large transfer, payload resumes automatically. You can also queue a transfer to an offline device. I'm also planning to add system sleep prevention during transfers.
I recently released something similar[1][2] (cross-platform file transfer, mostly for LAN but also works over the internet).
I feel like our projects are kinda complementary, you do frontend well, I think I win in terms of backend.
Hit me up if you want to chat and/or collaborate.
[1] https://github.com/mprimi/nasefa
[2] https://news.ycombinator.com/item?id=32027970