Parallel streams where single-TCP tools stall. Sturdier than rsync over the internet.

The whole workflow

Two commands, either direction.

$ CODE=$(blixt code --words)
$blixt send dump.sql --code "$CODE"
peer connected · direct/ICE (QUIC)
verify (SAS): 055 437
■■■■■■■■■■■■■■ 100% · BLAKE3 verified

# on the other machine
$blixt recv --code "$CODE" --out /srv/restore

The code is ≥130-bit CSPRNG entropy (12 BIP39 words or base32). The 6-digit SAS is derived from the TLS session itself — matching codes prove no one, including the signaling server, sits in the middle.

Long fat pipes

Why single-TCP tools crawl on a 150 ms link.

scp and rsyncride one TCP connection with loss-based congestion control: every lost packet is read as congestion and the window collapses, so on a long path with even light loss the pipe sits mostly idle. Blixt opens N parallel QUIC streams (quinn) with BBR, which models the path’s actual bandwidth and RTT instead of panicking at every drop.

Honest fallbacks:where UDP is blocked, Blixt falls back to HTTPS — N parallel TCP + TLS 1.3. It gets through strict firewalls, but on lossy links it is slower than QUIC; that’s why it’s the fallback, not the default. Last resort is a relay, and the free relay is throttled to 1 MiB/s. The raw reproduction package, hardware list and direct-path scp comparison are still pending here: /benchmarks.

Resume

An interrupted 200 GB dump keeps its verified progress.

Every transfer keeps a MAC-protected journal. After a drop — flaky VPN, rebooted box, cross-continent hiccup — the next session uses its authenticated block journal and re-sends only missing chunks. The journal is authenticated, so it can’t be forged or replayed, and the final file is verified with BLAKE3 per chunk and end to end.

$blixt send db-dump.tar.zst --code "$CODE"
■■■■■■■■■■□□□□ 71% · link lost — waiting for peer
peer reconnected · resuming at chunk 5 812
■■■■■■■■■■■■■■ 100% · resumed ×1 · BLAKE3 verified

Air-gapped

No internet in the room? --lan.

LAN mode needs no signaling server and no internet at all: peers find each other via an authenticated multicast beacon (keyed from the shared code — the code itself never leaves the LAN, only a keyed tag does), then connect directly with the same pinned TLS and 6-digit SAS as always. Built for isolated segments, lab networks, and site visits.

$blixt send --lan --code "$CODE" image.qcow2
$blixt recv --lan --code "$CODE" --out /data
peer found on 192.168.20.14 · direct QUIC · no server involved

Honest caveat: discovery needs a multicast-capable LAN — some corporate networks block multicast between ports.

Self-host

Keep the hub inside your perimeter.

The signaling hub only coordinates the handshake — it never sees plaintext, and the out-of-band SAS defeats even a compromised hub. If policy says no third-party coordination at all, embed the hub in your own daemon and point peers at it with --signal.

$ blixtd --embed-signal --signal-addr :8080
local web UI on 127.0.0.1:7777 · signaling hub on your box, port 8080
# peers: blixt send/recv --code "$CODE" --signal <your hub URL>

Without --signal-addrthe embedded hub binds loopback only — remote peers need the bind flag. The local web UI binds to loopback and is origin-guarded. Threat model, including what we don’t defend against: /security.

Automation

Cron it. CI it.

The CLI is headless-first. blixt batch runs a JSON queue of jobs serially and stops on the first failure; --bandwidth caps the send rate so a nightly dump doesn’t starve production; --transport quic|https pins the transport when your network policy demands it.

# nightly off-site dump, capped at 200 Mbit/s
$ crontab -l | grep blixt
0 2 * * * blixt batch /etc/blixt/nightly.json --yes --bandwidth 200

# nightly.json
[{"code": "…26+ chars…", "files": ["pg-dump.tar.zst", "wal/"]}]

Read before you script it: --yesauto-confirms the 6-digit SAS because an unattended job can’t compare codes — which disables the man-in-the-middle check for that run. Use it only on paths you already trust (your own hub, your own perimeter); interactive runs should always compare the code.