eMule and eDonkey

It carried peer to peer file sharing across Europe in the years between Napster and BitTorrent, it is still running, and it remains the clearest example of a network that identified files by their contents rather than their names.

How the eDonkey network found a file

The eDonkey network found a file by asking a server which clients held a particular hash. A server here was an index and nothing more: it stored no content, forwarded no data, and kept only a list of which client had which file. A client connected to one server at a time, published the hashes of what it was sharing, and asked that server for sources. The bytes then moved directly between clients, which is why a server needed almost no bandwidth.

The identifier was the important part: every file was hashed in fixed chunks of a little over nine megabytes, the chunk hashes were combined into one file hash in the MD4 family, and that hash was the file's name as far as the network was concerned. Two copies counted as the same file even if one had been renamed beyond recognition, so sources for a download were gathered from dozens of unrelated people at once. The glossary explains hashing, sources and queues separately.

ed2k link

A line of text carrying a file name, an exact size in bytes and the file hash, in the same way a magnet link handed to qBittorrent carries an info hash rather than a file.

Server list

A stored file of server addresses the client tried in turn, and the fragile part of the design: a server was one machine at one address, and a list was only as trustworthy as whoever assembled it.

User hash

A persistent identifier a client generated for itself and attached its credits to, backed by a key challenge so nobody could claim another client's standing.

Low ID

The status a server gave a client it could not connect back to, meaning firewalled: no incoming connections. Two Low ID clients could not reach each other at all.

eMule and eDonkey were never rivals

eMule and eDonkey were never competing products, which is why the comparison confuses people. eDonkey2000 was the original client, written by Jed McCaleb and published by MetaMachine from 2000, and it gave the network its name. eMule arrived two years later as an independent client for the same network, written from scratch and developed by volunteers. The original was discontinued in 2006 after its publisher settled with the recording industry, and the volunteer client is the one still in use.

Kad, the table that outlived the servers

Kad is the table that outlived the servers, and the reason the network did not die with them. Added to eMule around 2004, it implements Kademlia, the distributed hash table design published in 2002 by Petar Maymounkov and David Mazieres, in which every client holds a slice of a shared lookup structure and routes a query toward the slice it needs. Searching Kad means asking the crowd rather than a machine, so there is no address to publish and nothing to seize.

Joining still requires one introduction. A client has to reach at least one node already in the table, either from a stored file of previous contacts or through a peer it is already talking to, so a first connection on a fresh installation sits in a connecting state for a while. A firewalled client joins more slowly, because other nodes cannot open connections to it.

Credits, the queue and why the wait was so long

Credits changed a client's position in somebody else's upload queue, and they explain the network's reputation for patience. Every eMule client kept one global queue of the peers waiting on it, and a peer joined at the back with a queue rank. Credits, held locally and attached to the other party's user hash, moved a peer up that queue in proportion to what it had already uploaded to that client. The scheme was deliberately local: credits were not a currency, could not be transferred, and were worth nothing except to the client that granted them.

The result was that a download of a rare file was not stalled, it was waiting, sometimes for days, and it completed because the hashing made partial progress from many sources safe to combine. Corruption was repaired rather than restarted, through a separate hash tree that fixes a damaged section without discarding the chunk around it.

Running a client on macOS, Linux and a phone

eMule itself runs only on Windows and has never had an official build for any other system. The cross platform route is aMule, an independent free software client for Linux, macOS and the BSD systems that speaks both the server protocol and Kad. Either project publishes its own builds, and a build should come from the project that makes it rather than anywhere else.

On a phone the honest answer is that there is nothing maintained. No current mobile client for this network is in general use on Android or iOS, and the question resolves in practice to BitTorrent clients, the subject of the clients on a phone page. Syncthing sits at the other end of the same space, moving files between a person's own devices with no index and no strangers.

What is left of the server era

What is left of the server era is Kad and a much smaller crowd. Police actions in several European countries during 2006 removed the largest indexing servers, the original client was discontinued the same year, and the network never regained its shape. eMule continued, with development slowed to an occasional release. Its lasting contribution was the idea the later era took for granted: name a file by the hash of its contents, gather it from everybody holding a piece, and keep no list anywhere that anybody can be ordered to switch off.