I've been working on a download manager called FluxDown that handles multiple protocols in one app. The backend is written in Rust on top of Tokio, and the GUI uses Flutter with shadcn-style components. It's free, no ads, no accounts required.
Here's what it does and why I built it this way.
Multi-Protocol Downloads
Most download managers handle one protocol well and ignore the rest. IDM is great for HTTP but can't do BitTorrent. qBittorrent handles torrents but nothing else. I wanted a single tool that covers everything I actually use day to day:
- HTTP/HTTPS with adaptive segmentation (more on this below)
- FTP with multi-connection parallel downloads
- BitTorrent via librqbit — magnet links, .torrent files, DHT, UPnP
- HLS streaming — .m3u8 with AES-128 decryption
- DASH streaming — .mpd with quality selection
Adaptive Segmentation
This is probably the part I'm happiest with. IDM splits every download into 8 segments regardless of file size or connection speed. That works fine in many cases, but it's not optimal.
FluxDown takes a different approach. Before starting a download, it sends a 512KB probe request to measure your actual bandwidth. Then it calculates the segment count based on three factors: file size, measured bandwidth, and CPU core count.
The logic works like this: files under 4MB don't get segmented at all — single connection is fine. For larger files, each segment is at least 2MB. The upper bound is 4x your CPU core count (for I/O parallelism), capped at 64. If your bandwidth is below 512KB/s, it scales down to 25% of the recommended count to avoid overloading a slow connection.
There's also runtime dynamic splitting. When one segment finishes, the idle worker picks up part of the slowest remaining segment. This matters more than you'd expect on connections with variable speed.
Architecture
The download engine is a Rust binary running on Tokio's async runtime. Each download task is an independent tokio task with its own CancellationToken for lifecycle control. The Rust side handles all network I/O and disk writes.
The GUI is Flutter (Dart), connected to the Rust backend through the Rinf framework using FFI with bincode serialization. This keeps the UI responsive — Dart handles rendering and user interaction, Rust handles the heavy lifting. No shared memory headaches, just message passing.
For HTTP, I use reqwest with rustls. FTP goes through suppaftp's synchronous API wrapped in spawn_blocking with mpsc channels. BitTorrent uses librqbit with its own multi-threaded runtime, also in spawn_blocking since it internally calls block_on.
Browser Extension
The Chrome MV3 extension (also works on Firefox) has a three-layer interception system:
- webRequest API caches download metadata
- downloads.onDeterminingFilename does the main interception
- downloads.onCreated catches anything that slips through
For streaming detection, it monkey-patches the page's fetch() and XMLHttpRequest to catch .m3u8 and .mpd URLs automatically. The extension talks to the desktop client over a local HTTP API on port 19527 — no Native Messaging needed, which makes installation simpler.
Other Details
- Speed limiting: Token bucket algorithm with 50ms refill intervals. Smooth curve, not choppy.
- Persistence: All task state goes to SQLite. Resume works after crashes and reboots.
- UI: Dark and light themes, 12 color schemes. System tray, .torrent file association, single-instance enforcement.
- Code quality: Rust edition 2024 with strict Clippy lints — deny on unwrap, expect, and wildcard imports. Every error path is handled explicitly.
Limitations
Windows only for now. No post-download script execution. BT download speed depends on seed availability (nothing I can do about that). SOCKS5 proxy support exists but isn't perfectly stable yet.
Try It
FluxDown is completely free — no ads, no accounts, no telemetry. All data stays local.
Website: fluxdown.zerx.dev
I'd appreciate any feedback on the architecture decisions or feature requests.
Top comments (2)
Impressive work on FluxDown! The adaptive segmentation based on real-time bandwidth is a game changer for download efficiency. Have you considered integrating a feature for dynamically adjusting segment size during a download based on fluctuating network conditions? That could push performance further, especially on varying connections. Excited to see how this evolves! 🚀
thankyou I will try it 🔥🔥