Features you won't see in eMule: Multiple Server connections - We already talk to all the servers. Creating extra connections is just wasteful and loads the servers. Multicast - This isn't possible. Most ISP's do not support multicasting. Server hopping - We already talk to all the servers. This is just wasteful and loads the servers. Anonymous network (any) - No the edonkey and kad network cannot be changed to be anonymous without redesigning the whole network - which we do not intend. Anonymous network also always suffer from a huge waste of bandwidth (> 50%) which is needed to guarantee anonymity. If you prefer such a project, please take a look at projects like freenet. Webcache - Will not be added for legal (and moral) reasons as it "abuses" the ISPs HTTP-Proxies to store it's data which would lead to a huge increase of load and (unwanted) traffic for those servers if eMule would support it - maybe up to making them unreachable. Support for [any P2P-Network] - there will be no support for additional networks. We will concentrate our work to improve the Ed2K and Kad protocol. Also more networks means more overhead. Features you may or may not see in future eMule versions: (that means its not a promise, just that we are aware of it and consider it as a possibillity, sorted by priority) Improved hash resistance - To ensure eMule stays future-proof the current file integrity check mechnanisms which are based on MD4 will be extended to include MD4+SHA1 (currently already used for AICH). This will avoid any possible future attacks against the hashing mechansims. Autoupdate - There might be a possibility to autoupdate eMule in some way. This would probably still involve user interaction and possibly downloading some file by hand (or at least clicking on a ed2k link), but overall it would be an easier, more secure and more scalable way to update eMule's version. STUN for "UDP open" Kad sources - Sources which have the new (0.49a) UDP open state might also support STUN (on eMule Mods also known as NAT-T) in the future. However we first have to evaluate how many sources with TCP firewalled and UDP open will actually exist in the Kad network and if this is going to work out fine. Full Skin Support - It would be nice if the whole GUI would be customizable, but like many other points here this would be a lot work and its not yet deceided if its worth it IPv6 - We intent to make the Kad (and if possible Server-Ed2k) protocol ready for IPv6. However this is a milestone set for the far future and not for any soon upcoming release, so don't hold your breath. Plug-ins -This isn't a bad idea in general, but a lot coding, which has not high priority at this time. Maybe you will see this in a future version, but not that soon. QoS - Quality of Service Support for routers or QoS drivers Features currently under discussion/revision: (we are currently discussing/considering if this feature should/could be added, there is no decision published yet) Warning: I'm leaving this thread open so that people can comment on changes and mistakes in the list. I will periodically update this list. When I do, I will most likely delete all added posts to keep the thread clean. So if you see your post deleted, don't take offense.