Upload the part once, serve it to everyone
When five peers in your upload queue all want the same chunk of the same file, classic eMule sends it five times. HTTP Cache sends it once.
The uploader watches its queue, and when enough cache-capable peers are waiting on the same whole part, it reads that part, encrypts it, uploads the blob to a cache server, and sends each of those peers a small offer containing the URL and the key. They fetch it over HTTP, in parallel, at whatever speed their own connection allows.
Crucially, the offer replaces the upload slot instead of sharing it. A peer that was holding a slot is politely returned to the waiting list, and the freed slot goes to somebody the cache cannot help. The first peer effectively pays for the upload; everyone after rides along without costing you a slot at all.
What the cache server can see
Nothing useful. Each published chunk gets a fresh AES-256-CBC key and IV, and the key travels only inside the peer-to-peer ED2K offer — it is never sent to the server. The server receives uniform, opaque blobs and is never given the file hash, the part index or the key. A SHA-256 taken over the ciphertext tells a downloader whether the network or the server mangled the blob, as distinct from the uploader having published something wrong, and the ordinary MD4 part hash and AICH recovery remain the final arbiters before a byte reaches your file.
The specification is deliberately candid about the limits: the guarantee is that the server is never given the key, not that the key is a secret. Anyone who can read the ED2K link between the two peers can read the offer, and publishing offers to Kademlia — which is on by default — puts the URL and key into a public DHT record. A client that has verified a part can also relay the same offer onward, which needs no account and no key of its own.
How to enable it
HTTP Cache is off by default and there is no Options page for it yet. A cache is added by opening a one-click ed2k://|httpcache|… link, which the daemon verifies against the server before asking you to confirm; the settings then live under httpCache: in preferences.yml, and the credential is stored encrypted rather than in the clear.