Release v3.9.5

🚀 What's New in v3.9.5

Welcome to v3.9.5. This release focuses on deep performance optimizations for the network stack, resulting in significantly faster startup times. We've also introduced new piping parameters to better support automated workflows and server migrations.

⚡ Connection Optimization & Reduced Latency

We have fundamentally restructured the connection initialization sequence to minimize round-trip times (RTT). For users on high-latency networks (e.g., mobile connections), this results in a substantial reduction in setup time—saving roughly 12 to 15 seconds per share session.

• Intelligent API Caching: Tunnel availability and optimal routing paths are now cached locally.
• Direct Edge Fetching: Short-lived access tokens are fetched directly from the tunnel edge, bypassing unnecessary requests to the main API server.
• Network Stack Improvements: Implemented TLS Session Resumption, Parallel Prefetching, and TCP Pre-Connect, alongside pre-warmed SSL contexts. Redundant reachability probes have been removed.

Benchmark Comparison:

Phase	Time	Improvement
Old Cold Start	~6535ms	Baseline
New Cold Start	~2316ms	65% Faster
New Warm Start	~337ms	95% Faster

🌍 Unrestricted Routing Selection

• Removed the 500MB Limit: Previously, files exceeding 500MB were hard-coded to route through our unlimited bandwidth tunnel (33.fastfilelink.com). This restriction has been removed. ffl now dynamically evaluates and selects the lowest-latency tunnel for all transfers, regardless of payload size.

🛠️ Pipeline & DevOps Integration

We've added new features to support headless server migrations and advanced piping scenarios, allowing you to move data with zero disk footprint.

• Streaming Output (--stdout):
  You can now redirect downloaded payloads directly into stdout for on-the-fly processing or extraction.

  • Download and extract directly (e.g., during a system restore): ffl download "$URL" --stdout | tar -xf - -C /restore/path
  • Redirect stream to a custom file: ffl download "$URL" --stdout > output.bin

• Disable Stdin Caching (--stdin-cache off):
  When piping data into ffl (e.g., tar -cf - /data | ffl -), the stream is cached to disk by default to support multiple downloads or connection resumes. For one-to-one migrations where disk space is exhausted, you can use --stdin-cache off. This streams the data straight to the network, entirely bypassing local disk I/O.

---

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

• glibc 2.28+ — widest compatibility

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