[Smart "on request" tth]

this idea is surely very good theoritically, but the problem is that some people do searches by TTH (auto-searches, for instance). since ApexDC++ won't be able to answer to some of these TTH searches eventhough you do have the file in your share (but it's not yet hashed), i doubt hub operators would accept this.

[Search Spy]

ive niticed that in apex the search spy doesnt show who made the search.

i've not tried it in ApexDC++, but i guess there must be a column like "IP". actually, when receiving search requests, you only receive IPs, and ApexDC++ can't have an easy way to match this IP to someone's nick. however, once you have established a connection with this IP (i mean, download his file list for instance), ApexDC++ can then know this user's IP. try it and see if it works, otherwise IIRC it needs few work in ClientManager.

[Speed limit per IP]

if you wish to implement this, i can help, i did it some time ago... (per IP, or per nick, users usually prefer when it's per nick, but this is a bit more complicated to do.)

[A bigger chat message box]

this can seem to be difficult at first sight, but it can be very easily achieved with the current code; look at this line in HubFrame.cpp's UpdateLayout(): int h = WinUtil::fontHeight + 4;

change it to something like int h = WinUtil::fontHeight * numberOfLines + 4; and call UpdateLayout() with a new numberOfLines any time the message box's content changes.

then, adding options for the min/max number of lines, and such stuff is just a matter of time, nothing to really think about there...

[Connection between two passive users?]

these people have also thought about it, and there is a very good explanation of something that could work: http://midcom-p2p.sourceforge.net/