DEV Community: Zhiwei Ma

I built a free, open-source IDM alternative with Rust and Flutter — here's how the download engine works

Zhiwei Ma — Sat, 04 Jul 2026 11:25:55 +0000

TL;DR: FluxDown is a free, open-source (AGPL-3.0), zero-ads, zero-tracking multi-protocol download manager. The download engine is written from scratch in Rust + Tokio; the UI is Flutter. It speaks HTTP/HTTPS, FTP, BitTorrent, eD2K, and HLS/DASH, runs on Windows / macOS / Linux, and ships Chrome / Edge / Firefox extensions that take over browser downloads automatically.

Site: https://fluxdown.zerx.dev · Source: https://github.com/zerx-lab/FluxDown

Why I built this

Internet Download Manager (IDM) is genuinely great — multi-threaded segmentation, resume, browser takeover. But it has some dealbreakers:

It costs money ($24.95 + renewals).
Windows only — nothing for macOS/Linux users.
Closed source — you can't see what it does in the background.
No BitTorrent / magnet / eD2K, and only partial HLS/DASH support.

Meanwhile most "free" download managers are stuffed with ads, bundleware, or quietly phone home. So I wrote my own: a Rust + Tokio engine for speed and memory safety, a Flutter UI for a cross-platform and actually-nice interface — free forever, no ads, no tracking, no account required.

That's FluxDown.

What it does

Here's the head-to-head with IDM:

	FluxDown	IDM
Price	Free forever	$24.95 + renewals
Open source	Yes (AGPL-3.0)	No
Platforms	Windows / macOS / Linux	Windows only
BitTorrent & magnet	Yes	No
eD2K / eMule links	Yes	No
HLS / DASH streaming	Yes	Partial
Dynamic segmentation	Yes	Yes
Browser extension	Chrome / Edge / Firefox	Yes
Ads & tracking	None	—

Highlights:

Up to 10x faster — Rust + Tokio engine with IDM-style runtime dynamic segmentation.
Multi-protocol — HTTP/HTTPS, FTP, BitTorrent (DHT/UPnP/magnet), eD2K (server + Kad DHT source finding, MD4 verification), HLS (AES-decrypt), and DASH — each with a dedicated engine.
Browser integration — a three-layer download interception engine that also sniffs streaming media on the page.
Resume anywhere — every byte tracked in SQLite (WAL); power loss never costs you progress.
Clean & private — zero ads, zero tracking, no account, local-first. Your data never leaves your machine.

The interesting part: architecture

In one sentence: Flutter renders the UI, a zero-FFI pure-Rust engine does the downloading, the two talk over Rinf signals, and the browser extension connects via Native Messaging.

[Browser Extension (WXT)] --Native Messaging--> [fluxdown_nmh]
                                                     │ Named Pipe / Unix socket
[Flutter UI (shadcn_ui)] <--Rinf signals--> [hub — FFI adapter]
                                                     │
                                            [fluxdown_engine]
                            ┌─────────┬───────────┼──────────┬──────────┐
                          HTTP       FTP          BT        eD2K     HLS/DASH
                                                     │
                                                 [SQLite]

The key design decision: the download engine fluxdown_engine is its own crate with zero rinf / zero Dart dependencies. It's decoupled from the host through exactly two traits:

EventSink — the engine reports progress, segment splits, queue changes, etc.
HostSelection — the engine calls back when it needs the host to make a decision (pick an HLS quality, choose which files inside a torrent to download).

The hub crate is just the Rinf FFI adapter: signal plumbing and type conversion, no download logic at all.

Why bother? Because the same engine can now serve completely different hosts: the desktop app (Flutter), a headless web server (axum), a CLI client (aria2c-style), and eventually mobile — each just implements EventSink / HostSelection once, and the download core stays untouched. The repo already ships a headless server and a CLI reusing the exact same engine.

It's textbook dependency inversion / ports-and-adapters: the core domain (downloading) depends on nothing UI- or FFI-specific; the frameworks depend on traits the core defines. If you write Rust, you'll appreciate the boundary.

Smart segmentation: not just "open N threads"

Most download managers' "multithreading" splits the file into N equal parts and fetches them in parallel. The problem: networks aren't uniform. One segment can land on a slow CDN edge and crawl while every other segment finished ages ago — dragging the whole download down.

FluxDown's segmentation does two things:

1. Dynamic segment count (segment_advisor)

Instead of blindly maxing out threads, it tiers by file size, capped by CPU core count:

< 1 MB → 1 segment (multithreading a tiny file just wastes handshakes)
1–10 MB → 4
10–100 MB → 8
100 MB–1 GB → 16
> 1 GB → 32+

2. Runtime split & rescue (segment_coordinator)

Proactive split — a segment is clearly lagging → split its remainder into two and parallelize.
Reactive rescue — a segment stalls → split it so idle threads take over.

Splits are atomic: the child-segment insert and the parent-segment shrink commit in a single transaction, so there's no intermediate state that could re-download or miss bytes. The split is reported through EventSink, so the UI can play that IDM-style segment-visualization animation in real time.

That's what "idle threads rescue slow segments" means — like IDM, but smarter.

Global rate limiting: token bucket

Downloading in the background while still browsing needs a speed cap. FluxDown uses a classic token bucket as a global limiter:

Parameters: rate (bytes/sec) + burst (defaults to rate).
Before each write it consume(bytes) and awaits if tokens run short — non-blocking on the Tokio runtime by construction.

You get precise total-bandwidth control while still allowing short bursts, without the stuttery feel of a naive limiter.

Resume: full SQLite persistence

Tasks, segments, config, and queues all live in SQLite (WAL + foreign keys). Each segment's downloaded_bytes is flushed in 5-second batches, so after a power loss / crash / forced shutdown, it resumes from the exact byte offset — no re-downloading completed parts.

Side note: the persistence layer uses sqlx's Any pool with $N placeholders, so a single SQL codebase runs on both SQLite and PostgreSQL — groundwork for headless-server deployments.

Browser integration: three-layer interception

With the extension installed, FluxDown takes over browser downloads through three lines of defense:

webRequest.onHeadersReceived — cache response headers, detect Content-Disposition / Content-Type.
downloads.onDeterminingFilename — the primary intercept (Chrome MV3), suggest({cancel:true}) cleanly cancels the browser's own download and hands it to FluxDown.
downloads.onCreated + onChanged — fallback intercept, and the only path on Firefox.

Plus: automatic sniffing of video/audio/HLS streams on the page, Alt+Click to temporarily let the browser download directly, and a right-click "Send to FluxDown". All platforms talk to the app over a Native Messaging Host (Named Pipe on Windows, Unix socket on Linux/macOS).

Download & install

Grab the latest build (currently v0.1.52) from GitHub Releases or the site:

Windows (x64 / ARM64): setup.exe installer · portable .zip
macOS (Intel / Apple Silicon): .dmg · portable .tar.gz
Linux (x64): .AppImage · .deb · Arch .pkg.tar.zst · portable .tar.gz

Extensions: Chrome · Edge · Firefox

⚠️ The only official domain is fluxdown.zerx.dev and the source repo is github.com/zerx-lab/FluxDown. Please don't download from anywhere else.

Wrapping up

FluxDown is fully open source (AGPL-3.0). The whole point of writing the engine in Rust was to prove that free software can still be seriously engineered. Stack: Rust + Tokio + Flutter + Rinf. The code is on GitHub — issues and PRs welcome.

Site: https://fluxdown.zerx.dev
Source: https://github.com/zerx-lab/FluxDown

If it saves you time, a GitHub star helps more people find it. Happy to answer anything about the engine internals in the comments.

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.