Skip to content

Release v3.8.6

Choose a tag to compare

@Leona-Wang Leona-Wang released this 04 Mar 15:20
· 53 commits to main since this release
0dcdd1d

🚀 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): ffl now 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 /checksum endpoint. You can verify downloaded files manually or in scripts by fetching the hash (e.g., curl -NsS "<URL>/checksum") and comparing it locally using b2sum <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 /complete handshake 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.)

📦 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.com is 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_64ffl-v3.8.6-x86_64-windows.zip
    Unzip to get ffl.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 APE ffl.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.