Intervista agli sviluppatori di NeoLoader

[THOR]

 English version (part 1)            English version (part 2)    

 Versione italiana (parte 1)        Versione italiana (parte 2)

It is a real pleasure for us to present the interview that David Xanatos and Ekliptor, developers of the new client called NeoLoader, have kindly issued to Emule-Mods.it
We thank them for their kindness and wish them to continue this excellent job with NeoLoader.



English version (part 1)


1) Hi David, can you briefly introduce yourself for our users that still don't know you?

David Xanatos:
I'm one of the founding members of the  Austrian Pirate Party; I Work as a Physicist at a university by day, and develop file sharing applications by night.


2) Can you describe the client NeoLoader and what inspired you to create it?

David Xanatos:
The initial concept behind NeoLoader was to bring together the advantages of P2P file-sharing with those of Hoster based file-sharing, by using a Kademlia Network.

We wanted to create the first client that would provide a global Keyword search for File Hoster Downloads. This way a user wouldn't anymore have to look on various link sites for files he wants, but could instead just enter a search therm in Neo and start downloading the files right away. Also we wanted to solve the major problem of links to "interesting" files usually disappearing quite fast and so link sited sometimes having most of their offerings down until someone complains and the files get re uploaded manually. Having a client for uploading files would allow the releasers to easily monitor the on line status of their files and with almost no afford trigger a re-upload each time some files get pulled.
This feature could even be extended to involve users that downloaded the file in automatically re-uploading it if needed, but for security reasons this would ne not on default.
To make the system even more robust we decided from the start to add anonymous P2P functionality so that even if a particular file wouldn't be available on Hosters anymore a user could still download it from other users that got the file in the past and still have it. Since the P2P based sharing would be fully anonymous this should not bring any new unexpected threats to the average well protected Hoster user.
And since we ware at it we decided also to add support for other file-sharing networks like bt and ed2k, where the sharing would be disabled by default so that if a file would be needer available on Hosters nor in the anonymous NeoShare Network, our client could offer the user to download it from bt or ed2k, and of cause warn him that doing so would result in the downloaded file being also uploaded into the particular insecure networks, so that he could do a informed decision and would also be offered an option to setup a VPN account to mitigate the risks of using open unanonymized an P2P Network.

To sum it up the goal was to provide a Novel FileSharing client that gives the average unskilled users the best download experience possible and at the same time protect his privacy as good as possible.


3) Can you introduce the client's main features and some anticipation about possible news?

David Xanatos & Ekliptor:
NeoLoader is capable of combining any common means of file-sharing together, this is achieved by using an own next generation Kademlia Network that indexes all files the clients encounter and provides for hash and link associations. No mater where the file was downloaded from it is being hashed using all relevant schemes and the data are published into the Kad Network.
This core functionality enables a multitude of novel features. It provides for a global keyword based file search capability for all kinds of downloads, meaning it allows for eMule style searches for torrents or Hoster downloads. This feature is unprecedented for this 2 popular means of file-sharing, in the past users had to rely on link or torrent search engines which often provided outdated informations.
The Hash to Hash associations allow to download a file from multiple different networks at the same time, for example when given a ed2k link the client can retrieve corresponding Torrent InfoHashes and download the file with superior speed from the torrent Networks.
NeoLoader also revolutionizes the way Hoster link sites can operate instead of providing dumb link lists or static encrypted link containers, they can use Neo Links that identifies the files by its unique hash like in P2P  systems and a Neo User can than Retrieve up to date download links from the Kad Network. Using a P2P style part splitting allows also to interchange parts uploaded by different releasers so that the file availability is greatly improved. Also this  mechanism allows users without payed premium accounts to download  the files at acceptable speeds by being able to retrieve enough  different sources that they could download each part for free from a  different Hoster without having to wait.
Files that have been uploaded to hosters using the new Neo Scheme can even interchange parts with P2P downloads, so that it is possible to download a file from ed2k, bt and Hosters all at the same time.
A feature basing on this capability is a File Hoster based automatic part cache mechanism, so that parts that are needed by some P2P clients advertising the support for this feature will be uploaded to a File Hoster automatically and than the other clients can download it form there. This effectively can multiply the available bandwidth in the network by orders of magnitude.
NeoLoader also features a fully anonymous P2P file sharing system so that users can safely download files that are not longer available on File Hosters. The system is called NeoShare and through a combination of different techniques that allow to adjust the level of anonymity exactly to the thread level encountered by the user, it provides for a better network performance than other Anonymous file sharing networks.

NeoLoaders support for all types of File sharing schemes and networks is state of the art. We support all relevant Bittorent protocol extensions and have a full protocol compatibility to eMule, and are pioneering new protocol extensions for ed2k like NAT-T, IPv6, and others.
Our Hoster downloads engine minimizes the afford needed to develop scripts to handle Hoster and link sites, by providing a fully functional Java script enabled head less browser, many sides can be simply operated by triggering events on DOM-Tree elements, no more need to emulate the sites AJAX code by hand.

In future we will work further on the NeoKad improving the performance and reliability for anonymous tunnels. We intent also to rework the global file search system to include some rating schemes, such that the search results NeoKad provides will have a quality comparable to the quality of moderated link/torrent sites.


4) Why a user should find NeoLoader better than other clients?

David Xanatos & Ekliptor:
Global keyword search capability for BitTorrent Downloads
Global keyword search capability for Hoster Links
Part interchangeability across arbitrary File Sharing systems
A novel P2P style Link format for Hoster downloads
A fully anonymous yet fast P2P file sharing scheme (NeoShare)
State of the art support for all relevant types of File sharing schemes


5a) Are you going to add the ed2k server support in future?

David Xanatos & Ekliptor:
When I started implementing ed2k support into NeoLoader is seamed clear that there will never be any server support, as there was no up to date server software available and there are some good arguments against using central points in File-sharing topology's. But this year in February petermrg announced on EP (http://forum.emule-project.net/index.php?showtopic=156155) his intent to develop a up to date server software which he did in the following months, with some help from me.

Now the old arguments against using servers are still valid, but you can always argue about the relevance certain flaws have.
One problem with servers is that they are a central attack target for entities that don't like free unrestricted file sharing. But this my be chosen to be neglected as the worst thing is the server goes down.

A more pressing problem are honey-pot servers for a average user it is not always obvious  what server to trust and which not.
Any authority here would be prone to corruption as we know that the US is even coercing  SSL certificate authority's to provide them forged certificates, so it is not to far fetched that a big prominent server clearance point may be compelled by an injunction and a gag order to clear some honey-pot servers for the authorities and don't tell anyone.
The problem with honey-pot servers is that they don't just get a few of your files but all of them, in many jurisdictions this may actually be the difference between remaining anonymous or your ISP being compelled to give out your account details.
So if server support would to be added this flaw would have to be mitigated in a way that ensures the risk for typical users will not be substantially higher than using Kad only.

The solution for this issue is obvious, and actually employed by Torrent Clients,
you don't connect one client to one server (in torrent terminology Tracker), but you have a different server for each file, or at least for every small group of files you share.

For torrents this works really well as a typical torrent client does not share hundreds of files at once, not even dozens usually.

A similar approach would be needed for eMule, so that the user eider sets a custom server for each file or configures his client to automatically spread all files on as many servers as needed to never share more than lets say 20 files on every single server. This would be a neat and elegant solution, though it runs foul of eMule's policy to never maintain more than one server connection. For NeoLoader this would not be relevant as an independent client does not have in any way to conform to eMule's policy's but I'm afraid such a feature would cause a lot of flaming from many of the older eMule Mod Devs, despite the fact such a solution even was suggested by the new server developer himself: http://forum.emule-project.net/index.php?showtopic=156413

So long story short if I add server support it will be in the way described above, but I may for political reasons prohibit it from connecting to the old eserver from lugdunum what would make the feature for the time being not very useful until the new server software from petermrg replaces the old eservers in a substantial portion of the network.


5b) Besides, what are the changes that you made on the Kad network and what is the NeoShare network ?

David Xanatos & Ekliptor:
NeoLoader supports actually 3 individual Kademlia networks, Mainline DHT for Torrents, eMules Kad 2 and an own novel next generation Kademlia Network.
There are needer substantial changes to the TorrentDHT nor to the MuleKad.

NeoKad however is a completely from scratch developed Kademlia Network, its design goal was flexibility and anonymity. While classical Kad's can only handled payload types that they have hard coded support for. NeoKad can handle arbitrary payloads, this is achieved by running a script engine on each node and letting the scripts handle the payload processing, the scripts are sent if needed together with the lookup request. This architecture allows any developer to use our universal Kademlia network for his particular purpose. Simple things that spring to mind would be for example an anonymous untraceable Messager, or a censorship resistant alternative DNS system.
NeoKad's routing is implemented in a way that provides anonymity and deniability to its users, by means of recursive lookups, this means that instead of searching oneself for the globally closest nodes to send the requests to the system sends the request directly to the locally known closest node that than sends it further to even closer nodes, etc.. until the actual target nodes will be reached. This design ensures not only factual anonymity and plausible deniability to any particular node, it also makes the network incredibly robust to fragmentation. Like will for example occur with IPv4 and IPv6 where the network is spitted into 3 groups of nodes, those with only a IPv4 those with IPv4 and IPv6 and those with an IPv6 only, the recursive lookup design allows any node to reach any other node, even though no direct connection can be established.
An obvious extension was to add packet routing capabilities, so that using NeoKad you can not only publish data into the network and than retrieve it, but also establish reliable streaming tunnels between 2 anonymous entities, kind of like in I2P or TOR hidden services tunnel.
It basically works like this, the initiating node sets up a route that is identified by a EC (Elliptic Curve) public key fingerprint called (Entity ID) that was generated for the session, and spans the route into the target area around some randomly chosen 128bit Target ID, this pair of informations Entity ID and Target ID are all that is needed to contact the client, the real location (IP Address) of the client is hidden and not known to anyone, except the initiator himself. A relaying node can not distinguish if the previous node is the actual initializer of such a tunnel or a just yet another relay. This actually opens an very useful  opportunity a client that wants to have better speeds can choose a Target ID that lays very near to the Node ID of his NeoKad Node and this way be reachable without actually the need of going through a relay, of cause  than he will not be anonymous anymore but he and he alone will know that he is the initiator and not just the last relay node. So he could always deny any involvement and no one would be able to prove otherwise, and Voilà full plausible deniability, same trick works with any lookup within NeoKad. So this allows us to combine to a certain extent the security advantages of a typical anonymous network with the performance advantages of direct connections. Of cause all data are encrypted using strong end to end encryption, and in addition to that there is also a obfuscation layer to prevent ISP level filtering.

NeoShare is a anonymous P2P file sharing network that builds upon NeoKad's packet routing capabilities. It basically implements a simple P2P File-sharing protocol that instead of IP addresses works with Entity ID's and exchanges all data using NeoKad. As already hinted the use of variable length tunnels including 0 hoops gives the system the distinct advantage over other anonymous P2P implementations. In addition to that NeoKad's flexible Payload handling system allows to not to only store source and file informations in side the network, but even to cache many MB large parts on randomly selected nodes, adding to the speed benefits. This allows a user even to share files while his own client is off line he just has to order his client to push the entire file into the network, kind of like free net.

To sum it up the combination of various anonymization and misdirection techniques should ensure an unprecedented level of quality/speed while at the same time provide to any user exactly as much anonymity or deniability as he sees fit.


6) Don't you think that, considering the young age of the client, more documentation would  be necessary (in more languages) and considering the  high number of bugs a bugtracker?

David Xanatos & Ekliptor:
Yes I do, and we are working on that. Unfortunately we don't have enough manpower yet to maintain a Wiki and write detailed documentation so any Volunteers would be very welcome.
We are also looking right now into various bug tracker's to choose one and install it soon on our homepage.


7) A lot of users (and also some developers) expressed doubts about the  fact that NeoLoader is a closed source client (or semi-closed). Can you  explain the reason and if you will open the source code in the future?

David Xanatos & Ekliptor:
Well the doubts arise from the cultural differences between the P2P community's and the File Hoster community's.

The reason for this differences are the different requirements for each of this File Sharing schemes to work.
While P2P systems are very robust to any form of crackdown, you can in fact only pick some victims to make an example but you can ever really stop them by force. In comparison Hoster based systems are very vulnerable, all files uploaded in days of work or at least maxing out your Upload line for weeks can be gone in a few minutes if the wrong people get their hands on the links.
So already in ye ol' days of RS-Downloader the File Hoster community's developed various means of obfuscating the links so that users who may want to denounce them to the authorities would not get their hands on the actual links, while still being able to download the files.
This methods require the source to be closed, as on one hand you must give all means necessary to decrypt the links to the user but at the same time ensure he will never see the URL's in plain text.
So to be honest the conceptually exact same think BD-ROM's are trying to achieve, let the user see the movie while making it as hard as possible to actually get the data in plain text to copy it.
I have to say it plain and simple its DRM its bad in theory but it is war and when there is war bad things have to be done for a grater good. period.

There is in fact as of now, not a single one serious File Hoster Client that would be  really open source. The most known clients are RSDownloader, Cryptload, mipony, and JDownloader, and some more. Except of JDownloader all other are  completely closed source. JDownloader provides the most of their source  under the GPL, but the compiled binary they provide are not GPLed and  contain proprietary components for link protection. Also if any dev  wants to contribute to their project he has to permit them in writing,  to relicense his code as they see fit.
Their  proprietary server based link protection component is available to  other developers on request under a strict set of rules they have to  follow, failing them results in account termination and the component  being rendered inoperable. The restrictions basically are that the  developer is not allowed to share his account details with any 3rd party  and that no links obtained may be stored unprotected form user access  on hard disk or shown to the user in plain text.
So  the requirement to be allowed to use the link protection component are  incompatible with the requirements of the GPL. There for there never  will be a fully featured Mod of JDownloader.

Also  it should be obvious that if we index millions of hoster links in a  easy to search distributed network, all "interesting" links would almost  imminently be taken down, as we would this way present them to our  enemies so to say on a silver plater. They would just let their bots ask  our kad for files they want taken down and than send the links  automatically to the hosters for removal.

When you think about it the major problems for P2P Networks arise for the same causes as for File Hoster Community's, even though they are not equally severe on a global scale, the wrong people gaining access to the networks or confidential data. If no Internet surveillance  company could connect to a ed2k client or to a torrent client, the most problems P2P users face nowadays in large portions of Europe would not exist.

Simply put keeping parts of the source closed it is all about protecting users from Surveillance, Extortion and Internet Censorship, with any means necessary, and this includes a good portion of security by obscurity to keep the wrong people out of the networks.

So since for ed2k and bt its already to late, this protocols have already leaked to the  Internet Censorship, Surveillance and Extortion Companies and on the other hand NeoShare uses NeoKad and is those a anonymous Network, so one would think no harm would be done making this components open source. For the ed2k and bt this is certainly true, and for some long time we thought that it also holds for NeoKad as it is heavily anonymized. But that  opinion unfortunately was forced to change in march 2012: https://torrentfreak.com/anonymous-file-sharing-ruled-illegal-by-german-court-121123/ as a German court ruled that a user that was relaying data for some one  else is despite the fact he does not knowingly or willingly  participated in the transfer of the encrypted data and due to the  encryption was also unable to prevent the transfer of infringing data in  any way, is still liable for the infringement that was committed using  his client as a relay. It is insane legislation but unfortunately not  unprecedented in Germany, basically for them the last private person that can be identified that had something to do with the infringing data gets to fit the bill.  

So how else can the IP addresses of German users be protected form the Extortion Specialists?
Well  they could use a VPN that is not located in a Banana Republic like  Germany, but than there is not so much need for an anonymous FileSharing  network in the first place, also good VPN's in terms of anonymity don't  give you a full IP address, but at most the option to NAT a few  selected ports. So the most users will suffer from being not reachable  for the outside other than through NAT-Traversal, a.k.a. they will have a  LowID. Also using a VPN can not really be considered an actual  solution, its rather a crude workaround.
And in addition to that unless the VPN's will work for free you may have soon problems getting an account: http://torrentfreak.com/paypal-cuts-off-pirate-bay-vpn-ipredator-freezes-assets-130724/  as the Internet Surveillance Agency's are just in this very moment  clamping down on payment providers to stop the cash flow to VPN  providers.

So how does an actual solution look like?
Well its encryption misdirection and a lot of obfuscation, we must make it impossible to any user of a NeoKad node that is logging  all his IP traffic on the network adapter to distinguish transit traffic from traffic that ends  on his node and is routed to the NeoShare component.
German  judges may screw someone over unknowing and unwilling participating in  the transfer of infringing data for his negligence, but they surly can  not punish someone for just running a Relay node relaying unknown data  for an unknown 3rd party. They have at least to prove to one particular  node operator that their node relayed infringing data.
Now,  thanks to misdirection the Internet Surveillance and Extortion  Companies can not pinpoint a data stream they see coming out from the  NeoKad binary on their machine to any particular node they NeoKad node  is exchanging data with, using a simplified example: if there are 3 unbound streams and  2 outbound streams, one terminating locally  they can not tell from the  outside which one of the 3 tunnels is providing the infringing data. So  they can not sue anyone. This misdirection works only as long as your  treat the NeoKad binary as a black box on which inner workings you have  no insight. This does not means in this particular case that you are not  allowed to know in principle what it is doing in theory, just that you  are not allowed to know what is is explicitly doing right now. That  means the source could be open, as long as no one is capable of participating with a modified binary (with added  logging features) in the official Global NeoKad Network.
This sounds a bit tricky, doesn't it? How does one make the source open and functional while at the same time maintain control on what binary's can join the network?
We can solve this conundrum by using 2 transport layers a open one available for the open source  version and a proprietary one available only to the closed source  version compiled by us. And the users of our binary's will have the choice (default would be set based on users IP geolocation) if they want to use booth transport layer protocols or  only the secure proprietary one that guaranties to a reasonable extent  that if a connection can be established and maintained it is to a legit  unmodified binary.
This way the open source version on its own is fully functional despite the lack of one Transport Protocol. And as already described earlier the network is designed such that any fragmentation will not split it or hinder its working.

And thats the plan, release NeoKad under an appropriate Open Source License  that is not GPL compatible: http://piratepad.net/x43RU73nQN,  basically you can think about the license as a BSD/MIT license with a  clause prohibiting putting the code under a strong copy left license  like the GPL. As we must ensure any improvements done to the NeoKad code  by 3rd parties will remain back portable to our (or some one else's)  Surveillance resistant closed source release.

So what does that all means in practice for Open Sourcing NeoLoader or some of it parts in future.
Well as it is obvious some important security features can not work when being Open Sourced and those for the time being will be always a Closed Source NeoLoader build.
Only if the Pirate Partys around the world get into offices and manage to change relevant global policy's it will make the closed source components obsolete.
Till than we considder to provide in future a feature reduced NeoLoader that is Open Source and does not provide the additional security features. Since basically having no link protection at all would render the Hoster Support useless, the client would most likely lack the entire Hoster sub system and those have only P2P based file-sharing capabilities, so we would call such a client NeoShare.
Although since the Hoster Features are integrated in many places into NeoLoader it is not so strait forward to separate everything cleanly. So it would mean that we would have to maintain 2 projects  and we don't have the manpower for that now.
We are currently looking into moving P2P related code parts (ed2k and bt) into library's so that they can be used by other projects like http://quazaa.sourceforge.net/  with hum we are collaborating a little bit. Using library's would not  require us to maintain 2 separate projects as the library code would be  the same as NeoLoader is using.
But  also this is not that simple and will take many time, as we need to  change the code to use a proper factory and facade pattern and have a  API that allows us to hook in our proprietary extensions dynamically.

You can already find some Open Source components on gitoriuse: https://gitorious.org/~davidxanatos


8) What do you think about the apparent decrement of eMule's users in the last years and about its development?

David Xanatos:
I think the eMule's devs made/adopted some wrong design decisions about a decade ago that at these time ware not so detrimental but over time become a major hindrance in eMules success.
And as with any political decision at some point you can not go back without loosing face.

What I am talking about is eMules credit system and the FiFo (First In First Out) style queue. The Queue actually was already a part of the original eDonkey Protocol, but iirc Meta-machine (original ed2k inventors) realized their design fail and added the horde system that was somewhat similar to a BitTorrent Swarm and provided a subjectively much better download experience than any FiFo system ever could.

The main expectation of any somewhat not hardcore user is that if he starts a download it should actually start. With BitTorrent you basically enter a magnet link to a video file, you want to watch and if it is popular enough you can start watching it in real time while it is being downloaded.
With long FiFo Queues style systems this is not going to happen, ever.
A acceptable user experience requiters your download speed not to be a monotonically increasing function of your download duration, but roughly constant over the entire duration of your download. Even if the average download speed over your entire download duration would be the same in booth cases. The slowly starting download is a substantial worse download experience than a download that maintains a mediocre but constant speed over time.
To get a roughly constant speed you need a upload system that distributes the bandwidth to all users independent of their waiting time, for example randomly.

Most BitTorrent clients actually have 2 modes of operation, one for incomplete files they are  downloading and one for complete files they are seeding. Upload for complete files is distributed completely randomly to all requesting users. For Incomplete files a trading system is used, slots are opened at random but if they don't start uploading something back with in a reasonable time frame they are terminated and the next peer is tried, slots that maintain a acceptable Upload/Download ratio over the duration of the connection will be kept open indefinitely (like in a eDonkeyHybrid horde).

This fundamental difference in upload policy is in my opinion the main reason for BitTorents success.

If eMule don't want to slowly fade into obscurity they desperately need to start using an egalitarian random Upload Queue, and scrap the credit system together with their SUI.

An other major issue is that the people behind eMule think they can force users to use their client in a certain way as their see fit, that is as already stated  run it 24/7 and also manually solve LowID problems (if must be by changing the ISP), etc...
This patronizing attitude is simply ridi**censured**us, users are not forced to use eMule at all and they are enough alternatives that don't try to adapt the users to the program but instead gladly adapt the program to any needs the users may have.

The most prominent example of this attitude is the permanent refusal to add NAT-Traversal to the official client. The Offi Devs argue that NAT-T will cause users not to be so much disappointed with their LowID and those much less users will try to fix their LowID problem. They completely ignore all the users that for technical reasons are unable to obtain a HighID. And lets be honest the modern user eider Gets a High ID thanks to UPnP keeps a LowID and is happy with it, or solves the LowID problem by uninstalling eMule and installing uTorrent, which by the way has NAT-T just as the most other up to date BitTorrent Clients.


9) Why have you left the emule-project (as active developer) and how was the grudge against you born?

David Xanatos:
I left eMule development because I was not longer myself using my NeoMule as my main means of downloading, but  instead used mostly torrents and File Hosters.
Also it did not helped to keep me interested that no one (from the official moders) ever implemented any of my protocol extensions in their mods, for NAT-T I even provided a reference implementation (a eMule mod with NAT-T only) but no one seamed interested.

About the grudge against me, I would have to guess, I actually would like to know my self.

I think its a mix of multiple circumstances for once I'm a extremely skilled coder; and not shy to point that out when I have a opportunity (thats commonly considered arrogant). Also I'm a true anarchist not respecting any authority, what also not always is well received. And I have a big mouth criticizing everything I consider suboptimal and have a improvement idea for, bluntly trampling on any sacred dogmas there may be in place.

Also what seams to have initially sparked the controversy is my collaboration with Ekliptor whom developed some Notorious Lecher mods in the past, and our decision not to make NeoLoader fully open source right from the start just added fuel into the fire.


10) Recently inside emule-project's community a new client was born called kMule, developed by Tuxman and Wizard. What do you think about it?

David Xanatos:
I think it is a promising attempt at saving eMule from becoming obsolete, they definitely made some good improvements towards a more user friendly application.
But if they really want to succeed they have to break with the dogma that eMules Upload scheme is acceptable and instead implement a Torrent like Upload scheme. That makes downloads start right away and does not force users to run their clients over night. I don't know if they are willing to do that and obviously such a system would only than bring relieve  to the users if it would be adopted by a substantial portion of the network. So I also don't know if they can pull it of, I mean to take over as the leading ed2k only client in the network.

What they are lacking right now would be a "killer feature" that would make the average Offi eMule user put their old eMule into the dustbin and use kMule instead. At the moment i really don't see it just yet, but there definitely is the potential and I hope also the courage to pull it of, even if it means breaking with some antiquated design policy's.

I read that wizard would like to add NAT-T to a future version of kMule, this for example may just be such a "killer feature" the eMule world is waiting for. Now that the IPv4 addresses run out even some ISP's in Europe started selling accounts with only a shared IPv4 causing more people to get a unresolvable LowIDs, NAT-Traversal would bring here a substantial advantage for all these users. So I invested a day of work and made a new up to date reference Implementation of NAT-T v3: https://gitorious.org/neomule/neomule_reloaded, may be the 3rd time is really the charm and finally someone will adopt it.

This interview is published under Creative Commons Attribution 3.0 License

[THOR]

English version (part 2)


1) Hi Ekliptor, can you briefly introduce yourself for our users that still don't know you?

Ekliptor:
I'm a computer scientist from Munich. My main interest for projects in my free time is filesharing. This led me to start working on eMule in 2006, releasing some modifications with additional features.



2) What led you to take part in the development of the NeoLoader client?  

Ekliptor:
By 2009 One-Click hosters had gained lot's of popularity, causing eMule communities to shrink, while talk and usage of hosters increased everywhere. In Germany there was a second benefit to hosters aside from the obvious download-speed advantage compared to eMule. Laywers and P2P logging companies were very active in the ed2k network, so the idea of not disclosing your IP address together with information about what files you transfer to millions of users was very appealing. Unfortunately finding content became more difficult, because it was spread all over the web on blogs and forums. On top of that old content disappeared very quickly because hosters deleted files very soon and DMCA complaints just started to skyrocket.
So by that time in 2009, David and I talked about how to mitigate these problems and combine the advantages of a client like eMule with those of hosters. So quite rapidly during just one evening the idea of using a Kad network to publish and store hoster links, thus combining the best of both worlds, was born. I still remember the how excited David was about the idea and the zealousness to immediately start with it. David had just started his own download client called “ProxyLoader” to load from hosters using multiple IPs of proxies, thus bypassing download restrictions on free accounts. He wanted to use this as a base to start our client. Unfortunately ProxyLoader was still written using MFC and therefore a windows-only client. So we eventually agreed to start together from scratch using Qt, which allowed us to create a client that runs on all major operating systems. After a couple evenings of talking and planning together we felt ready to get started and the name “NeoLoader” was finally born.

 

7) A lot of users (and also some developers) expressed doubts about the fact that NeoLoader is a closed source client (or semi-closed). Can you explain the reason and if you will open the source code in the future?

Ekliptor:
Additionally since VPNs are basically just a central server through which all your data gets routed through, they have the same problem as described for eMule servers above. Your VPN see's all your traffic which is not end-to-end encrypted to a destination host beyond your VPN server. Therefore your VPN provider could log traffic for the extortionist lawyers. 



8) What do you think about the decrement of emule's users and the end (apparently) of its development?

Ekliptor:
First of all I don't think the decreasing amount of eMule users and the apparently dying development-cycle are tightly related.
I attribute the decrease in users mainly to a shift in the interests of many users. Some one-click hosters have been around for more than 10 years now and are therefore about the same age as the eMule client. However, while during the early and mid 2000s eMule was the popular choice to download files, in the past couple of years a lot of users seemed to have switched to hosters (or are at least using them more frequently than eMule). While proponents of eMule today might argue that the real number of users using eMule is hard to measure and probably still higher than in the mid 2000 (due to an increase in the number of households having internet connectivity), I find it quite obvious that eMule's market share on download-traffic of the internet has significantly decreased because of hosters and streaming sites. But that transition already started while poeple didn't think that the development of eMule was coming to a stop. So the reason for this change seems to be simply that one-click hosters are easier to use than eMule (or any P2P client for that matter) as well as the higher download rates.
 
At the same time a lot of eMule developers, who did a great job in the mid 2000s, gradually lost interest in eMule. Although some would probably try to deny this, I think that's the honest and only explanation why eMule is still lacking some important features like NAT-Traversal and at least an official roadmap for IPv6 support. And this even tough other filesharing clients and even eMule Mods have these features. This in turn demotivated a lot of eMule Mod developers, because for these features to have an impact, all clients in the network must support them.
 
I think if eMule wants to play any important role in the upcoming years in the filesharing community, bold action would have to be taken by those forums and sites that are still very involved in eMule. There are several options how I think this could be done:
 
An “official” eMule fork is one of them. Besides the already mentioned features like NAT-Traversal and IPv6 I think changing the queue system of eMule to select clients randomly and apply file-trading (like BitTorrent does) is necessary since slow download speeds (especially for new users) is definitely what cause eMule users to turn away disappointed. To encourage users to continue uploading their finished downloads (a huge selection of files is one of eMule's key features we want to keep), this could be improved by a ratio-bonus on the file-trading ratio for every user uploading a complete file to the user he's downloading from. Furthermore I would remove all long-term identification of eMule clients, namely remove the whole user-hash along with SUI. This decreases traceability of clients in the network and ensures that the file-trading ratios don't slow down new users, as the current eMule Credit System does.
 
But since such an “official” eMule fork would probably be banned from eMule's official forum (notably while still being GPL conform), i.e. the remaining eMule communities would have to spread it on their own anyway, the next bolder and better step would be basing this fork on aMule instead of eMule. When eMule started out, practically all home-computers used windows. This has changed significantly over the past years. So ensuring the main eMule client is platform independent seems necessary to me.
 
Ultimately, in my mind, the long-term goal for a continuing eMule community would have to be a platform independent libtorrent-like eMule core library written from scratch. But as can easily be seen on NeoLoader, there can be years of work between getting a project to function and getting it out of its beta stage. So by the time this library was out of its beta stage there might not be much left of the remaining eMule communities, which is why I think this idea would have to be combined with a fork of eMule or aMule. But the next generation of developers is not growing up with wxWidets (the aMule framework) or MFC (eMule) since both of these frameworks are outdated. So if you want new developers to join the project, as well as expand to new platforms like tablet computers which isn't supported by eMule/aMule's current frameworks, I think this step would be inevitable.



9) Why have you never been a developer of emule-project and why have you preferred to stay in the "dark side" of the modding?

Ekliptor:
The way I changed the eMule queue system wasn't allowed on eMule's official forum. Consequently, because of this choice I made, I understandably didn't feel very welcome in their forums and avoided posting there most of the time. Although I was still reading many threads and following up on interesting developments.
As for the “dark side” of my eMule mods, I tried to eventually move away from that by creating a separate network. My mods already have their own way of contacting each other through Kad. This is currently only used to store “Applejuice Credits” and to find the most popular files inside the community. Following that I started a branch of eMule Mods which specialized on releasing files into the network. And finally my Mods got the option to connect only to other mods of my community, i.e. dropping all hello packets from any other eMule client. This feature currently also provides safety against extortionist lawyers trying to monitor your sharing habits. (As a remark, this only works for the same reason some small parts of NeoLoader's source code will also have to stay closed source in order to keep the extortionists out of the network.) So with these 3 ideas already in place, the idea was to eventually migrate to an independent network which nobody could accuse of damaging the ed2k network. This fork would have been based on aMule. Even the idea of adding one-click hoster download support to this aMule fork has been discussed with other members of the community like Titandonkey and Razorback 3. However, since the idea of NeoLoader came up, my priorities shifted. Fully integrating hoster link-sources to eMule's/aMule's Part Files and Client Lists would have required a lot of changes to the source code. A new client written from scratch is definitely the better approach, as it allows you to better structure your code to fit these new requirements.

 

10) Recently inside emule-project's community was born the new client kMule, developed by tuxman and wizard, what do you think about?

Ekliptor:
I think it's a nice idea to try to keep the eMule community going. If you want to have a chance to attract new modders, you have to add better structure eMule's source code and remove some unnecessary and outdated features, thus making it easier for new interested developers to understand the whole source code and start developing. Furthermore, eMule has no official developers guide and documentation. So if they add a guide for new developers after their lightweight version of eMule has progressed far enough, I think their client might really have a chance to revive some eMule forums by attracting young new developers. If that might bring enough new “regular” users back to eMule remains questionable though. To ensure eMule's long-term competitiveness against other download clients, I think bold action is required and their approach doesn't go far enough yet (see answer 8).

This interview is published under Creative Commons Attribution 3.0 License

[THOR]

E' per noi un vero piacere presentarvi l'intervista che David Xanatos e Ekliptor, gli sviluppatori del nuovo client chiamato NeoLoader, hanno gentilmente rilasciato ad Emule-Mods.it
Li ringraziamo per la loro gentilezza e gli auguriamo di proseguire il loro eccellente lavoro con NeoLoader.



Versione italiana (parte 1)


1) Ciao David, puoi presentarti brevemente per i nostri utenti che ancora non ti conoscono?

David Xanatos:
Sono uno dei membri fondatori del Partito Pirata Austriaco, lavoro come Fisico all'università di giorno e sviluppo applicazioni per il filesharing di notte.


2) Puoi illustrare il client NeoLoader e cosa ti ha spinto a crearlo?

David Xanatos:
Il concetto iniziale di NeoLoader era di unire insieme i vantaggi di un programma di file-sharing p2p con quelli di un file-sharing basato su Hoster, usando la rete Kademlia.

Volevamo creare il primo client che potesse fornire la ricerca globale di parole chiave per il download di file da siti Hoster. In questo modo, un utente non dovrebbe cercare tra i vari siti i link riconducibili ai file richiesti, ma potrebbe inserire una parola di ricerca in Neo ed iniziare a scaricare subito i file. Inoltre, volevamo risolvere il problema dei link a file "interessanti" che spesso spariscono piuttosto velocemente portando i siti che pubblicizzano link ad avere molti dei loro servizi down, fino a quando qualcuno si lamenta ed i file vengono ricaricati manualmente.
Avere un client per l'upload dei file consentirebbe ai releaser di monitorare con semplicità lo stato dei loro file online e, quasi senza sforzi, ricaricare gli stessi ogni volta che qualche file viene perso.
Questa feature potrebbe essere estesa per far sì che i file scaricati possano essere ricaricati automaticamente se richiesto ma, per motivi di sicurezza, questa funzione non è attiva di default.
Per rendere il sistema ancora più robusto decidemmo, fin dall'inizio, di aggiungere una funzionalità di p2p anonimo in modo che, se un particolare file non fosse più disponibile su nessun Hoster, un client potesse comunque scaricare quel file da altri utenti che l'avevano scaricato in passato e che ancora lo avevano a disposizione. Visto che il file sharing p2p di base è completamente anonimo, questo non dovrebbe portare nessuna nuova minaccia imprevista alla media di utenti ben protetti da un Hoster.
E mentre c'eravamo, decidemmo di aggiungere il supporto ad altre reti di file-sharing come bt e ed2k, che però sono disattivate di default in modo che, se un file non fosse disponibile su un Hoster o nella rete anonima NeoShare, il nostro client potrebbe mettere in condizione l'utente di scaricarlo da bt o da ed2k ed informarlo che questo porterà a condividere il file in una rete non sicura; in questo modo, egli potrà prendere una decisione ponderata sulla scelta da fare. Inoltre, viene offerta un'opzione per creare un account VPN al fine di mitigare i rischi connessi all'utilizzo di una rete p2p aperta e non anonima.

Per riassumere, l'obiettivo era quello di offrire un nuovo programma di condivisione che desse alla media dei normali utilizzatori la migliore esperienza possibile di download e, allo stesso tempo, la protezione della loro privacy nel modo migliore possibile.


3) Puoi presentare le funzioni principali del client e qualche anticipazione su eventuali novità?

David Xanatos & Ekliptor:
NeoLoader è capace di combinare insieme qualsiasi sistema di file-sharing. Questo risultato viene raggiunto usando un network Kad di nuova generazione che indicizza tutti i file incontrati dal client grazie al calcolo del loro hash ed all'associazione dei link. Non importa da quale network viene scaricato il file. Quest'ultimo riceve un hash attraverso l'utilizzo di sistemi appropriati ed in seguito i dati vengono pubblicati nel network Kad.

Questo nucleo elaborativo (core) rende possibili un sacco di nuove funzionalità (feature). Offre la capacità di condurre ricerche tramite una parola-chiave globale per tutte le tipologie di download, cioè una ricerca “eMule style” per i download tramite Torrent e Hoster. Questa feature non ha precedenti per questi 2 popolari sistemi di file sharing. In passato gli utenti dovevano affidarsi a link o motori di ricerca Torrent i quali spesso fornivano informazioni datate.
L'associazione di hash permette di scaricare un file da più di un network allo stesso tempo. Per esempio, se avviamo il download tramite un link ed2k, NeoLoader può recuperare le corrispondenti "Informazioni di Hash Torrent" e scaricare il file ad una velocità superiore tramite il protocollo Torrent.
NeoLoader rivoluziona anche il modo in cui i siti di File-Host possono operare. Piuttosto che fornire stupide liste di link o collegamenti statici criptati, essi possono usare i NeoLink, i quali identificano i file tramite il loro hash univoco come avviene nei sistemi P2P; inoltre, i Neo utenti possono recuperare link aggiornati dal network Kad. Usare la divisione dei file in parti come nei sistemi P2P permette di intercambiare le parti in upload tra differenti releaser così da migliorare notevolmente la disponibilità dei file. Oltre a ciò, gli utenti senza account premium a pagamento possono scaricare i file a velocità accettabili dato che sono in grado di recuperare un numero di fonti tale che potrebbero scaricare ogni parte gratuitamente da differenti hoster e senza dover aspettare.
I file caricati sui siti di hosting tramite il nuovo schema Neo possono interscambiare parti con i download tramite P2P, così si può scaricare allo stesso momento da ed2k, torrent e da siti di Hosting.
Una caratteristica basata su questa capacità è rappresentata da un meccanismo di cache automatico delle parti basato sui File Hoster, così che le parti che sono necessarie a qualche client P2P potranno essere caricate automaticamente su un File Hoster ed in seguito scaricate da lì. Tutto ciò effettivamente può moltiplicare l'ampiezza di banda disponibile nel network ad un più alto ordine di grandezza.
NeoLoader supporta anche un sistema di file sharing P2P completamente anonimo cosicché gli utenti possono scaricare in sicurezza i file non piu disponibili sui File Hoster. Il sistema si chiama NeoShare e, attraverso la combinazione di vari parametri, regola il livello di anonimato esattamente al livello di controllo richiesto dall'utente; questo assicura migliori performance rispetto agli altri network di file sharing anonimi.

Il supporto di NeoLoader a tutti gli schemi e network per il file sharing è di ultima generazione.
Supporta tutte le estensioni di rilievo al protocollo Bittorrent ed è completamente compatibile ad eMule, inoltre ci sono nuove pioneristiche estensioni di protocollo per ed2k come il NaT-T, IPv6 e altri.
Il nostro motore di download hoster minimizza le competenze richieste allo sviluppo di script gestionali per Hoster e siti di link grazie ad un browser senza interfaccia grafica scritto in Java Script e totalmente funzionante. Molte parti possono essere semplicemente gestite avviando eventi su elementi DOM-tree (Document Object Model n.d.r.) e non è più necessario emulare il codice AJAX a mano.

In futuro lavoreremo ulteriormente a NeoKad migliorandone le performance e l'affidabilità per i tunnel anonimi. Inoltre, intendiamo riscrivere il sistema globale di ricerca per includere qualche schema di valutazione in modo che i risultati di ricerca generati da NeoKad abbiano una qualità al pari dei buoni siti di link e torrent.  


4) Perchè un utente dovrebbe trovare NeoLoader migliore di altri client?

David Xanatos & Ekliptor:
Capacità di ricerca globale tramite parole chiave per download da reti Bittorrent
Capacità di ricerca globale tramite parole chiave per link su siti Host
Scambio parti tramite i sistemi di condivisione convenzionali
Un nuovo stile di collegamento tra P2P ed il download da siti Host
Sistema di condivisione completamente anonimo e veloce (NeoShare)
Contributo avanzato a tutti i tipi e progetti per la condivisione dei file


5a) Hai intenzione di inserire il supporto ai server ed2k in futuro?

David Xanatos & Ekliptor:
Quando ho iniziato l'implementazione del supporto ed2k nella NeoLoader, sembrava chiaro che non ci sarebbe mai stato nessun supporto server, in quanto non erano disponibili dei software server aggiornati e per la presenza di alcune buone motivazioni contro l'utilizzo di punti centralizzati nel File-sharing. Ma nel febbraio di questo anno petermrg ha annunciato su EP (http://forum.emule-project.net/index.php?showtopic=156155) la sua intenzione di sviluppare un software server aggiornato che, col mio aiuto, ha prodotto nei mesi successivi.

Le vecchie argomentazioni contro l'utilizzo dei server sono ancora valide, ma si può sempre discutere sulla rilevanza di alcuni loro difetti.
Uno dei problemi dei server è che sono dei bersagli centrali per gli attacchi da parte di persone che non amano la libera condivisione dei file priva di restrizioni. Ma questo punto può essere trascurato e la conseguenza peggiore è rappresentata dalla chiusura del server.

Un problema più urgente sono i server "trappola" (honey-pot), in quanto per un utente medio non è sempre facile capire di quali server fidarsi e di quali no.
Qualsiasi autorità qui sarebbe incline alla corruzione, come negli Stati Uniti dove sappiamo che stanno forzando l'autorità di certificazione SSL affinché fornisca loro i propri certificati falsificati, quindi non è poi così esagerato pensare che un gestore di server di spicco possa essere costretto, attraverso un provvedimento inibitorio ed un ordine privato, a "donare" alcuni server trappola in favore delle autorità e senza dirlo a nessuno.
Il problema con i server honey-pot è che non ottengono solo alcuni dei tuoi file, bensì tutti. In molte giurisdizioni questo può effettivamente fare la differenza tra rimanere anonimi o essere costretti a dare i dati dell'account al proprio ISP.
Quindi, se il supporto server fosse da aggiungere, questo difetto dovrebbe essere mitigato in modo tale da garantire che il rischio per gli utenti tipici non sia di molto superiore all'utilizzo della sola rete Kad.

La soluzione per questo problema è evidente e di fatto impiegato dai client Torrent.
Non connetti un client ad un server (nella terminologia torrent viene chiamato Tracker), ma hai un server differente per ogni file, o perlomeno per ogni piccolo gruppo di file che condividi.

Nel sistema torrent questo funziona veramente bene in quanto un tipico client torrent non condivide centinaia di file per volta, e solitamente neanche decine.

Per eMule sarebbe necessario un approccio simile, in modo che l'utente imposti un server personalizzato per ogni file oppure configuri il proprio client in modo che diffonda automaticamente tutti i file in più server ma in modo da non superare mai i 20 files su un singolo server. Questa sarebbe una soluzione pulita ed elegante, anche se ciò creerebbe un conflitto con le regole di eMule che non permettono la connessione a più di un server. Per NeoLoader questo non sarebbe rilevante in quanto è un client indipendente che non deve in nessun modo conformarsi alle regole di eMule, ma ho paura che una tale funzione potrebbe causare un sacco di polemiche da parte di molti fra i più vecchi Devs Mod di eMule, nonostante il fatto che tale soluzione riguardante lo sviluppo dei nuovi server fu suggerita proprio da me: http://forum.emule-project.net/index.php?showtopic=156413

Quindi, per farla breve, se aggiungo il supporto ai server, sarà nel modo sopra descritto, ma forse, per ragioni politiche, proibirei la connessione ai vecchi eserver lugdunum, cosa che renderebbe la caratteristica momentaneamente poco utile finché il nuovo software server creato da petermrg non sostituirà i vecchi eServers in una porzione sostanziale della rete.


5b) Inoltre, quali sono i cambiamenti che hai effettuato sulla rete KAD e in cosa consiste il network NeoShare?

David Xanatos & Ekliptor:
NeoLoader attualmente supporta 3 singole reti Kademlia: Mainline DHT per Torrent, eMule Kad 2 e una propria rete Kademlia di nuova generazione.
Non ci sono modifiche sostanziali al TorrentDHT, né alla eMuleKad.

NeoKad è una rete Kademlia sviluppata completamente da zero, il suo obiettivo di progettazione è stata la flessibilità e l'anonimato. Mentre la classica Kad può gestire soltanto alcuni tipi di PayLoads (flusso di dati rappresentante un contenuto informativo n.d.r) che sono "HardCoded" (insiti nel codice sorgente n.d.r.), NeoKad è in grado di gestire PayLoads arbitrari; questo si ottiene eseguendo un motore di script su ogni nodo e lasciando allo script la gestione del processo di PayLoad. Gli script sono inviati, se necessario, assieme alla richiesta di ricerca. Questa architettura permette ad ogni sviluppatore di usare la nostra rete Kademlia universale per i propri scopi. Alcune semplici cose che mi vengono in mente sono un messenger anonimo non rintracciabile o un sistema alternativo di dns resistente alla censura.
Il routing (instradamento n.d.r.) di NeoKad è implementato per fornire ai propri utenti anonimato e negazione plausibile mediante ricerche ricorsive, questo significa che invece di cercare autonomamente i nodi globali più vicini a cui inviare le richieste verso il sistema, inoltra quest'ultime al nodo locale attiguo che a sua volta continuerà finchè verrà raggiunto il nodo che cerchiamo. Questo progetto non solo assicura alla rete anonimato e plausibile negabilità per ogni singolo nodo, ma rende la rete incredibilmente robusta contro la frammentazione. Come si verificherà con IPv4 e IPv6, la rete è divisa in 3 gruppi di nodi, uno con IPv4, uno con IPv4 e IPv6 ed uno con IPv6 soltanto. In questo caso la ricerca ricorsiva permette a qualsiasi nodo di raggiungere l'altro anche se non è possibile una connessione diretta.
Un'estensione ovvia era quella di aggiungere funzionalità di routing dei pacchetti, quindi usando NeoKad non puoi soltanto pubblicare dati nella rete e poi riceverli, ma anche stabilire tunnel di streaming affidabili tra 2 entità anonime, come avviene in I2P e TOR.
Fondamentalmente funziona così: il nodo di avvio imposta un percorso che viene identificato da un EC (curva ellittica) riconducibile ad una chiave pubblica crittografata chiamata entità ID che è stata generata per la sessione, ed estende l'instradamento nell'area di destinazione intorno a qualche Target ID (id di destinazione n.d.r.) cifrato a 128bit scelto a caso; questa coppia di informazioni (entità ID e Target ID) è tutto il necessario per contattare il client. La reale posizione (indirizzo IP) del client è nascosta e non è conosciuta da nessuno, eccetto l'iniziatore. Un nodo intermedio non può distinguere se il nodo precedente ha iniziato il tunnel o è un altro intermediario. Questo scenario apre un'opportunità al client che vuole ottenere migliori velocità, infatti quest'ultimo sceglierà un TargetID vicino al nodo ID della propria NeoKad e sarà raggiungibile senza bisogno di intermediari. In questo caso non è anonimo, ma solo lui sa di essere il nodo iniziale del tunnel, quindi può sempre negare qualsiasi coinvolgimento e nessuno è in grado di provare il contrario. Et voilà, ecco la negazione plausibile; lo stesso trucco funziona per ogni ricerca nella NeoKad. Questo ci permette di combinare in una certa misura i vantaggi nella sicurezza di un tipico network anonimo con i vantaggi di performance della connessione diretta. Quindi tutti i dati sono criptati da un capo all'altro, e in più c'è anche uno strato di offuscamento per prevenire il filtraggio da parte dell'ISP.

NeoShare è una rete di condivisione anonima costruita sulla capacità di instradamento dei pacchetti di NeoKad. Fondamentalmente utilizza un semplice protocollo di condivisione P2P che invece degli indirizzi IP funziona con entità ID e scambia tutti i dati utilizzando NeoKad. Come già detto, l'uso di tunnel a lunghezza variabile dà al sistema un distinto vantaggio sulle altre implementazioni di reti P2P anonime. In aggiunta al sistema di gestione flessibile dei PayLoads, NeoKad permette non solo la memorizzazione delle informazioni di file e fonti nella rete, ma funge anche da cache per vari MB su nodi casuali, migliorando la velocità. Questo permette all'utente di condividere i propri file anche quando il suo client è offline, deve soltanto ordinare a quest'ultimo di spingere l'intero file nel network, come in una free net.

Per riassumere la combinazione di varie tecniche di anonimizzazione e di depistaggio, NeoLoader dovrebbe garantire un livello di qualità/velocità senza precedenti, mentre allo stesso tempo dovrebbe fornire a qualsiasi utente anonimato o negazione come meglio crede.


6) Non pensi che, vista la giovane età del client, sarebbe necessaria una maggiore documentazione (in più lingue) e, visti i numerosi bug, un bugtracker?

David Xanatos & Ekliptor:
Si che la faccio, ci stiamo lavorando su. Purtroppo ancora non siamo in molti per sostenere una Wiki e per scrivere la documentazione in modo dettagliato, quindi l'arrivo di volontari sarebbe molto gradito.
Stiamo cercando tra diversi bug traker al fine di sceglierne uno da installare prossimamente sul nostro sito.


7) Molti utenti (ed anche alcuni sviluppatori) hanno espresso perplessità sul fatto che NeoLoader sia un client a codice sorgente chiuso (o semi-chiuso). Puoi spiegarne le ragioni e se in futuro aprirai il codice sorgente?

David Xanatos & Ekliptor:
Bene, i dubbi nascono dalle differenze culturali tra la comunità P2P e quella legata ai file Hoster.

La causa di queste differenze riguarda le diverse esigenze che ciascuna di queste realtà di condivisione utilizza per funzionare.
I sistemi P2P sono molto robusti a qualsiasi forma di repressione, infatti si possono prendere in considerazione solo alcune vittime per fare un esempio, ma non li si può mai fermare con la forza.
In confronto, i sistemi basati su Hoster sono molto vulnerabili; tutti i file caricati impegnando giorni di lavoro o dopo aver quasi saturato la propria banda di upload per settimane, possono scomparire in pochi minuti se le persone sbagliate mettono le mani sui link.
Così, già dai tempi di RS-Downloader, la comunità dei File Hoster sviluppò diversi mezzi per offuscare i link in modo tale che gli utenti che intendevano denunciarli alle autorità non potessero mettere le mani sui link effettivi, pur essendo in grado di scaricare i file.
Questi metodi richiedono che il codice sorgente sia chiuso, come da un lato si devono offrire tutti i servizi necessari al fine di rendere decodificabili i link utili all'utente, ma allo stesso tempo garantire che egli non vedrà mai l'URL in un testo normale.
Quindi, per essere onesti, il concetto di pensare allo stesso obiettivo che i BD-ROM (Blue-Ray Disc n.d.r.) stanno tentando di raggiungere, permette sì all'utente di vedere il film, mentre rende effettivamente più difficile ottenere i dati in formato testo per copiarlo.
Devo dire che è chiaro e semplice il fatto che il suo DRM (Digital Rights Management n.d.r) sia un male, in teoria, ma è una guerra e quando c'è la guerra brutte cose devono essere fatte per un bene più grande.

Fino ad ora non esiste un vero e proprio File Hoster veramente open source. I clienti più conosciuti sono RSDownloader, Cryptload, Mipony, JDownloader e qualcun altro.
Tranne che per JDownloader, tutti gli altri sono completamente closed source. JDownloader fornisce la maggior parte dei propri sorgenti con licenza GPL, ma i binari compilati che forniscono non sono sotto licenza GPL e contengono componenti proprietari per la protezione dei link. Anche se qualche sviluppatore vuole contribuire al loro progetto, deve essere avanzata una richiesta per iscritto, così che gli sviluppatori ufficiali possano mettere sotto licenza il suo codice come meglio credono.
La loro componente di protezione proprietaria dei link del server è a disposizione di altri sviluppatori su richiesta sotto una rigida serie di regole che devono seguire; la mancanza di queste provoca la chiusura dell'account e la componente viene resa inutilizzabile. Le restrizioni che fondamentalmente lo sviluppatore deve seguire riguardano il divieto di condividere i suoi dati account con qualsiasi terza parte ed il divieto di conservare su disco rigido i link ottenuti sotto forma non protetta dall'accesso degli utenti o mostrarli loro in testo normale.
Quindi, l'obbligo di essere autorizzati ad utilizzare il componente di protezione dei link è incompatibile con i requisiti della GPL. Lì per lì non ci sarà mai una Mod ben descritta di JDownloader.

Inoltre, dovrebbe essere ovvio che se noi indicizzassimo milioni di link hoster in una rete distribuita nella quale è facile trovarli, tutti i link "interessanti" verrebbero quasi subito rimossi, così come se li presentassimo ai nostri nemici, per così dire, su un piatto d'argento. Semplicemente questi lasceranno che i loro bot chiedano alla nostra kad per i file che intendono disfarsi e quindi invieranno automaticamente i link agli hoster per la rimozione.

Quando si pensa che i maggiori problemi per il P2P sorgano per le stesse cause attribuibili alle comunità di file Hoster, anche se non sono altrettanto gravi su scala globale, le persone sbagliate guadagnando l'accesso alle reti o a dati riservati. Se nessuna società di sorveglianza Internet potesse connettersi a un client ed2k o ad un client torrent, la maggior parte dei problemi che gli utenti P2P devono affrontare al giorno d'oggi in ampie porzioni di Europa non esisterebbe.

In poche parole, mantenere il codice chiuso è utile al fine di proteggere gli utenti dalla Sorveglianza, estorsione e Censura di Internet, con ogni mezzo necessario, e questo include una buona parte della sicurezza attraverso l'oscuramento per tenere le persone sbagliate fuori dalle reti.

Quindi, dal momento che per ed2k e bt è già troppo tardi visto che questi protocolli sono già trapelati alla censura di Internet, Sorveglianza ed Aziende d'estorsione, dall'altra parte NeoShare usa NeoKad, che è una rete anonima, per cui si potrebbe pensare nulla di male a rilasciare i suoi componenti open source. Per ed2k e BT questo è certamente vero, e per qualche tempo abbiamo pensato che valesse anche per NeoKad visto che è pesantemente anonima. Ma purtroppo siamo stati costretti a cambiare questa opinione nel Marzo 2012: https://torrentfreak.com/anonymous-file-sharing-ruled-illegal-by-german-court-121123/ visto che un tribunale tedesco ha stabilito che un utente che stava tramettendo i dati per qualcun altro, nonostante il fatto che non avesse consapevolmente o volontariamente partecipato alla trasmissione dei dati crittografati e che a causa della crittografia non fosse stato in grado di impedirne il trasferimento o la violazione in qualsiasi modo, è ancora responsabile per l'infrazione che è stata commessa usando il suo client come trasmettitore. E' la legislazione folle, ma purtroppo non senza precedenti in Germania, in fondo per loro l'ultima persona privata che può essere identificata e che ha qualcosa a che fare con i dati violati viene perseguita.

Quindi, in quale altro modo possono essere protetti gli indirizzi IP degli utenti tedeschi dagli specialisti dell'estorsione?
Beh potrebbero utilizzare una VPN che non si trova in una repubblica delle banane come la Germania, quindi non c'è tanto bisogno di una rete di FileSharing anonima in questo caso, però anche una buona VPN in termini di anonimato non conferisce un completo indirizzo IP, ma al massimo dà la possibilità di eseguire il NAT di alcune porte selezionate. Quindi, la maggior parte degli utenti soffrirà del fatto di essere non raggiungibile dall'esterno se non attraverso il NAT-Traversal, in altre parole avranno un ID basso. Anche utilizzare una rete VPN non può essere considerata una soluzione reale, piuttosto è una soluzione grezza.
E in aggiunta a questo, a meno che la VPN funzioni gratis, si possono avere dei problemi ad ottenere un account: http://torrentfreak.com/paypal-cuts-off-pirate-bay-vpn-ipredator-freezes-assets-130724/ visto che l'Agenzia di Sorveglianza di Internet in questo momento intende reprimere i pagamenti effettuati ai provider VPN al fine di fermare il flusso di soldi verso quest'ultimi.

Allora quale potrebbe essere una soluzione reale?
Bene, deve avere un suo depistaggio crittografico e un sacco di offuscamento, dobbiamo rendere impossibile il riconoscimento di tutto il traffico IP sulla scheda di rete effettuato da qualsiasi utente di un nodo NeoKad connesso, in modo da non distinguere il traffico di transito dal traffico che termina sul suo nodo e che viene indirizzato al componente NeoShare.
I giudici tedeschi possono sì incolpare qualcuno basandosi sull'inconsapevolezza e l'indisposizione nel partecipare al trasferimento di dati dovuto alla sua negligenza, ma essi non possono punire qualcuno solo per aver avviato un nodo di trasmissione di dati sconosciuti verso una terza parte altrettanto sconosciuta. Essi devono almeno dimostrare a un particolare nodo operatore che il loro nodo ha trasmesso dati contraffatti. Ora, grazie al depistaggio, la sorveglianza di Internet e le Società di estorsione non possono individuare un flusso di dati che vedono uscire dal binario NeoKad in merito ad un particolare nodo con il quale NeoKad sta scambiando dati. Usando un esempio semplificato: se ci sono 3 flussi senza restrizioni e 2 flussi in uscita oltre ad una terminazione a livello locale, essi dall'esterno non possono affermare che uno dei 3 tunnel stia fornendo dati contraffatti, quindi non possono fare causa a nessuno. Questo depistaggio funziona solo a patto che si tratti il binario NeoKad come una scatola nera sul cui funzionamento interno non si ha alcuna conoscenza. Ciò non significa, in questo caso particolare, che non è permesso sapere in linea di principio ciò che sta facendo, in teoria, solo che non è permesso sapere ciò che sta esplicitamente facendo in quel momento. Ciò significa che i sorgenti potrebbero essere aperti, a condizione che nessuno sia in grado di partecipare con un binario modificato (con l'aggiunta di funzionalità di registrazione) nella rete globale NeoKad ufficiale.
Questo suona un po' complicato, non è vero? Come si fa a tenere il sorgente aperto e funzionale e allo stesso tempo mantenere il controllo sui binari con i quali è possibile collegarsi alla rete?
Siamo in grado di risolvere questo enigma utilizzando 2 tipologie di traporto: uno aperto e disponibile per la versione open source ed una esclusivo disponibile solo per la versione closed source compilata da noi. Gli utenti del nostro binario potranno scegliere (di default dovrebbe essere impostata sulla base della geolocalizzazione IP) se vogliono utilizzare entrambi i protocolli di trasporto o solo quello proprietario protetto; quest'ultimo garantisce, in misura ragionevole, che se una connessione può essere stabilita e mantenuta, significa che il binario non è modificato e quindi legittimo.
In questo modo la versione open source di per sé è completamente funzionale nonostante la mancanza di un protocollo di trasporto. Come già descritto in precedenza, la rete è progettata in modo tale che ogni frammentazione non la suddividerà né ostacolerà il suo funzionamento.

E questo è il piano, il rilascio di NeoKad sotto una appropriata licenza Open Source che non è compatibile con la GPL: http://piratepad.net/x43RU73nQN, in pratica si può pensare alla licenza del tipo BSD / MIT con una clausola che vieta di mettere il codice sotto una forte licenza copyleft come la GPL. Visto che dobbiamo garantire i miglioramenti apportati da terze parti al codice NeoKad, rimarrà indietro il rilascio del nostro (o di qualcun altro) sorgente chiuso resistente alla sorveglianza.

In pratica, questo è tutto ciò che si intende per l'apertura dei sorgenti di NeoLoader o delle sue parti in futuro.
Beh, è ovvio che alcune importanti caratteristiche di sicurezza non possono funzionare quando sono a sorgente aperto e quelle, per il momento, saranno sempre a codice chiuso.
Solo se i Partiti Pirata in tutto il mondo vanno negli uffici e riescono a cambiare la politica globale renderanno i componenti closed source obsoleti.
Fino ad allora, in un futuro terremo in considerazione il rilascio di un client Neoloader con funzionalità ridotte, quindi Open Source e che non offrirà le caratteristiche di protezione aggiuntive. Dal momento che in fondo non si ha la protezione dei link, renderebbe il supporto Hoster inutile, il client molto probabilmente mancherebbe di tutto il sistema di sub Hoster e quindi sfrutterebbe solo la funzionalità  di condivisione P2P, così lo chiameremo NeoShare.
Visto che le caratteristiche Hoster sono integrate in molte parti di NeoLoader, non è così semplice separare tutto in maniera pulita. Questo vorrebbe dire che dovremmo mantenere 2 progetti e non abbiamo la forza lavoro per questo.
Attualmente stiamo pensando di spostare le parti di codice relative al P2P (ed2k e bt) inserendole in librerie in modo che possano essere utilizzate da altri progetti come http://quazaa.sourceforge.net/ con i quali stiamo collaborando un po'. Usare le librerie non dovrebbe richiedere il mantenimento di due distinti progetti e lo stesso vale per il codice della libreria che dovrebbe essere lo stesso utilizzato da NeoLoader.
Ma anche questo non è così semplice e ci vorrà molto tempo, abbiamo bisogno di modificare il codice per utilizzare un adeguato modello di fabbrica e di facciata oltre ad avere una API (Application Programming Interface n.d.r.) che ci permetta di agganciare dinamicamente le nostre estensioni proprietarie.


Potete trovare alcuni componenti Open Source su gitorius: https://gitorious.org/ ~ davidxanatos


8) Cosa ne pensi del calo di utenza di eMule e della fine (apparente) del suo sviluppo?

David Xanatos:
Credo che gli sviluppatori di eMule abbiano fatto/adottato decisioni progettuali sbagliate oltre una decade fa; allora non sembrarono così dannose, ma col passare del tempo si sono rivelate un grande ostacolo al successo di eMule. E come per ogni decisione politica, a un certo punto non si può tornare sui propri passi senza perdere la faccia.

Ciò di cui sto parlando è il sistema di crediti di eMule e lo stile FiFo (First In First Out) della coda. La coda erà già parte dell'originale protocollo eDonkey ma, se non ricordo male, (iirc*) Meta-machine [/color] (inventori dell'ed2k originale) capirono l'errore progettuale ed aggiunsero il sistema di horde[/color] che grossomodo somiglia al BitTorrent Swarm e fornisce un'esperienza di download soggettivamente[?] migliore di quella possibile con qualsiasi sistema FiFo.

L'aspettativa principale di qualunque utente "non estremo" è che quando si fa partire un download, questo parta sul serio. Con BitTorrent essenzialmente si inserisce un magnet link ad un file video che si vuol vedere, e se è popolare a sufficienza si può iniziare a guardarlo in tempo reale, mentre è ancora in download. Con i sistemi a lunghe code di tipo FiFo, questo non accadrà mai.

Un'esperienza di utilizzo accettabile richiederebbe che la velocità di download non sia una funzione – crescente in modo monotono – della durata del download stesso, ma piuttosto che si mantenga grossomodo costante per l'intera durata del download. Anche se la velocità di download media per tutto il download fosse costante in entrambi i casi, un download che parte lentamente è sostanzialmente un'esperienza di download peggiore di un download che mantiene una mediocre ma costante velocità nel tempo.
Per ottenere una velocità approssimativamente costante occorre un sistema di upload che distribuisca la larghezza di banda a tutti gli utenti indipendentemente dai loro tempi d'attesa, ad esempio in modo casuale.

La maggior parte dei client BitTorrent oggi ha due modi di operare: uno per i file incompleti in download ed uno per i file completi in upload. L'upload dei file completi è distribuito in modo completamente casuale a tutti i richiedenti.
Per i file incompleti viene impiegato un sistema di scambio: gli slot vengono aperti casualmente ma se non iniziano a restituire qualcosa in upload entro un intervallo di tempo ragionevole, vengono terminati e si inizia una nuova sessione. Gli slot che invece mantengono un rapporto upload/download accettabile per tutta la durata della connessione vengono tenuti aperti indefinitamente (come in un sistema horde tipo eDonkeyHybrid).

Questa fondamentale differenza nella gestione dell'upload è, secondo me, la ragione principale del successo di BitTorrent.

Se eMule non vuole lentamente svanire nell'oscurità, è necessario che si inizi ad utilizzare una coda di upload egualitaria e casuale, oltre a sbarazzarsi dei sistemi di crediti e dei relativi SUI.

Un altro grande problema è che le persone dietro ad eMule pensano di poter imporre agli utenti di utilizzare il loro client nel modo che loro ritengono più opportuno ossia, come già affermato: lasciarlo in esecuzione 24 ore al giorno 7 giorni su 7, lasciandoli risolvere manualmente i loro problemi di ID basso (nel caso, anche cambiando l'ISP), eccetera...

Questo atteggiamento paternalistico è semplicemente ridicolo: gli utenti non sono costretti da nessuno ad usare eMule e ci sono abbastanza alternative che non cercano di "adattare" l'utente la programma ma che piuttosto adattano volentieri il programma ai vari bisogni che gli utenti possono avere.

L'esempio più emblematico di quest'attitudine è l'ostinato rifiuto di aggiungere il NAT-Traversal al client ufficiale: Gli sviluppatori di eMule ufficiale, sostengono che il NAT-T farebbe sì che gli utenti non siano più così insoddisfatti dei loro ID bassi, così che molti meno utenti cercherebbero di risolvere i loro problemi di ID basso. Gli sviluppatori ufficiali ignorano completamente tutti gli utenti che non possono avere un ID alto per motivi tecnici. E, siamo onesti, l'utente d'oggi: od ottiene un ID alto grazie all'UPnP, o si tiene l'ID basso e si accontenta, o risolve i suoi problemi di ID basso disinstallando eMule ed installando uTorrent, che del resto è fornito di NAT-T proprio come quasi tutti i client BitTorrent aggiornati.


9) Qual è il motivo per cui hai abbandonato l'emule-project (come sviluppatore attivo) e da cosa nasce l'astio che esiste nei tuoi confronti?

David Xanatos:
Ho lasciato lo sviluppo di eMule poiché non mi sentivo più mestesso nell'utilizzare il mio NeoMule come principale strumento per il download, al contrario usavo per lo più Torrent e siti di Hosting.
Inoltre, non ha aiutato a tenermi interessato al progetto il fatto che nessuno ( tra gli sviluppatori ufficiali di mod ) abbia mai implementato una qualsiasi delle mie protocol extensions nelle loro mod;
per il NAT-T ho persino creato una implementazione di riferimento ( una mod di eMule con solo il NAT-T ), ma nessuno si è dimostrato interessato.

Riguardo il rancore nei miei confronti, posso solo provare ad indovinare, piacerebbe anche a me saperlo.

Penso che la causa sia dovuta a diverse cose, in primis il fatto che sono uno sviluppatore estremamente abile e non manco di farlo notare agli altri ( cosa che è comunemente associata all'arroganza ).
Inoltre sono vero anarchico, non rispetto alcuna autorità, altra caratteristica che non è sempre apprezzata.
Tra l'altro non manco di criticare qualsiasi cosa che considero inefficiente o per la quale ho un'idea per migliorarla, travolgendo senza ritegno qualsiasi "dogma sacro" che possa esserci sull'argomento.

La scintilla che ha creato la controversia sembra essere stata la mia collaborazione con Ekliptor, che in passato ha sviluppato note Leecher Mod.
La decisione di non rendere il codice sorgente di NeoLoader pienamente pubblico fin dall'inizio ha soltanto aggiunto benzina sul fuoco.


10) Recentemente nella comunità emule-project è nato il nuovo client kMule, sviluppato da Tuxman e Wizard, tu cosa pensi a riguardo?

David Xanatos:
Penso che sia un promettente tentativo per salvare eMule dal diventare obsoleto; hanno fatto sicuramente dei buoni miglioramenti per arrivare ad un'applicazione user friendly.
Ma se vogliono veramente avere successo, devono rompere con il dogma che vuole che il sistema di upload di eMule sia accettabile e implementare invece un sistema di upload stile Torrent. Questo permette che i download partano subito e non impone agli utenti di dover tenere acceso il client tutta notte. Non so se sono disposti a farlo ma, ovviamente, un sistema simile potrà solo portare sollievo agli utenti, sempre se questo verrà adottato da una porzione sostanziale della rete. E quindi, io non so neanche se possano farcela, intendo cioè diventare il client ed2k leader della rete (nota del redattore: penso intenda; visto che secondo lui un sistema di upload di questo tipo impone avere una grossa parte della rete, kmule dovrebbe diventare il client ed2k più diffuso nella rete).

Quello che gli manca in questo momento è una "killer feature" che faccia sì che l'utente medio metta il suo vecchio eMule nella pattumiera e usi kMule al suo posto. Al momento non riesco ancora a vedere questa cosa, ma sicuramente kMule ha del potenziale e spero anche il coraggio per farcela, anche se questo significa rompere con una qualche linea di condotta antiquata.

Ho letto che wizard vorrebbe aggiungere il NAT-T a qualche futura versione di kMule; questo sarebbe un esempio di una "killer feature" che il mondo di eMule attende. Adesso che gli indirizzi IPv4 si stanno esaurendo, alcuni ISP Europei hanno iniziato a vendere contratti adsl con indirizzi IPv4 condivisi portando molti utenti ad avere LowIDs (ID basso) irrisolvibili. Il NAT-Traversal porterebbe un notevole vantaggio a tutti questi utenti. QUindi ho investito un giorno di lavoro e ho fatto una versione aggiornata della "reference implementation" del NAT-T v3 (https://gitorious.org/neomule/neomule_reloaded); forse la terza versione è più allettante e finalmente qualcuno la adotterà.

La presente intervista è pubblicata con licenza Creative Commons Attribution 3.0 License

[THOR]

Versione italiana (parte 2)


1) Ciao Ekliptor, puoi presentarti brevemente per i nostri utenti che ancora non ti conoscono?

Ekliptor:
Sono un informatico da Monaco di Baviera. Nel tempo libero, il mio interesse principale è il file sharing. Questo mi ha portato ad iniziare a lavorare su eMule nel 2006, rilasciando alcune mod con funzioni aggiuntive.



2) Cosa ti ha spinto a partecipare allo sviluppo del client NeoLoader?  

Ekliptor:
Nel 2009 gli One-Click hoster avevano guadagnato una sacco di popolarità contribuendo alla riduzione della comunità di eMule, mentre il passaparola e l'utilizzo degli hosters era cresciuto ovunque. In Germania si attribuiva un secondo beneficio agli hoster a parte l'ovvio vantaggio di velocità di download rispetto ad eMule. I giudici e le società di registrazione P2P erano stati molto attivi nella rete ed2k, quindi l'idea di non divulgare il proprio indirizzo IP insieme ad informazioni sul tipo di file che venivano trasferiti a milioni di utenti era molto interessante. Purtroppo trovare materiale era diventato più difficile perché veniva diffuso in tutto il web su blog e forum. In cima a tutto questo, i vecchi contenuti scomparivano molto rapidamente perché gli hoster cancellavano i file molto presto ed i reclami della DMCA erano appena iniziati a salire alle stelle. Così da quel momento, nel 2009, David e io abbiamo parlato di come attenuare questi problemi e di combinare i vantaggi di un client come eMule con quelli degli hoster. Quindi, abbastanza rapidamente e nel giro di una sera è nata l'idea di utilizzare una rete Kad per pubblicare ed archiviare i collegamenti hoster, combinando così il meglio dei due mondi. Ricordo ancora come David fosse eccitato all'idea e lo zelo con il quale iniziò ad applicarla. David aveva appena creato il suo client chiamato "ProxyLoader" al fine di caricare dagli hoster utilizzando IP multipli di proxy, aggirando così le restrizioni nel download applicate agli account gratuiti. Voleva usare questo come base per iniziare il nostro client. Purtroppo ProxyLoader è stato scritto utilizzando MFC e quindi era funzionante solo su Windows. Alla fine abbiamo deciso di avviare il progetto insieme partendo da zero ed utilizzando Qt, il quale ci ha permesso di creare un client che funziona su tutti i principali sistemi operativi. Dopo un paio di serate di discussione e programmazione insieme, ci siamo sentiti pronti per iniziare e finalmente nacque il nome di "NeoLoader".
 

7) Molti utenti (ed anche alcuni sviluppatori) hanno espresso perplessità sul fatto che NeoLoader sia un client a codice sorgente chiuso (o semi-chiuso). Puoi spiegarne le ragioni e se in futuro aprirai il codice sorgente?

Ekliptor:
In aggiunta, dal momento che le VPN sono fondamentalmente un solo server centrale attraverso il quale tutti i dati vengono instradati, hanno lo stesso problema descritto sopra per i server di eMule. Il tuo gestore VPN vede tutto il tuo traffico non cifrato inoltrato verso un host di destinazione che va oltre il proprio server VPN. Pertanto il fornitore VPN potrebbe registrare il traffico per gli avvocati estorsori.  



8) Cosa ne pensi del calo di utenza di eMule e della fine (apparente) del suo sviluppo?

Ekliptor:
Attribuisco la diminuzione degli utenti principalmente ad un cambiamento nell'interesse di molti di questi. Alcuni one-click hoster sono sulla piazza da più di 10 anni e quindi hanno circa la stessa età del client eMule. Tuttavia, mentre nel corso della prima metà degli anni 2000 eMule è stata la scelta più popolare per scaricare i file, nel corso degli ultimi due anni un sacco di utenti sembra essere passato agli hoster (o almeno li utilizzano più frequentemente di eMule). Mentre i sostenitori di eMule oggi potrebbero asserire che il numero reale di utenti che usano eMule sia difficile da misurare e probabilmente potrebbe essere ancora superiore alla metà del 2000 (a causa di un aumento del numero di famiglie che hanno la connessione internet), trovo abbastanza ovvio che la quota di mercato di eMule nel traffico di download da Internet sia notevolmente diminuita a causa degli hoster e dei siti di streaming. Ma questa transizione era già iniziata mentre le persone non pensavano che lo sviluppo di eMule fosse prossimo al capolinea. Quindi, la ragione di questo cambiamento sembra essere semplicemente riconducibile al fatto che gli one-click hoster sono più facili da utilizzare rispetto ad eMule (o qualsiasi client P2P utile a tale scopo), così come le velocità di download più elevate.

Allo stesso tempo, un sacco di sviluppatori di eMule che hanno fatto un ottimo lavoro a metà degli anni 2000, a poco a poco hanno perso interesse per eMule. Anche se probabilmente qualcuno potrebbe cercare di negare ciò, credo che l'unica ed onesta spiegazione sia riconducibile al fatto che in eMule mancano ancora alcune caratteristiche importanti come il NAT-Traversal ed almeno una linea guida ufficiale per il supporto all'IPv6. E tutto questo nonostante altri client di filesharing e persino alcune mod di eMule includano da tempo queste caratteristiche. Questo a sua volta ha demotivato un sacco di sviluppatori di Mod, perché queste caratteristiche, per avere un impatto, devono essere supportate da tutti i client della rete.

Penso che se nei prossimi anni eMule vuole ancora giocare un ruolo importante nella comunità del filesharing, dovrebbero essere intraprese delle azioni corraggiose da parte di quei forum e siti che sono ancora molto coinvolti nel suo progetto. Ci sono diverse opzioni che potrebbero essere applicate:

Un fork "ufficiale" di eMule è una di queste. Oltre alle caratteristiche già citate come NAT-Traversal e IPv6, penso che cambiare il sistema di coda di eMule per selezionare i clienti in modo casuale ed applicare il file-trading (come fa BitTorrent) sia necessario in quanto l'irrisoria velocità di download (in particolare per i nuovi utenti) è sicuramente ciò che causa delusione tra gli utilizzatori. Per incoraggiare gli utenti a continuare la condivisione dei download finiti (una vasta selezione di file è una delle caratteristiche chiave di eMule che vogliamo mantenere), potrebbe essere migliorata attraverso un bonus applicato sul rapporto di scambio file per ogni utente che sta uppando un file completo e colui che lo sta scaricando. Inoltre vorrei rimuovere ogni identificazione a lungo termine del client eMule, cioè rimuovere l'intero user-hash con SUI (Identificazione Sicura Utente n.d.r.). Questo diminuisce la tracciabilità dei client nella rete ed assicura che i rapporti di file-trading (scambio file n.d.r.) non rallentino i nuovi utenti, ovvero quello che accade con l'attuale sistema dei crediti di eMule.

Ma dal momento che un tale fork "ufficiale" sarebbe vietato dal forum ufficiale di eMule (in particolare pur essendo GPL conforme), le rimanenti comunità di eMule dovrebbero diffonderlo autonomamente. ll prossimo passo più audace e migliore sarà quello di basare questo progetto su aMule invece che su eMule. Quando eMule ha iniziato, praticamente tutti i computer casalinghi usavano Windows. Questo è cambiato molto negli ultimi anni. Quindi, per me appare necessario garantire l'indipendenza della piattaforma principale del client eMule.

Infine, nella mia mente, l'obiettivo a lungo termine utile al fine di garantire una longeva comunità di eMule dovrebbe essere una piattaforma indipendente, riscritta da zero e basata su librerie torrent. Ma come può essere facilmente visto con NeoLoader, possono passare anni di lavoro tra un progetto funzionante ed un progetto in fase beta. Quindi, quando questa libreria uscirà dalla sua fase beta, potrebbe non esserci rimasto molto delle comunità eMule restanti, motivo per cui credo che questa idea dovrebbe essere combinata con un fork di eMule o aMule. La prossima generazione di sviluppatori non sta crescendo con wxWidets (le librerie di aMule) o MFC (eMule), in quanto entrambe queste strutture sono obsolete. Quindi, se si desidera che nuovi sviluppatori partecipino al progetto, anche espandendosi a nuove piattaforme come i tablet PC, i quali non sono supportati dalle strutture logiche di eMule/aMule, credo che questo passo sia inevitabile.



9) Qual è il motivo per cui non sei mai entrato a far parte dell'emule-project ed hai invece preferito il "lato oscuro"?

Ekliptor:
Il modo in cui ho cambiato il sistema di code di eMule non era permesso sul forum ufficiale. Così, a causa della scelta da me compiuta, comprensibilmente non mi sono più sentito benvenuto nel loro forum ed ho quasi sempre evitato di postare lì, anche se stavo ancora leggendo vari thread e seguendo alcuni sviluppi interessanti.
Per quanto riguarda il "lato oscuro" delle mie mod di eMule, ho tentato di allontanarmi da ciò creando una rete separata. Le mie mod hanno già il proprio modo di connettersi con altri via Kad. Questo serve oggi solo per accumulare "crediti Applejuice" e per trovare i file più popolari all'interno della community. Seguendo ciò, ho iniziato a lavorare su di una branca di mod di eMule specializzate nel releasing di file nella rete. Infine le mie mod sono state provviste dell'opzione di potersi connettere esclusivamente con altre mod della mia community, cioè rifiutando i pacchetti di benvenuto/riconoscimento inviati da qualunque altro client di eMule. Questa funzione, tra l'altro, garantisce sicurezza contro gli avvocati estorsori che cercano di monitorare le tue "abitudini di condivisione". (A titolo di osservazione, alcune piccole parti del codice sorgente di NeoLoader dovranno restare closed-source (a sorgente chiuso n.d.r.), in modo tale da tenere questi estorsori fuori dalla rete).
Così, con queste tre idee già al loro posto, il passo successivo era quello di migrare finalmente ad una rete indipendente, in modo che nessuno potesse accusare di danneggiare la rete ed2k. Questo fork sarebbe stato basato su aMule. Anche l'idea di aggiungere il supporto al download attraverso gli one-click hoster è stata discussa con altri membri della community come Titandonkey e Razorback 3. Comunque, dal momento in cui saltò fuori l'idea di NeoLoader, le mie priorità cambiarono. Una completa integrazione tra i collegamenti hoster, le parti di file e le liste di client di eMule/aMule avrebbe richiesto un sacco di modifiche al codice sorgente; un nuovo client compilato da zero è sicuramente l'approccio migliore, dato che permette di strutturare meglio il codice per potervi inserire questi nuovi requisiti.
 

10) Recentemente nella comunità emule-project è nato il nuovo client kMule, sviluppato da Tuxman e Wizard, tu cosa pensi a riguardo?

Ekliptor:
Penso che sia una bella idea cercare di mantenere aggiornata la comunità di eMule. Se si vuole avere una possibilità di attirare nuovi modders, bisogna strutturare meglio il codice sorgente di eMule e rimuovere alcune funzioni inutili e obsolete in modo da rendere più facile ai nuovi sviluppatori capire il codice sorgente completo e iniziare lo sviluppo. Oltre a questo, eMule non ha guide e documentazioni ufficiali per gli sviluppatori. Quindi, se aggiungeranno una guida per i nuovi sviluppatori, dopo che la loro versione "leggera" di eMule sarà abbastanza stabile, penso che il loro client potrà avere davvero una chance di ravvivare alcuni forums di eMule attirando nuovi giovani programmatori. Se questo potrà riportare abbastanza utenti "regolari" a eMule, rimane ancora discutibile però. Per garantire una competitività a lungo termine contro altri client di download, penso che sia necessaria un'azione più audace e il loro approccio non va ancora abbastanza lontano (vedi risposta 8).

La presente intervista è pubblicata con licenza Creative Commons Attribution 3.0 License