gosh-dl
A fast, embeddable download engine for Rust applications. Supports HTTP/HTTPS with multi-connection acceleration and full BitTorrent protocol including DHT, PEX, encryption, and WebSeeds.
Why gosh-dl?
gosh-dl brings download functionality directly into your Rust application as a native library, eliminating the complexity of managing external processes, parsing JSON-RPC responses, or bundling platform-specific binaries. Modern applications demand seamless integration, and gosh-dl delivers exactly that; async function calls that feel natural in your codebase, compile-time type safety that catches errors before runtime, and shared memory that keeps your application lightweight and responsive.
Whether you're building a media application that needs BitTorrent with streaming support, a package manager requiring resilient HTTP downloads with checksums and mirrors, or any software that moves files across the network, gosh-dl provides the complete feature set you need. Multi-connection acceleration splits large downloads across parallel connections for maximum throughput. Automatic resume with ETag validation ensures interrupted transfers pick up exactly where they left off. Full BitTorrent support includes DHT for trackerless operation, peer exchange for efficient swarm discovery, and protocol encryption for privacy.
The engine handles the complexity of segmented downloads, tracker communication, DHT peer discovery, and connection encryption while exposing a clean, intuitive API that integrates naturally with Tokio-based applications. Priority queues let you control which downloads matter most, bandwidth scheduling adapts to time-of-day constraints, and SQLite persistence ensures nothing is lost across restarts.
A standalone CLI application is coming soon for those who need command-line access to these capabilities.
Features
Tested & Production-Ready
| Feature | Details |
|---|---|
| Multi-connection HTTP/HTTPS | Up to 16 parallel connections per download |
| Content-Disposition detection | Automatic filename from server headers |
| Custom headers | User-Agent, Referer, cookies, arbitrary headers |
| Checksum verification | MD5, SHA-1, SHA-256 |
| Concurrent download management | Priority queue (Critical/High/Normal/Low) |
| Pause / resume / cancel | Full lifecycle control |
| Event system | Broadcast channels for progress, state changes |
| Global statistics | Active count, aggregate speeds |
| SQLite persistence | WAL mode, schema versioning, crash recovery |
Tested BitTorrent Core
| Feature | BEP | Details |
|---|---|---|
| .torrent parsing | 3 | Single-file and multi-file |
| Magnet URI | 9 | Metadata fetching from peers |
| Multi-peer downloading | 3 | Piece selection, block pipelining |
| Piece hash verification | 3 | SHA-1 per piece |
| HTTP & UDP trackers | 3, 15 | Announce, scrape |
| Sequential download | — | For streaming playback |
| Torrent crash recovery | — | Resume from SQLite-stored torrent data |
| IPv6 tracker peers | 7 | Compact peers6 parsing |
Implemented, Lightly Tested
| Feature | BEP | Notes |
|---|---|---|
| DHT peer discovery | 5 | Works, disabled in CI tests |
| Peer Exchange (PEX) | 11 | Implemented, disabled in CI tests |
| Local Peer Discovery | 14 | Implemented, disabled in CI tests |
| Message Stream Encryption | MSE/PE | RC4 + DH key exchange, unit tests only |
| WebSeeds | 17, 19 | Hoffman + GetRight, including cross-file pieces |
| uTP transport | 29 | LEDBAT congestion control, wired into peer connections (opt-in) |
| HTTP resume | — | ETag/Last-Modified validation |
| Mirror/failover | — | Automatic failover to alternate URLs |
| Private torrent handling | 27 | Disables DHT/PEX/LPD |
| Choking algorithm | — | Unchoke rotation, optimistic unchoking |
Planned / Stub
| Feature | Notes |
|---|---|
| DHT IPv6 | Depends on upstream mainline crate |
| Proxy support | Config field exists, not tested |
| Bandwidth scheduling | Code exists, not tested |
| File preallocation | Config field exists, not tested |
Quick Start
Add to your Cargo.toml:
[]
= "0.1"
= { = "1", = ["full"] }
Basic usage:
use ;
async
API Overview
All public types are available at the crate root via re-exports. For explicit imports, use gosh_dl::protocol:
use ;
Download Management
// Add downloads
let http_id = engine.add_http.await?;
let torrent_id = engine.add_torrent.await?;
let magnet_id = engine.add_magnet.await?;
// Control
engine.pause.await?;
engine.resume.await?;
engine.cancel.await?;
// Priority
engine.set_priority?;
// Status
let status = engine.status;
let all = engine.list;
let active = engine.active;
let waiting = engine.waiting;
let stopped = engine.stopped;
let stats = engine.global_stats;
Download Options
use ;
let options = DownloadOptions ;
Events
use DownloadEvent;
let mut events = engine.subscribe;
while let Ok = events.recv.await
Configuration
use ;
use PathBuf;
let config = EngineConfig ;
Bandwidth Scheduling
use ;
// Limit bandwidth during work hours (Mon-Fri, 9am-5pm)
let work_hours = weekdays;
let config = default
.add_schedule_rule;
Building
See technical_spec.md for architecture details.
Why an API Instead of RPC?
Traditional download managers like aria2 use JSON-RPC for external communication. This works well for standalone tools, but creates friction when embedding download functionality into applications:
With RPC (aria2 approach):
Your App → Serialize JSON → HTTP/WebSocket → aria2 Process → Parse JSON → Execute
← Parse JSON ← HTTP/WebSocket ← ← Serialize JSON ← Result
With native API (gosh-dl approach):
Your App → engine.add_http(url, opts) → Result
Benefits of the API Approach
- Zero serialization overhead: No JSON encoding/decoding on every call. Function arguments pass directly through memory.
- Compile-time guarantees: The Rust compiler catches type mismatches, missing parameters, and invalid states before your code runs. RPC errors only surface at runtime.
- Native error handling: Use
?operator, pattern matching onResult, and standard Rust error propagation. No parsing error strings from JSON responses. - No process coordination: No need to spawn aria2, monitor if it crashed, restart it, or manage its lifecycle. The engine lives in your process.
- Shared memory space: Progress callbacks, event streams, and status queries happen in-process. No IPC latency or message queue bottlenecks.
- Single deployment artifact: Ship one binary. No bundling platform-specific aria2 executables or dealing with PATH issues.
- IDE integration: Autocomplete, go-to-definition, inline docs all work. RPC calls are opaque strings to your editor.
Comparison with aria2
gosh-dl was designed as a native Rust alternative to aria2, the popular C++ download utility. While aria2 is excellent as a standalone tool, embedding it in applications requires spawning an external process and communicating via JSON-RPC.
| Aspect | aria2 | gosh-dl |
|---|---|---|
| Integration | External process + JSON-RPC | Native library calls |
| Deployment | Bundle platform binaries | Single Rust crate |
| Type Safety | JSON strings | Rust types with compile-time checks |
| Error Handling | Parse JSON responses | Native Result<T, E> |
| Process Management | Handle lifecycle, crashes | None required |
| Memory | Separate process | Shared with your app |
Migration Guide
| aria2 RPC | gosh-dl |
|---|---|
aria2.addUri(urls) |
engine.add_http(url, opts) |
aria2.addTorrent(torrent) |
engine.add_torrent(bytes, opts) |
aria2.pause(gid) |
engine.pause(id) |
aria2.unpause(gid) |
engine.resume(id) |
aria2.remove(gid) |
engine.cancel(id, false) |
aria2.tellStatus(gid) |
engine.status(id) |
aria2.tellActive() |
engine.active() |
aria2.tellWaiting() |
engine.waiting() |
aria2.tellStopped() |
engine.stopped() |
aria2.getGlobalStat() |
engine.global_stats() |
aria2.changeOption(gid, {priority}) |
engine.set_priority(id, priority) |
FAQ
Why not just use aria2?
aria2 is a battle-tested download utility and remains an excellent choice for many use cases. Use aria2 if:
- You need a standalone command-line tool
- You're scripting downloads from shell or other languages
- You want a mature, widely-deployed solution with years of production use
Use gosh-dl if:
- You're building a Rust application and want download functionality as a library
- You need tight integration without IPC overhead
- You want compile-time type safety and native async/await
- You prefer not to bundle and manage external binaries
- You need direct access to download state without polling JSON-RPC
Both tools support similar feature sets (multi-connection HTTP, BitTorrent, DHT, etc.). The difference is architectural: aria2 is a standalone process you communicate with, gosh-dl is a library you call directly.
Is there a CLI?
A standalone gosh-dl CLI application is now available and can be found here: gosh-dl-cli. It allows command-line access to all engine features for users who prefer terminal workflows or need to script downloads without writing Rust code.
What Rust version is required?
gosh-dl requires Rust 1.85+ for async trait support.
Does gosh-dl work on Windows?
Yes. gosh-dl supports Linux, macOS, and Windows. Platform-specific code handles differences in file handling, network interfaces, and path conventions.
License
MIT License - see LICENSE for details.