ztorrent-core is the embeddable engine behind ztorrent, a Transmission-style BitTorrent client. It owns the session model (torrents, files, peers, trackers, labels), the policy Transmission applies above the wire — the download/seed queue, ratio and idle seeding limits, the alt-speed (turtle) scheduler, blocklists, watch folders and auto-assign groups — plus .torrent parse/create, magnet handling and a Transmission RPC compatibility layer over an HTTP listener that can serve TLS and stream a partial file over byte ranges, BEP 16 super-seeding, preallocation, weighted bandwidth allocation, saved views, RSS auto-download rules and an SMTP client that mails on completion, and exposes all of them through one command surface (Engine::invoke), so every host drives identical behaviour. The peer wire protocol itself is librqbit, behind the default net feature. The crate builds as rlib for native Rust/Tauri hosts and as staticlib/cdylib for non-Rust hosts over a C ABI. This project is in active development; current Transmission coverage is 96.5% of an enumerated feature set.
Embeddable
One command surface — Engine::invoke(cmd, args_json) — drives every host identically: native Rust, a Tauri command, or a C/C++ host over the FFI (ztr_invoke).
Byte-exact formats
The bencode decoder keeps every value’s source span, so a torrent’s info-hash is SHA-1 over the original info bytes rather than a re-encode — the difference between a handshake peers accept and one they drop.
Vendored Wire Layer
The BitTorrent protocol comes from a fork of librqbit carried as a submodule. Where upstream had no knob — a configurable queue order, a peer-exchange switch — the fork adds one, rather than the engine faking the behaviour above it.
Feature-Gated Net
The net feature carries the BitTorrent session. Build --no-default-features for a pure core that compiles in headless CI with zero sockets; the model, the queue/seeding/scheduler policy and the .torrent/magnet formats still work.
Honest Status
The port report is hand-assessed and audited: a capability whose engine works but whose UI is incomplete is partial, and the generator can only flag or downgrade a row, never upgrade one.
Quick start
use ztorrent_core::Engine;
use serde_json::json;
let mut engine = Engine::new()?;
// One dotted command surface for every host.
engine.invoke("session.start", &json!({}))?;
engine.invoke("torrent.add", &json!({ "magnet": "magnet:?xt=urn:btih:…" }))?;
let rows = engine.invoke("torrent.list", &json!({}))?;
// The policy layer is callable on its own — no session required.
engine.invoke("scheduler.evaluate", &json!({ "utc_offset": -18000 }))?;
engine.invoke("seeding.check", &json!({}))?;
Surfaces
Depend on the rlib and call Engine directly, or go through Engine::invoke with JSON for parity across hosts. Enable the tauri feature to mount the engine as Tauri app commands (ztr_invoke + setup), with events emitted on ztr-event. Link the staticlib/cdylib and call ztr_invoke from a C ABI host. A Transmission remote can drive the engine through rpc.request, which answers in Transmission’s own envelope. Asynchronous facts (torrent added, download complete, a seeding limit firing) are pushed to the host through an installed event sink.
The mountable GUI
webui/ztorrent.{js,css} is the client view every host mounts: toolbar, status-filter sidebar with live counts, a sortable and resizable torrent table with fuzzy filtering, and a details pane (Info · Files · Peers · Trackers · Options). It feeds the host’s single command palette and settings panel instead of binding a global key of its own, so an embed reads as part of its host rather than a competing mini-app.
Where it goes next
See the engineering report for the module map, dependency footprint, FFI surface and test status, the port report for feature-by-feature Transmission coverage, the cross-client report for what every other major client does, and the MenkeTechnologiesMeta umbrella for the wider stack this engine plugs into.