BitSpeed Transfer Now Shows Progress, and Only Counts What the Receiver Confirmed

Until now, bitspeed-transfer send was quiet until it finished. On a big file over a slow link that’s a long time to stare at a cursor. Transfer 0.3.0 prints progress while it works.

Progress bars usually count bytes leaving the sender. That number can be wrong in the way that matters most: a chunk can leave and never arrive, or arrive and never get written. Transfer counts a chunk only after the receiver replies that it stored it, with the chunk’s index, the transfer’s identity and the chunk’s SHA-256 all matching. If the number says 25 percent, the receiver has 25 percent on disk and verified.

What it looks like

Here’s a real run with the released 0.3.0 binary: a 64 MiB file in 1 MiB chunks over loopback. We killed the sender a moment after it started. Its last line was:

sent 16 of 64 chunks, 16777216/67108864 bytes (25%)

Then we ran the same command again. The first line it printed came from the receiver, not from anything the sender remembered:

receiver has 16 of 64 chunks verified; sending 48 (50331648 bytes)
sent 1 of 48 chunks, 1048576/50331648 bytes (2%)
...
sent 48 of 48 chunks, 50331648/50331648 bytes (100%)
all 64 chunks verified; receiver is checking and publishing the file

The two numbers line up. The killed run said 16 chunks, and after restart the receiver vouched for exactly 16. The resumed run then sent the other 48 and finished with transferred true.

The details

Progress goes to stderr. The JSON result still goes to stdout on its own, so scripts that parse it don’t change. Lines print at most once per percent, so even a file at the protocol’s limit of 16,384 chunks produces about a hundred lines. The lines hold counts and byte totals only, never paths, URLs or tokens. A transfer the receiver already reports as complete prints nothing, because there’s nothing left to do.

If stderr goes away mid-run, for example a closed pipe, the command stops. That’s safe: every chunk already acknowledged stays verified on the receiver, and running the command again picks up from there, as above.

Nothing else changed. The protocol is the same, so 0.1.0 through 0.3.0 senders and receivers work together, and clean from 0.2.0 is still there. An independent review before release found no blockers. Delivery is still Linux and macOS only. Get it from the download page.