> > Here is an update to my original post about DistribNet with a good deal > of information added. > > 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. It will also try to avoid some of > the problems freenet has been having. > > *** 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.
This is simply a matter of implementation. You could write a Gnutella node that used a datastore, or you could write a Freenet node that doesn't. The node on the other end really doesn't care how your data is stored, only that the data is available. > > Since data is stored in a straight forward manner there is little > change the "datastore" will get corrupted and have to be reset. > Also, since data is no longer in a fixed size file, the size of the > data store can be controlled via both soft and hard quotas. > > Finally support will be added for shrinking the datastore so that > there would be no reason anyone can not donate almost all of > there unused space to DistribNet. Wait, I thought you said there would be no datastore??? > > *) The protocol will be well defined and kept as simple as possible. > Transferring of data from one node to another will likely use the > HTTP protocol for simplicity. Probably a good idea. You could probably even build an FProxy-like system right into the node where it assumes any HTTP request that doesn't set an "X-Node: true" header is a browser or other HTTP client and return a standard HTTP reply. The node themselves will set that header, thus letting the node on the other end know that it is a node contacting you, not a client. > > *) By default no attempt will be made to prevent other nodes from > knowing what is in another nodes datastore. I don't see how this helps. It seems like it is *too* public, on the order of "finger". <> > 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. Good idea. Hang around P2P developers long enough and eventually you see them reinvent CHKs over and over again *g*. > > 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 new index or data pointer to the existing list. By > default, 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 as those proved to > be completely insure. Also a good idea. We've had flame wars around here of weather KSKs should be expunged from Freenet or not (personally, I think they should be gone). > Instead Map keys may be requested with out a > signature. Are you planning on some sort of web-of-trust system? _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
