One big problem with my adding new features is that I've been rather busy IRL until recently. That's been cutting down on my coding time.
Another problem, to answer your last question, is that mainline BitTorrent has switched licenses to one based on the Jabber OSL. I want to keep my current MIT/X11 licensing, which means I can't adopt code from their codebase or even look at it, for fear of license contamination. I think it's more important to push the protocol than to try and make money off my codebase. More on that later...
NAT port mapping and NAT traversal: This is problematic with Python, and prior attempts to implement it resulted in problems. For proper NAT traversal the tracker needs to be involved, and I don't have any information on how or whether this has been implemented. Given that information I might be willing to try again.
DHT: Neither mainline BitTorrent nor AFAIK Azureus has published their DHT protocol specifications. Mainline's is based on a MIT/X11-licensed product called Kademlia, but they've made custom modifications to it, and I have no information on those modifications. Azureus' DHT version is disliked by some torrent publishers, since it allows torrents to continue running after they've been withdrawn, and a few have banned clients that implement it.
Peer exchange: This isn't part of the official specification, and is also not implemented in a way mainline recognizes. Future changes to mainline may break it. Given DHT it's also really not necessary.
Encryption: This is scheduled to be incorporated Real Soon Now.
Multi-Torrent GUI: I've been planning this for a while. It's a big job, and has been complicated by other problems. I've been considering moving away from wxPython which has caused problems in the past, but I find the alternative, PyGTK, annoying. The latest version of wxPython has improved though, even if it isn't very RAM-conservative. Consider this to be still in progress.
Broadcatching: Not really usable without the multi-torrent GUI, above.
SOCKS: Very few people have a legitimate purpose for using this, and I'd rather not place a heavy load on some unfortunates trying to run a SOCKS server. I'll consider it though.
Web Remote Control: Also not very useful w/o the multi-torrent GUI.
Torrent Search Engine: I don't think I'll ever incorporate anything like this into my client. Web-based engines are simply more flexible.
Automatic Client Updates: Periodically pinging my server not only potentially overloads my server, but many people will be concerned about maintaining their privacy. I may implement something like this in the future, but don't expect it to be enabled by default.
----
It became clear to me some time ago that a client coded in Python has limited use in being incorporated into other projects, so continuing this codebase under an MIT/X11 license may not be useful. I have two alternatives I can pursue:
(1) Give up MIT/X11 and adopt the BTOSL from mainline BitTorrent. This would allow me to utilize their code, giving me a jump on implementing new features and increasing performance.
(2) Switch codebases to C/C++. This would be a lot of work. I'm actually willing to pay for someone with a decent codebase to release it under MIT/X11, so I can adopt it and make a new version of BitTornado. As above, it would also let me look at the mainline BitTorrent codebase, since I'd need to re-implement any techniques they use and this would isolate me from license contamination.
I'd appreciate feedback on the above two alternatives.