More hard-coded limits? Does every generation need to learn the lesson that no, 640K will not be enough for everybody or for very long? I thought the whole point of this thing called "recorded history" is that these mistakes, such as assuming zero growth in a computer/Internet related area, don't get made twice. Instead they get made over and over and over and over and over and over and over and over and over...

Gnutella must scale or it will die. p2p won't die, but the revenues from Limewire Pro will sure dry up. Make the software perform well at higher scales. In the short term, make Limewire actually share only 1000 files at a time; if you have more shared, it will rotate among them, changing what files it offers to a different thousand every hour or so, with a preference for small files. (Any given shared kb should be shared about as often as any other.) Of course, uploads aren't interrupted as the shared group changes; but newly queued uploads will then be for the new group.

In the longer run Limewire should be able to offer whatever you're sharing all of the time without hassle -- and by 2006, this means it should handle sharing up to 100,000 files on a high-end 32 bit desktop box (4GB RAM, etc.) or a low-end 64-bit machine with maybe 4 or 8GB RAM, and a cable connection.
(These are the figures suggested by extrapolating current trends in memory, bandwidth, and file storage, all of which follow Moore curves.)

As for preferring to share rare files: most of the files I am sharing are rare; indeed most of them are jpgs and jpgs are for some reason difficult to get, often only available from one or two hosts at any given time.

Bunching small files into related groups might help things too, by reducing overhead. Efficiency seems to get low for files under 1M, based on observations. Chain-downloading groups of related files, especially small ones, should carry the same costs as downloading one huge file. Sharing them should carry the same costs as sharing one huge file.

Currently, Limewire scales poorly. It scales poorly handling large numbers of downloads -- queued, not concurrent -- and large numbers of shared files. This must change or Limewire will die. Not a threat, a prediction.

Also, a new layer is needed between ultrapeers and leaves: "middlepeers" which connect leaves to ultrapeers. These would have relatively few leaves and offload much work to ultrapeers, but not have as many connections to ultrapeers or to leaves as ultrapeers do, nor any to other middlepeers. Middlepeers would run OK on bandwidth (cable) that is iffy for ultrapeers. They'd help the network scale by taking burden off ultrapeers; less steep requirements would allow there to be more of them and avoid the disincentives that keep the number of ultrapeers inadequate. Ultrapeers would send a connecting middlepeer the most common query string words they see and the middlepeer would filter that list against the content shared by their handful of leaves. The middlepeer would send the filtered list back to the ultrapeer, and the ultrapeer would broadcast a query to it only if it either used an uncommon query string word or used a common one contained in the filtered list. Thus, broad swathes of queries for commonly desired content these leaves happened not to have would not go to the middlepeer. It would also only have to index the files of a few leaves, not of hundreds.

One more thing I want to see fixed is the icons in search results. The green checked paper icon should always appear by a file you already have, either in the download directory or a shared directory. It should never appear by a file you don't have. Currently, both of these conditions are violated, the first frequently, the second rarely.

And fix this forum so the default "Unregistered" doesn't produce a message that the username is taken! In fact, any string starting with "Unregistered" seems to do that.