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

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:

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:

1. webRequest.onHeadersReceived — cache response headers, detect Content-Disposition / Content-Type.
2. downloads.onDeterminingFilename — the primary intercept (Chrome MV3), suggest({cancel:true}) cleanly cancels the browser's own download and hands it to FluxDown.
3. 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.