----- Original Message ----- From: "fish" <[email protected]> To: <devl at freenetproject.org> Sent: Friday, November 29, 2002 8:03 PM Subject: Re: [freenet-dev] Freenet Updating
> > >>>Actually, I just got another idea on how to handle them with a new key > > >>>type. Let's call it a Time Redirection Key (TRK). The key is designed so > > >>>that it will always route to the same part of the keyspace for a specific > > >>>updatable file. When someone initially uploads a document, they point to > > >>>this routing keyspace, and a request goes in that direction. This > > >>>keytype has an unencrypted meta-value that is basically an estimate for > > >>>the next update time. If a request reaches a node with a key that has a > > >>>next-update-estimate time less than the current time, it continues on > > >>>until the search finds a node with a next-update-estimate that is greater > > >>>than the current time. If the request fails, it returns with the most > > >>>recent value for the key found in the request chain. > > this sounds no better than most of the ideas going around for editions > right now. defeats the purpose of implenting updatable keys in the first > place > Updatable keys are a security vunerability. If someone's key is compromized, their original content can be removed by updating the content with a "hacked by foo" message in its place. Also, how does the fact that this "defeats the purpose of implenting updatable keys" make it "no better than most of the ideas going around for editions right now"? Good updating needs several qualities: 1. Minimal requests (preferably no more than 2: redirect and data) 2. Minimal request length (requests that must go the full HTL are undeseriable) 3. No "maintenace" or broadcast requests (they just waste network bandwidth) 4. Granular update interval 5. Persistence of old data (for security reasons) 6. Ability to find the most recent version of a site if it isn't maintained. 7. Works well with both popular and unpopular sites So here's a comparison: 1. Updatable Keys and regular editions only need 1 request, while DBRs and TRKs need 2. No big difference here, although regular editions need to do a lot of requests to find the most recent version. 2. Updatable Keys fall short on this (at least all the ideas i've seen). TRKs only go the full HTL if the author has not updated their content after the time they said they would. 3. All of the good ideas i've seen for updating don't need maintenance or broadcast requests. This is probably because any idea that does need them is a bad one. 4. Updatable Keys and regular editions can update whenever they want. DBRs are required to update at specific intervals. With TRKs, the interval can be changed, and the author can specify a 0-time interval so that it always gets the most recent content (although this would make requests suffer from problem #2) 5. Updatable Keys get iffy at this. Some people want to do away with the old version while other people want to keep them. I think that the network should be left up to decide wether or not to keep the old data. 6. DBRs are the only ones that have a problem with this. 7. Some updatable key ideas have a problem with this. DBRs have a problem with it too because single-day keys that are still pointing to old data don't get a good foothold in freenet for unpopular sites. Regular editions and TRKs improve reliability over time. (Although TRKs will take longer if it's past the last estimated update time, they will still be reliable). So the only problem with TRKs that they really suffer with is #2, but even then they only do a full request until after the estimate update time. -Scott Young _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
