I have found the following mirrored to Freenet from I2P. I would like to discuss this, if people don't mind. This will probably induce a flame war between Freenet and I2P, but the issues at stake are more important than that. Please read the below, and read my response to it, before replying.
Freenet URI: http://127.0.0.1:8888/CHK at oaP3GuqiTb3t-krpzvllua4pd6cNAwI,9Z~9tQliGmdaXWGlrUw0ig/not_invented_here.html Contents: identiguy at mail.i2p Not Invented Here Friday, September 23, 2005 "A few days ago, Toad posted a message to the Freenet devl list, arguing in favor of re-implementing I2P inside of Freenet. Of course, that's not the way he put it, but that's what his comments amount to. He believes that, with a large amount of effort, it would be possible to allow low-latency communication between parties on Freenet (presumably using the same means as pre-mix routing), allowing for applications such as IRC to operate over Freenet. He believes this is necessary because the recent low activity levels on Freenet are the result of a lack of communication between users and developers. He says he'd rather not recommend they use IRC over I2P, because users who begin to use I2P tend to abandon Freenet. This, it seems to me, is a blatant admission on the part of the primary Freenet developer that Freenet development no longer serves any rational purpose. Freenet's users may not know it yet, but they don't want Freenet. They want a stable, efficient, performant, secure communications medium. Freenet 0.5 is none of these things. The goal of development over the last several months has been to start again, producing a package that does meet these critieria, but the fact is that one already exists: I2P. (Disclaimer: I2P isn't finished yet, it might have bugs that defeat its security.) The reason users abandon Freenet once they begin to embrace I2P is that I2P meets their needs better than Freenet. Toad's proposed solution to this problem is to write an equivalent of I2P into Freenet 0.7. But why? If Freenet does not meet the needs of the users, and I2P does, is there any reason to continue Freenet development at all? Why spend the effort to make Freenet try and do what I2P already can? Is the greater glory of Ian Clarke worth that much?" Here is my response: - No, it is not using premix routing. I have come to the conclusion that it is very difficult to implement premix routing securely on a darknet. It is using rendezvous-at-a-key and provides multicast streams, which as far as I know I2P cannot do. We will also have 1:1 streams on a similar basis. - I2P does not meet the needs of the users. Specifically, I2P is harvestable. I2P will always be harvestable, as far as I can see. This means, essentially that a chinese technician can block it in a day. That means that I2P is utterly useless anywhere where it is illegal. Now, I'm not saying Freenet totally solves the problem, but I2P doesn't even pretend to solve the problem. Freenet 0.7 can, for those of you that have been asleep for the last 6 months, form a scalable darknet, where you only connect to your friends. This cannot be harvested; it can only be compromized one node at a time via very expensive attacks. And it can scale, because social networks are small world. The network in practice will be a hybrid - parts will be "open" and parts will be "dark" - but it will be technically possible to set up large darknets. - Recently people on the IRC channel have told me that I2P is very slow recently. - I2P does not provide all the functionality Freenet does (e.g. document storage), but even if it did, it would not be a viable replacement for Freenet 0.7 for the simple reason that it is harvestable. I apologize for provoking a flamewar, but the article is utterly untrue and a personal attack. This may not be the author's intention, but it is the fact of the matter. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20051005/68ec32d8/attachment.pgp>
