Release v3.8.7

🚀 What's New in v3.8.7

📦 The "Digital Courier" Update: Recipient Verification

This major release introduces the Recipient Verification system. Moving beyond standard password protection (which is for sharing with a group), these new modes ensure that your file is delivered to the exact intended person—just like a digital courier requiring a signature.

You can now use the --recipient-auth flag to choose how the recipient proves their identity before downloading.

🔑 Four Ways to Verify Your Recipient

1. One-Time Pickup Code (pickup)
The classic courier experience. Generates or sets a 6-digit pickup code. Perfect for sending files to clients where you want a single, verified delivery without requiring them to create an account.

• Usage: --recipient-auth pickup --pickup-code 123456

2. Anonymous Identity Pass (pubkey)
Designed for maximum privacy and Tor users. Verify the recipient using a long-term RSA Public Key (.fflpub file) without knowing their email or phone number. Only the person holding the corresponding private key can unlock the download.

• Usage: --recipient-auth pubkey --recipient-public-key ./client.fflpub

3. Two-Factor Anonymous Delivery (pubkey+pickup)
For high-security scenarios. Combines the long-term identity verification of a public key with the one-time, single-use nature of a pickup code.

• Usage: --recipient-auth pubkey+pickup --recipient-public-key ./client.fflpub --pickup-code 123456

4. Email OTP Verification (email)
The standard business delivery method. The recipient must enter a one-time password sent to their specified email address to claim the file.

• Usage: --recipient-auth email --recipient-email client@example.com

🛠️ Decentralized OTP Infrastructure

True to our decentralized philosophy, the Email OTP feature is not locked to our servers. You can easily point the OTP dispatch mechanism to your own infrastructure using the --recipient-otp-api-base flag.

• Usage: --recipient-otp-api-base https://my-custom-server.com/api

---

📦 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_64 → ffl-v3.8.7-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.7-manylinux_glibc2.39-x86_64-linux.tar.gz
  • Best for newer distros (e.g., Ubuntu 24).

• glibc 2.28+ — widest compatibility

  • ffl-v3.8.7-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.7-aarch-darwin.tar.gz
• Intel (x86_64) → ffl-v3.8.7-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.