Release v3.8.6
🚀 What's New in v3.8.6
This release focuses on data integrity and transfer reliability, ensuring that your files arrive exactly as they were sent, and that the sender knows exactly when the transfer is truly finished.
🛡️ Data Integrity & Verification
- Zero-Overhead Checksums (Blake2b):
fflnow calculates file checksums incrementally during the transfer. This happens purely in memory with zero extra I/O overhead on both the server and client sides.- Web UI: The browser recipient now automatically verifies the checksum upon download completion to guarantee the file wasn't corrupted in transit.
- CLI / Scripts: We've exposed a new
/checksumendpoint. You can verify downloaded files manually or in scripts by fetching the hash (e.g.,curl -NsS "<URL>/checksum") and comparing it locally usingb2sum <file>.
⚡ Reliability & Under the Hood
- Accurate Completion Tracking (Relay Mode): Previously, in HTTP/Relay mode, the sender would finish uploading to the tunnel and wait, but couldn't be 100% sure when the recipient actually finished downloading due to tunnel buffering.
- Now, HTTP downloads implement the same explicit
POST /completehandshake as WebRTC. The sender is explicitly notified the moment the recipient successfully saves the file to disk. - (Note: The CLI exit message will remain unchanged for now while we monitor the stability of this new handshake in the wild, but the underlying tracking is now fully accurate.)
- Now, HTTP downloads implement the same explicit
📦 Which file should I download?
- If you want a single file that runs everywhere, across OSes? choose APE (
ffl.com/fflo.com). - If you want platform-optimized size/perf, choose a native build. 🙂
- On Linux and unsure about glibc (or on musl)? -> APE
ffl.comis the safest choice.
ℹ️ On the first run of a native build, the app performs an internal extraction step (by pyapp), so startup is temporarily slower once.
The install scripts pre-warm this step; manual downloads will see the one-time delay.
APE builds (ffl.com/fflo.com) are single-file and do not have this first-run warmup.
Windows (native)
- x86_64 →
ffl-v3.8.6-x86_64-windows.zip
Unzip to getffl.exe.
Linux (native)
We publish two glibc baselines. Pick the highest baseline that does not exceed your system glibc:
-
glibc 2.39+ — smaller & faster
ffl-v3.8.6-manylinux_glibc2.39-x86_64-linux.tar.gz- Best for newer distros (e.g., Ubuntu 24).
-
glibc 2.28+ — widest compatibility
ffl-v3.8.6-manylinux_glibc2.28-x86_64-linux.tar.gz- Works on older distros (e.g., Ubuntu 20); larger due to additional internal linking.
⚠️ If your system is musl-based (e.g., Alpine) or you’re unsure about glibc, prefer APEffl.com.
macOS (native)
- Apple Silicon (arm64) →
ffl-v3.8.6-aarch-darwin.tar.gz - Intel (x86_64) →
ffl-v3.8.6-x86_64-darwin.tar.gz
The archive unpacks to a single ffl binary.
🧰 APE (cross-platform single file, zero external deps)
ffl.com— Single-file build that runs natively on Linux, macOS, Windows, FreeBSD, OpenBSD 7.3, NetBSD, BIOS, and Android (Termux).fflo.com— Alternative APE build that is exactly aligned with the open-source repo (no additional/proprietary addons).
As a result, features that require closed-source components—such as upload to server (e.g.,--upload)—are not available.
For a deeper comparison between native and APE, see the README’s notes.