Proposal: optional eMuleBB REST backend support for aMuTorrent (not an issue!)

[itlezy]

Hi, Ciao,
first of all thank you for aMuTorrent. It is a really useful project, and it has been a great base for ED2K/controller work.
I have an eMuleBB fork of aMuTorrent here: https://github.com/emulebb/amutorrent
I maintain eMuleBB, a Windows eMule-compatible client with a native REST API.

It adds eMuleBB as an optional ED2K backend beside the existing aMule support. It is currently used by the eMuleBB RC1 suite, so the code is not just experimental, but I also do not want to send a huge PR without first checking whether this is interesting for upstream, as I also bumped up a few dependencies and workflows.

eMuleBB exposes a native /api/v1 REST API for app status, transfers, searches, shared files, categories, servers, Kad, logs, preferences, and diagnostics. OpenAPI contract: https://emulebb.github.io/emulebb-tooling/rest/REST-API-OPENAPI.yaml

It also has native Arr-facing integration through Torznab-compatible and qBittorrent-compatible adapter surfaces for Radarr/Sonarr-style workflows. Torznab / qBittorrent-compatible adapter docs: https://emulebb.github.io/emulebb-tooling/rest/REST-API-ADAPTERS/

I think some of this could be useful as inspiration for a common ED2K controller approach across eMuleBB and aMule too. If you are interested, please have a look at the fork and let me know whether you would like to collaborate or talk about a clean way to upstream pieces of it.

I believe you are Italian, right ? I am, if there's an easy way to get in touch please let me know, we could have some common design discussions.

No pressure either way. I can keep maintaining the aMuTorrent fork if it does not fit the upstream roadmap, but I wanted to reach out before opening any PR.

Thanks again for building and sharing aMuTorrent.

[got3nks]

Ciao @itlezy, thanks for reaching out and for maintaining eMuleBB.

The good news is you're already past the bar that made the gnutella/shareaza/limewire discussion in #43 a non-starter — eMuleBB has a native REST API, which is the prerequisite aMuTorrent's whole architecture is built around. The integration shape I'd want is the same one outlined here: comment on #43. Same five touch points (Client.js, Manager.js, clientMeta capability block, normalizer, registry wiring), and frontend changes are usually zero if the capabilities are set correctly — the most recent PR (#54, Soulseek/slskd) confirmed that pattern end-to-end with no UI churn.

A few things worth knowing as you map eMuleBB onto this shape:

• aMule and eMuleBB will live as separate client infrastructures, not variants of the same backend. aMule's control plane is the EC protocol over a binary TCP socket (amule-ec-node); eMuleBB's is REST. They happen to share the ED2K network type at the wire level, which the abstraction handles naturally — they'd both report networkType: 'ed2k' to the frontend and share the same networkType-keyed UI affordances (filters, network-scoped stats, etc.) — but their Client.js / Manager.js are independent implementations sitting side-by-side. Same way qBittorrent, rTorrent, Deluge, and Transmission all coexist as separate client infrastructures on networkType: 'bittorrent'.
• Completion detection is the most common bug to watch for in ED2K-class clients. v3.8.4 (server/lib/downloadNormalizer.js:118-128) had to switch from bytes-equality on aMule's SIZE_DONE to gap-status (empty range list = verified+written) because SIZE_DONE counts raw transferred bytes including corrupted pieces that failed hash check — fired false "Download Complete" notifications. eMuleBB will have its own model for this; whatever you map isComplete to in the normalizer, make sure it's the "verified+written" measure, not the "received from peers" measure.
• Shared vs downloading distinction. clientMeta.js has a sharedMeansComplete capability — clients where a hash appearing in the shared-files list is the authoritative "this download finished" signal. aMule sets it; eMuleBB likely should too. There's a paired removeSharedMustDeleteFiles capability that controls *arr cleanup semantics.
• Per-instance, multi-backend. Compound instanceId:hash keys are pervasive across the codebase, so users can run an aMule instance and an eMuleBB instance (or multiple of each) side-by-side in the same UI. Nothing in the manager should assume singleton-per-network-type.
• Torznab / qBit-compat adapters: keep yours. aMuTorrent's adapters were built around aMule's EC-specific data model (hash mapping via hashStore, direct calls into AmuleManager, etc.), so they're not a drop-in for eMuleBB even if it's registered as an ed2k client. And since eMuleBB already exposes Torznab + qBit-compat surfaces natively, there's no need to route through ours — let users point their *arr stack at whichever endpoint they prefer. No need to converge here.

PR shape: a single PR is fine if the diff stays purely additive — new files under server/lib/emulebb/, server/modules/emulebbManager.js, additions to server/lib/clientMeta.js and server/lib/downloadNormalizer.js, plus the registry + setup-wizard hookup. If you find yourself needing to modify existing client code or shared services, that's the signal to split into a small "abstraction tweak" PR first and the additive integration PR after. The slskd PR (#54) is a useful reference for what "additive" looks like at scale — 67 files, mostly net-new, the existing-file edits are all extension points.

Sì, sono italiano. The issue tracker works fine for design discussion (others can read along + future contributors benefit from the searchable history), but if you'd prefer a faster channel let me know what you're on and we can sort something out. Looking forward to seeing what you put together.

[itlezy]

Thanks for the input, as I keep working and stabilizing I'll ensure to always rebase and keep my changes clean and tested. Let's be in touch.