From PhexWiki

Why we don't want multiple p2p-networks in Phex

There are quite many multi-protocol clients out there, but we at the Phex team think, that implementing several different p2p-networks is like curing the symptoms instead of thinking about the reasons.

Naturally a p2p-network lives from its sharers, and some p2p-networks are used by fans of one type of content, while others have different users. So, a short-term approach to this problem is to implement all those p2p-networks into one client.

But using this approach means, that effort is being split among several networks instead of putting all effort into improving one single network.

That means that you'll be stuck in the end with several suboptimal networks, which each consume network bandwidth and CPU-time instead of one network which really works and constantly improves.

So we should rather think about the reason: Why do people choose a certain network over Gnutella, and how can we change that?

Our decision to avoid multiple networks stems from the firm belief, that Gnutella is the best approach towards a scaleable, tag-based searcheable p2p-network.

We believe in the "one tool for one task" philosophy, and for the task of searching for a file by its name or by word or tag based metadata, Gnutella is the best tool out there, and it constantly improves.

For other tasks we have, for instance, the download mesh, which implements a BitTorrent like decentral source-exchange network around each actively downloaded or uploaded file, the GWebCaches for finding the first hosts we connect to, UDP-host-caches to exchange information about active hosts in the network, and soon a dht for searching by sha1-hash.

But all these have their own field, and they work flawlessly together without "competing" for resources in one and the same field, as it happens in multinetwork clients.

And in the long term we hope, that this will make Gnutella the major tool for distributing, locating and retrieving content in the internet.