Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Show HN: Payload – Cross-platform desktop app for LAN file transfers (payload.app)
65 points by klabb3 on July 14, 2022 | hide | past | favorite | 31 comments
Hi HN.

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:

https://news.ycombinator.com/item?id=21575869

https://news.ycombinator.com/item?id=24351111



Just tested this between my MacBook Pro (Max with 64GB RAM) and my main workstation, GodBoxV3 (Dual 20 Core Xeon, 256GB RAM, and lots of SSD/NVMe storage). The MacBook has a 10GbE link and GodBoxV3 has 2x10GbE Links... Tried sending a file from the Mac to GodBoxV3 and it didn't top out at more than 40MB/s. The Windows client also crashed about halfway through. Mind you, when I restarted it, it did recover the transfer. Going the other direction, I seem to be getting around the same kind of speed. One thing I want to test is whether it works over a VPN. Interesting concept and easy to use. lets see if it can get even better.


Thanks a ton for trying out! I get >100 MB/s between my M1 and Windows machine (with significantly worse specs than yours) so this was a cold shower. Can I ask:

- 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


in both cases, I transferred a single ISO. one was 1.7GB (Mac -> PC) and back it was 6.5Gb (Win -> Mac). CPU seems to be quite low... PC is hovering around 11-14%, it's usually at 10% (got some VMs running in the background). Agent on the mac is around 4-5. Just ran a second test today, and got less than 5MB/s from Windows -> Mac. The numbers for CPU and RAM above are from that run. 6.5GB ISO is being sent again... [Edit] There is a pending reboot on that Windows box I need to do, at some stage, and I will retest it then. I double-checked that it wasn't sent data over Zerotier or Tailscale (both installed on both machines) and nope. It's just over the standard LAN. Both boxes are on the same subnet, so nothing between them. I will do a bit more digging and open a ticket with my findings. Thanks.


For people reading this: tiernano has been super helpful on github & discord. Early triaging shows payload chose quic over TCP despite firewall disabled. Quic is a fallback and not yet CPU optimized, and struggles on windows (looks like a single threaded bottleneck - one core was at 100%). It appears payload jumps to the fallback too quickly, without giving TCP a fair chance first.


Is your HD on one or both of the machines possibly the bottleneck?


Nope. NVMe in both cases...


Why use QUIC in LAN?


Good Q. I wanted to have QUIC for future NAT traversal plans, so I put it in the net stack to keep my architecture in check and not overfit to TCP. Today, Quic is just a fallback though.


Not knocking the project, I love the idea -- but that it needs to be built today is, for me, such a strong indicator of some of the terribly divisive decisions that were made by the big incumbents so long ago. Which is to say, this would have been trivially easy to implement 20 years as a standard feature of operating systems.

I'll check it out. FWIW, I've just been using a dedicated syncthing folder for this purpose.


Looks awesome! But I have to ask, if all file transfers are being done locally, why the end to end encryption?

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.


Thank you!

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.


Maybe it's good for public places like cafes and offices?


Rusty disks are slower than any modern symmetric encryption.


https://file.pizza afaik does LAN transfers using webrtc, supports iOS and Android because it's just a browser application.

(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 tried it recently as well as P2P based apps like https://www.sharedrop.io/ but it doesn't work great for large files (> 500MB). The speed decreases the longer the transfer takes.

I have to try if it is the same case with Payload.


This didn't work on my network. The transfer never moved more than 0%, going from my desktop to my phone.


How is this better than SyncThing?

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?


It's a fair question. SyncThing is a great piece of software and has overlap with Payload.

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.


Is the main selling point the ease of use copying between devices, or better performance compared to existing network file sharing software?

I want to understand how this is better than Samba or NFS.


Short answer: ease of use. Setting up shared folders cross-platform is non-trivial for the average person.

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.


> Setting up shared folders cross-platform is non-trivial for the average person

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.


Device to device (PCs, tablets, phones) file sharing within the Apple ecosystem is relatively easy, even with strangers if you set your airdrop to ‘everyone’.

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.


Sweet tool, though i'm more of a terminal-focused guy (for which i definitely recommend croc)


You may have answered this in a previous thread, or it may be a dumb question, but why not just wrap rsync?


It's not dumb. Many subtle differences but I guess the biggest one is that with Payload the receiver can see the proposed files and sizes, choose dst dir and accept/decline, so you don't need to go on each device and tell it "I trust these other devices" before the fun begins.


Sounds like a handy utility, even in an all-Mac household. I'm fed up with this Mac mysteriously not being able to see that one on the same router when browsing the network with Finder... despite the fact that THAT one can see THIS one.


I'm having the exact same problem, AirDrop used to be so reliable now I can't see one device from the other one most of the time


Matches my experiences too, airdrop has been quite flaky but I'm not sure exactly why. (Of course that could happen with payload too but so far it's been reliable in all home LANs I've tested in.)

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.


Congrats on the launch.

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


For fastest file transfers available, I prefer: https://udt.sourceforge.io/


Any plans for an Android app?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: