FluxDown: A Free Download Manager Built with Rust + Flutter

Zhiwei Ma — Mon, 16 Feb 2026 07:29:40 +0000

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.

Building a GPU-Accelerated Terminal Emulator with Rust and GPUI

Zhiwei Ma — Sat, 24 Jan 2026 05:40:42 +0000

I've been working on a terminal emulator project called zTerm in my spare time, and wanted to share some lessons learned along the way.

The Stack

Terminal emulation: Built on top of alacritty_terminal - no need to reinvent the wheel for VT parsing
UI Framework: GPUI, the same framework that powers the Zed editor, with GPU-accelerated rendering
Component library: gpui-component from Longbridge

I chose GPUI because I was curious about what makes Zed's rendering so smooth. Wanted to see if I could achieve similar results.

Challenges I Faced

Cross-Platform PTY

The differences between Windows ConPTY and Unix PTY were bigger than expected. Signal handling and process lifecycle management took significant debugging time.

IME Support

Supporting Chinese/Japanese/Korean input methods was tricky. Cursor positioning, candidate window placement, and composition state handling all behave differently across platforms. GPUI's documentation is sparse here, so I ended up reading Zed's source code.

Rendering Performance

Initially, I was triggering a render on every PTY event. Running cat on a large file would freeze the terminal. Adding a 4ms batching interval to coalesce multiple events before rendering made a huge difference.

Current Status

Basic functionality works: multi-tab support, scroll history, mouse selection, and keyboard shortcuts. Split panes are in progress, and theming is planned.

The code is still rough around the edges. If you have experience with GPUI or terminal emulators, feedback and PRs are welcome.

GitHub: https://github.com/zerx-lab/zTerm

Built with Rust. No pre-built releases yet - you'll need to compile from source if you want to try it out.

Forem: Zhiwei Ma