NOTE: I am posting this to freenet-tech in order to get some constructive criticism and general ideas. Please do not flame me as I will simply ignore you.
I really like the general idea behind freenet, however I believe Freenet is overly concerned about anonymity. Therefore, unless some one talks me out of it, I am strongly considering starting my own project called DistribNet which will be similar to Freenet but different in a number of key areas. *** Comparison to Freenet *) Focus more on speed and scalability than anonymity. The goal of DistribNet is to be as fast or faster than the Web for any sort of pages with reasonable popularity. *) No fancy datastore. Use the file system for storing keys. No attempt to disguise what is in one owns datastore. Nothing is encrypted by default. *) By default no attempt will be made to prevent other nodes from knowing what's in another nodes datastore. *) Data, by default, will go directly from one node to another instead of having to be routed through other nodes. Please not the "by default" part. The eventual goal support the same level of anonymity that freenet offers, but that is not DistribNet primary focus. However, DistribNet will be the same as freenet in several key areas. *) Will allow anyone to anonymously post content to the network *) Completely decentralized *) Content will be stored in a similar fashion that data is stored in Freenet. That is popular content will be In addition DistribNet will deffer by freenet as it is now with: *) The ability for one to share content that is one one's hard drive or be able to fetch content from the Web or other networks when it is more effect to do so. *) Searching and support for "updateable" keys will be build into the protocol from the beginning. The searching faculty will be designed in such a way to make message boards trivial to implement. *) Will try very hard to keep all but the most unpopular content from falling off the network. *** Philosophy behind DistribNet For most type of things the level of anonymity that freenet offers in simply not needed. Even for copyrighted and censored material there is, in general, little risk in actually viewing the information because it is simply impractical to go after every single person who access forbidden information. Most all of the time the lawsuits and such are after the original distributors of the information and not the viewers. There for DistribNet will offer the same level of anonymity that freenet offers for distributing information, but not for actually viewing it. However, since there *is* some information where even viewing it is extremely risky, DistribNet will eventually be able to provide the same level of anonymity that freenet offers, but it will be completely optional. I also believe that knowing what is in one owns datastore and being able to block certain type of material from one owns node is not that big of a deal. Unless almost everyone blocks a certain type of information the availability of blocked information will not be harmed. This is because even if 90% of the nodes block say, kiddie porn, the information will still be available on the other 10% of the nodes which, if the network is designed correctly, should be more than enough for anoyone to get at blocked information. Furthermore, since the source code for DistribNet will be protected under the GPL or similar license, it will be completely impractical for other to force a significant number of nodes to block information. *** DistribNet Architecture I have not worked all the details of how DistribNet will work, but here is what I have so far: There will essentially be two types of keys. Map keys and data keys. Map keys will be uniquely identified in a similar manner as freenet SSK keys. Data keys will be identified in a similar manner as freenet's CHK keys. Map keys will contain the following information: * Short Description * Public Namespace Key * Timestamped Index pointers * Timestamped Data pointers _At any given point in time_ each map key will only be associated with one index pointer and one data pointer. Map keys can be updated by appending a more a new index or data pointer to the existing list. By fault, when a map key is queried only the most recent pointer will be returned. However, older pointers are still there and may be retrieved by specifying a specific date. Thus, map keys may be updated, but information is never lost or overwritten. Data keys will be very much like freenet's chk keys except that they will not be encrypted. Since they are not encrypted delta compression may be used to save space. There will not be anything like freenet's KSK keys. Instead Map keys may be requested with out a signature. If there is more than one map key by that name than a list of keys is presented. To make such a list meaning full every public key in freenet will have a descriptive string associated with it. Query for keys will be handled similar to freenet but instead of returning the actual data a pointer to the node which can easily provide the data is returned. The data can then directly be transfered from one node to another. Once transfered the data will be cached in the local node. If a particular node notices a large number of query for a key that it does not have it may chose to store a copy in its own cache therefore providing similar performance benefits that freenet's routing provides. *** Conclusion I really think I can make this work. So unless someone talks me out of it I am extremely likely to code something out, with or without other support. However, I am hopping I do not have to do it without. If you think this is a good idea be sure and let me know. If you don't fell free to also let me know but keep it constructive and to the point. If you start flaming me you will be ignored. --- http://kevin.atkinson.dhs.org _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
