On Fri, 2003-05-16 at 14:50, Toad wrote: > On Fri, May 16, 2003 at 05:03:22AM +0000, jrandom wrote: > > Ok, lots of chatting on IRC today about updatable keys, spawned by > > "<toad_> we must do something about this silly edition site prejudice" > > Almost two hours later, I think we've got something. > > > > Proposal: > > Add a new key type that supports secure sites that: > > - are like edition sites that can be bookmarked > > - are like DBR sites, but don't dissapear when they aren't inserted > > - doesn't allow people to delete their content > > - allows people to backtrack to old versions without much trouble > > > > Summary: > > There are two parts to the proposal - a new key type and some supporting > > metadata. The new Time Updatable Key (TUK) contains in its payload > > only the latest site edition number. The TUK itself is signed by > > the site's owner, and nodes throughout freenet have access to the update > > date through standard datastore/FNP mechanisms. Whenever a TUK > > collision occurs, the one with the latest timestamp wins, replacing the > > old version. > > Important point: this occurs not only on inserts, but also, when we make > a request, we keep going, fetching later versions if they are available, > until we run out of HTL or reach the desired timestamp.
Updatable keys have been debated over, and over, and over again for the past several years, so I'll weigh in on what I've gathered so far. The problem of going the entire HTL is, of course, the time lag that every request for updatable content must suffer. Oskar's Interval Pass-Through Update scheme from September of 2000 was an early idea to solve this problem: http://www.geocrawler.com/archives/3/928/2000/9/50/4421682/ One change that I would make to his scheme, though, is to use a formula that would make the next-time-to-allow-pass-through the same throughout the network, so that there isn't a mess with nodes mismatching update windows and continually re-propagating old content. Another scheme would be to do the request, return the first TUK that the request hits immediately, but still continue the request on until the most recent one is found, and return that if it exists. A "reload" in the browser window would give the new content once it was received. This scheme would be much quicker at distributing new content, but it would cause more network traffic. Although, TUKs would only be a few bytes long so traffic might not be so much of a problem. Both of these schemes require a key that will always route to the same area of the keyspace for all keys updating the same content. A node needs to know where the updates will be located in order to find them, which becomes difficult if an update redirect keeps changing routing location. This is the main reason why a new key type and a modification to the FNP is needed for these two schemes. _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
