A modern BitTorrent client. No frameworks needed. Binary target: <3 MB.
Status: Work in progress.
Frontend runs against a standard transmission-daemon. Bugs exist; some features are unfinished and regressions may occur.
Custom single-binary backend is under active development.
I grew up with torrent clients that were ~160 KB — small, fast, and engineered with real hardware limits in mind. That era is gone. Today even a simple tray application wastes memory it has no reason to touch, and I’m not fine with that. So I decided to do something about it.
My first idea was a pure C, bare-metal Windows client — no external libraries, just raw WinAPI. The UI was unacceptable, so I abandoned that approach. Later I realized that every modern system already ships with a fully optimized, GPU-accelerated rendering engine: the web browser. Used on demand, it delivers better visuals, less UI code, and zero idle UI memory.
This project exists to bring back what made the classics great: a lean core, a tiny binary, and a UI that feels modern — without abandoning engineering discipline.
This is how TinyTorrent was born.
Instead of dragging UI toolkits into the binary, TinyTorrent is split cleanly:
-
Native Tray Daemon:
A minimal C/C++ executable responsible for lifecycle, tray controls (pause/resume/open GUI), and the torrent engine. Always running. No UI. -
On-Demand GUI:
A browser-based UI launched only when requested (Chrome, Edge, Firefox, etc.).
When closed, no UI process exists.
Zero GUI memory when unused.
Exactly how it should be.
- Zero GUI memory when unused — the interface is launched on demand in an external browser.
- Glass Monolith UI — Tailwind v4 + HeroUI + blur + depth for a stealth aesthetic.
- Workspace Components
- File Explorer Tree: Nested, accordion-style file selection with priority toggling.
- Visualizers: Real-time speed graphs, Disk Space Gauge, and peer maps.
- Kinetic Motion — Framer Motion used for structural transitions, not decoration.
TinyTorrent is not tied to a single engine.
- Strict RPC boundary: The UI talks to a well-defined API.
- Adapter Pattern:
- Transmission Adapter: Uses standard Transmission RPC.
- Libtorrent Adapter: Planned C++ wrapper around
libtorrent-rasterbar.
- Queue Management: Reorder torrents, move to top/bottom, drag-and-drop.
- Deep Interaction: Shift-click ranges, Ctrl-click toggles, full keyboard navigation.
- Exact Typing: No
any. RPC schema is strictly typed and normalized.
TinyTorrent is licensed under MPL-2.0 for the code because I want this project to stay true to the spirit that in my eyes made uTorrent great (small, practical, user-respecting), and to avoid the “uTorrent way” where a great tool drifts into a closed, adware/bloat-heavy direction.
MPL-2.0 is a pragmatic middle ground: it keeps the project open and encourages improvements to flow back when code is modified and redistributed, while still being compatible with real-world integration.
Notes:
- Repository license texts live at the repo root:
LICENSE(MPL-2.0) andAPACHE-2.0. - Protocol/spec docs are Apache-2.0; branding assets are proprietary/trademarked (see the notices adjacent to those assets).
TinyTorrent/
├── frontend/ # React 19 HUD, Vite build, Tailwind v4, HeroUI, Framer Motion
├── backend/ # C/C++ tray daemon + torrent engine
└── README.md # You are here
- React 19
- TypeScript
- TailwindCSS v4
- HeroUI
- Framer Motion
- Vite
- C / C++20 (no exceptions, no RTTI)
- libtransmission
- Mongoose (embedded web server)
- Static asset bundling for optional embedded UI in the future
- Node.js 20+
- Development: You can run the frontend against a standard
transmission-daemon(port 9091).
cd frontend
npm install
npm run devNote: The root and backend directories are intentionally TypeScript/Node-free. All
npm/npxwork happens insidefrontend/so the native build tree stays clean. SeeAGENTS.mdfor the full rule set.
From a fresh clone, you can generate a .sln using Meson’s Visual Studio backend via the PowerShell helper:
cd backend
./make.ps1 vs DebugThis produces the solution at:
backend/build_vs/debug/tinytorrent-daemon.sln
For a release solution:
cd backend
./make.ps1 vs ReleaseOutput:
backend/build_vs/release/tinytorrent-daemon.sln
Notes:
- The script also writes Visual Studio
.vcxproj.userdebug settings so the debugger can find required runtime DLLs (vcpkg deps and ASan runtime in Debug). - If you change toolsets / vcpkg triplets / upgrade Visual Studio, rerun
./make.ps1 vs Debugto regenerate those settings.
Today, the only backend that is working reliably end-to-end is a standard transmission-daemon.
In parallel, we’re building a TinyTorrent-native daemon (currently WIP) built around libtorrent (C++). This path is the main reason our current executable misses the original size target: libtorrent (and the surrounding C++ runtime + dependencies) is heavier than a minimal Transmission-based setup.
Why go this way anyway? Because the Transmission-based setup has had reliability issues for our use case — most notably around starting magnet downloads immediately (and, in some cases, entering unrecoverable wait states). The libtorrent-based daemon is intended to solve those problems while keeping a clean RPC boundary.
Current priorities are correctness and stability first; optimization comes later. We may be able to shave some size off, but a dramatic drop is unlikely while we stay on libtorrent + C++.
The ~1 MB size target is an explicit initial goal derived from an educated estimate. Although the estimate was made before fully evaluating the scope of a full torrent daemon, Transmission’s final executable indicates the target remains realistic. The primary priority is correct, stable operation and interoperability in today’s torrent ecosystem; binary size optimization remains a subsequent objective, with the size goal still in scope.
Longer-term (time permitting): once the libtorrent-based daemon is solid, we may take on Transmission itself and apply a similar approach there. There’s also an aspirational “classic uTorrent” goal: potentially rewriting more of the stack in C with an aggressive size target (roughly 1–1.5 MB UPX-packed), primarily as an engineering challenge.
For the full protocol and engine details, see:
docs/TinyTorrent_RPC_Extended.mddocs/TinyTorrent_Specification.md
Defined in AGENTS.md (root). That document also makes the rule explicit: only frontend/ owns TypeScript and Node tooling, keeping the rest of the tree purely native.
- Speed
- Density
- One Responsibility
- Exact Typing
- No entropy in the codebase
Pull requests must follow the Visual Excellence Directive:
- Modern and consistent components
- Framer Motion for structural transitions
- Strict TypeScript
- No regressions in performance
TinyTorrent — Simple. Fast. Beautiful. On-Demand.