This is the home of eMuleBB, the compact public name for eMule broadband edition.

eMuleBB began as a broadband-focused Windows eMule line — eD2K, Kad, rare files, deliberate sharing, long-running sessions — and is growing into a Rust-forward peer-to-peer suite. The active work is the emulebb-rust headless client and Rust-native UI; BitTorrent and cross-network controller work come later.

The organization around it is a practical P2P workshop. We build the clients, the controller, the release and test machinery, the public documentation, and the protocol work that keeps it honest — shipping a stable Windows client today while the multiplatform Rust client takes shape.

The current public release, 0.7.3, is published on GitHub Releases with matching suite bootstrap and aMuTorrent controller packages.

eMuleBB is a privacy-first peer-to-peer suite for people who take file sharing seriously — built on classic eD2K/Kad now, with BitTorrent companion work planned for a later phase.

• eD2K/Kad first. The shipped Windows client is frozen on 0.7.x; active development is the Rust headless client plus native Rust UI.
• VPN-aware by design. The data plane is built to ride your VPN interface, so peer traffic stays on your tunnel. (Fail-closed binding is being hardened across the suite.)
• No central servers or indexers required. Kad and the BitTorrent DHT do the discovery where implemented; the long-term direction is local search without a central service dependency.
• Built for automation. A native REST API plus Torznab and qBittorrent-compatible adapters are used where they belong; Rust currently focuses on stable client behavior and its native UI.

Today: run the Windows client (eMuleBB 0.7.3) with the aMuTorrent controller and the one-line suite installer. Active next: stabilize emulebb-rust headless client behavior and the Rust-native UI. qBittorrentBB and TrackMuleBB are future/parked suite work.

The suite is organized as clients behind shared controller contracts, so off-the-shelf tools drive every part without flattening native protocol behavior.

• eMuleBB — the C++ MFC Windows desktop client shipped on the frozen 0.7.3/0.7.x line.
• emulebb-rust — the headless, multiplatform eD2K/Kad core; the forward direction of the eMule-family work, paired with a Rust-native UI.
• qBittorrentBB — the BitTorrent-side companion: a full BT client with a DHT harvester and a Torznab index. Future work.
• aMuTorrent — the cross-network web-UI controller that manages the eD2K and BitTorrent clients together for the shipped 0.7.3 Windows suite.

The target architecture keeps clients behind automatable contracts while preserving native protocol behavior. Data-plane traffic is designed to egress a fail-closed VPN tunnel. The active implementation lane is Rust eD2K/Kad; the BitTorrent companion and future controller layers are staged after that.

flowchart LR
    Amu["aMuTorrent<br/>web UI · cross-network controller"]
    Prowlarr["Prowlarr<br/>indexer federation"]
    Arr["Radarr · Sonarr<br/>Lidarr · Whisparr"]

    subgraph Cores["eD2K / Kad cores — shared /api/v1"]
        direction TB
        Cpp["eMuleBB<br/>C++ MFC desktop<br/>frozen 0.7.x"]
        Rust["emulebb-rust<br/>headless + native UI<br/>active forward client"]
    end

    Qbbb["qBittorrentBB<br/>BitTorrent client<br/>future companion"]

    Ed2k[("eD2K / Kad")]
    Bt[("BitTorrent<br/>DHT · swarms")]
    Vpn{{"VPN — fail-closed data plane"}}

    Amu -->|"REST /api/v1"| Cores
    Amu -->|"qBit WebUI API"| Qbbb
    Arr -->|"qBit download client"| Cores
    Arr -->|"qBit download client"| Qbbb
    Prowlarr -->|"Torznab"| Cores
    Prowlarr -->|"Torznab"| Qbbb
    Prowlarr -. indexer sync .-> Arr

    Cores --> Vpn
    Qbbb --> Vpn
    Vpn --> Ed2k
    Vpn --> Bt

    style Rust fill:#dea584,stroke:#8b4513
    style Qbbb fill:#cfe8ff,stroke:#1c6fb4

This is the target suite architecture. Today, the stable public line is the MFC 0.7.3 Windows suite. Active forward work is emulebb-rust headless client stabilization and Rust-native UI. qBittorrentBB and TrackMuleBB are future work.

Stable 0.7.3 is published on GitHub Releases. Choose one install path:

Use this path when you only want the eMuleBB desktop app.

1. Open emulebb-v0.7.3.
2. Download emulebb-0.7.3-x64.zip.
3. Extract the ZIP into a new version-specific folder, for example C:\Apps\eMuleBB\0.7.3.
4. Run emulebb.exe.

Keep each version in its own application folder. Use a backed-up or disposable profile for first launch and support testing.

Use this path when you want eMuleBB plus aMuTorrent, Prowlarr, Radarr, and Sonarr integration out of the box.

irm https://emulebb.github.io/install.ps1 | iex

The Pages install.ps1 is a thin wrapper that resolves the latest published release and forwards to its Bootstrap-eMuleBBSuite.ps1. The bootstrapper then downloads and verifies the matching release package, extracts the suite installer, resolves the matching aMuTorrent package, and starts the install flow. Advanced options and verification details are in the Setup guide.

Stable release builds and packaging happen in GitHub Actions and are published through GitHub Releases. The 0.7.3 release includes ZIPs, manifests, SHA-256 evidence, SPDX SBOMs, diagnostics packages, the suite bootstrapper, and the bootstrapper SHA-256 asset. The bootstrapper verifies package hashes from the release manifests before installing.

MFC 0.7.3 is frozen except for critical maintenance and non-behavior-expanding diagnostics/instrumentation. Current forward development is focused on emulebb-rust: the headless client, protocol stability, safety gates, persistence, REST correctness, and Rust-native UI. qBittorrentBB remains future companion work; TrackMuleBB is parked until that companion work progresses.

Use the published stable packages if you want to help shake out real Windows profiles, large libraries, controller/API workflows, package contents, startup/shutdown behavior, and public-network regressions.

Use a disposable or backed-up profile when testing a fresh package. Report crashes, freezes, broken packages, UI regressions, REST/controller problems, and repeatable live-network issues in emulebb/issues.

Useful reports include the package name, architecture, Windows version, profile type, exact launch command, repro steps, logs, diagnostic snapshots, and dumps for crashes, hangs, or memory-growth cases.

The eMuleBB desktop client keeps the familiar workflow at the center: servers, Kad search, shared files, upload queues, categories, known clients, and long-running control, plus broadband-aware upload policy, safer large-library operation, authenticated REST automation, and release evidence. It is the stable entry point to the suite and is maintained on the 0.7.x line.

emulebb-rust is where the eD2K/Kad client is headed: a headless, multiplatform core plus Rust-native UI. This is the strategic direction of the suite, not a side experiment. In development.

qBittorrentBB is planned to bring the suite onto BitTorrent: a full client with a DHT harvester, a local searchable index, and a Torznab endpoint. Future work.

The aMuTorrent fork ships with the frozen eMuleBB 0.7.3 Windows line and validates controller workflows for that release family. It is not the forward controller for new Rust work.

We provide Windows build and validation work for aMule and MiniUPnP/miniupnpc — ecosystem builds for users who want these tools in the same Windows P2P workflow.

goed2k-server is a deterministic eD2K server used for tests and parity work. p2p-overlord is a separate, server-oriented product line in the family — it can share contracts and infrastructure but is not part of the suite.

The suite is built as tested products, not patched source trees. Public claims stay tied to evidence across the family: CI on every active repo (the rust core builds and tests on Windows, Linux, and macOS), native and harness tests, REST contracts, live eD2K/Kad scenarios, controller lanes, package provenance, GitHub Actions release packaging, SBOMs, SHA-256 hashes, manifests, and explicit operator gates. A tracked-content guard keeps secrets and private data out of the repositories.

Performance and behavior are treated the same way. Claims are tied to concrete operating surfaces: upload-slot policy, queue/source limits, socket and file buffers, startup behavior, large shared libraries, long paths, and controller responsiveness.

The result is a focused P2P organization: conservative where compatibility matters, aggressive about validation, and serious about making eD2K/Kad and BitTorrent usable, automatable, and honest on modern systems.

Clients and core

• emulebb-rust - multiplatform eD2K/Kad headless client + Rust-native UI (active forward core)
• emulebb - eMuleBB Windows client (frozen 0.7.x line)
• qbittorrentbb - future BitTorrent companion
• amutorrent - 0.7.3 Windows-suite controller

Infrastructure

• emulebb-build - build, validation, and release orchestration
• emulebb-build-tests - native, Python, UI, REST, and live E2E tests
• emulebb-tooling - roadmap, backlog, policy, audits, and reference docs
• emulebb-setup - reproducible workspace setup

Service / lab

• goed2k-server - deterministic eD2K server for tests and parity work

Separate product family (shares contracts/infrastructure, not part of the suite)

• p2p-overlord-agents and p2p-overlord-be - server-oriented P2P line

• aMule - Windows build and validation track for aMule users
• emulebb-miniupnp - Windows build and validation track for MiniUPnP/miniupnpc

• eMuleBB is a peer-to-peer suite; the eMuleBB Windows client is its stable entry point.
• Keep stock eD2K/Kad protocol compatibility as the default.
• The Windows MFC client is maintained on 0.7.x; the multiplatform forward core is emulebb-rust.
• Treat REST, Torznab, and controller support as shared product features across clients.
• Make packages, build evidence, and release gates inspectable.
• Keep lab and separate-family work visible, useful, and clearly labeled.
• Sell the expertise by proving the work.