On Mon, 18 Feb 2002, Timm Murray wrote: > > > > I want to first thank everyone for all the feedback I have been getting. > > However, I want to also make clear some things about DistribNet. > > > > 1) I want the system to be designed with scalability, availability of > > data, and speed in mind not absolute privacy and anonymity. > > Fine, but why must you blatently ignore possibilites for privacy that > don't hugely affect your desgin? As was stated before, crypto does not > radically change the speed of Freenet's routing, and there is no reason > to believe that it will be any different on your network. A good block > cipher (like AES) is pretty quick and won't noticably decrease your > efficency while doing much to increase privacy (if done properly).
I am not blatantly ignoring the possibility. I just don't want the network to be designed primary around privacy. For the initial design I want to get everything working without encryption but allowing the possibility for it which can be added on latter. > > The main reason I am starting this project is that in my view freenet, as > > it now, is way to concerned with complete anonymity. And more > > importantly, it is overly concerned about preventing people from > > controlling what type of data is stored in there own node as demonstrated > > by the recent removal of the delete command and the fact that freenet > > stores all of its data in a single file with its own property indexing > > methods instead of relaying on the file system or other well established > > simple database system such as Berkeley DB. > > IIRC, one argument for using the datastorefs instead of the native file system was >that > you can immediately claim the space specified. Under Fred 0.3, if you specified >your > data store size to be 200 MB, but later on you only have 150 MB of free space on the > disk, your node would run into problems. With the datastore, you specify 200 MB >now, it > creates a 200 MB store on the disk and thus other files won't take up the space Fred > needs. Also, you open up the possibility of encrypting the entire store with a >passphrase > that must be typed in every time you start the node (this isn't done right now, but >it > could be in the future). I'm sure there are other good reasons for using a special > datastorefs. Yeah I am sure you can find other ones but in my view it adds a lot of unneeded complexity. I also like have keys stored as files so one can actually use the data in the cache. Why must someone donate a fixed amount of space? Why can't they say always leave % percent of disk space free and have the cache grow and shrink itself as necessary? By the way if you must reserve the space you can probably do it by creating a huge file from /dev/zero and shrink it as the cache grows. And just why would you want to encrypt already encrypted data? What purpose will that serve. > > > I am also not very happy about the fact the Freenet 0.40 was pushed on > > the end user way before it was ready as evident my the many > > "mandatory" updates posted and the constant need to reset the data > > store. Freenet 0.40 may be stable *now* but it sure wasn't in > > December and January. > > "It seemed like a good idea at the time." I think the argument was > that 0.4 became more stable than 0.3, so there was no reason to > encourage people to still use 0.3. Now, 0.3 totally sucked, while 0.4's > only problem was a plauge of datastore problems (which is certainly bad, > but it still manages to be better than 0.3). And all those dam datastore problems could be avoid if you were not so concerned and keeping the node operator from knowing what is in his own node. Which in my view something the node operator has every right to know. > It certainly *should* be able to, but an ill-connected network (0.3) and datastore > problems (0.4) have prevented it from showing this ability thus far. Well I will stick around but I am loosing confidence in Freenet's ability. --- http://kevin.atkinson.dhs.org _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
