On Sat, Oct 29, 2005 at 11:14:18AM -0500, Conrad J. Sabatier wrote: > > On 29-Oct-2005 Matthew Toseland wrote: > > This has the architecturally nice property that only USK keys can > > ever change from one moment to the next, short of KSK replacement and > > other freak events. > > I like the idea, I'm just not sure it should be something to include in > 0.7. It seems there's enough radical change in the wind without adding > even more. :-) > > But then, another school of thought says, if you're making a bunch of > radical changes anyway, why not include this, too?
That's my opinion. We MUST NOT do another content reset before 1.0. Now, what is the practical upshot here? If we do this for 0.7.0, we can get rid of double slashes, and all clients, authors, and sites do not need to worry about updating ever again, from 0.7.0 If we do this after 0.7.0, then we can't get rid of double slashes before 1.0, and clients, authors, and sites, many of which will be new for 0.7, will have to initially use DBRs or edition sites, and then later on change to the new updating mechanism in 0.7.1. > > My main concern, really, is the potential loss of existing keys. > Anything that can be done to avoid this should definitely be given the > utmost consideration. If new key types, etc. can be safely introduced > while maintaining backwards compatibility, then great! Everything is getting zapped for 0.7. It's a content reset. Painful, but these things have to be done sometimes. > > I've missed out on so much of the discussion here due to that bitch > Katrina, I still have a lot of catching up to do, so do take any > comments of mine with a giant block of salt. :-) :) > > > On Sat, Oct 29, 2005 at 04:24:15PM +0100, Matthew Toseland wrote: > >> USK at .../CofE/1898/ is the site "CofE", last known edition, with 1898 > >> being a hint. If the node knows edition 2000, it will return > >> USK at .../CofE/2000/ (and fproxy is expected to do a redirect so that > >> the > >> client gets the right key). The node is expected to try to look for > >> the > >> next edition in the background. It will stop doing so after a > >> certain > >> period of the user not checking the site; it keeps an LRU. Also it > >> does > >> not fetch the whole site, it assumes that if it finds *something*, > >> that > >> is a valid site. > >> > >> SSK at .../CofE/1898/ is the site "CofE", exactly edition 1898, > >> assuming > >> that we keep the use of double slashes for manifests as it is now. > >> If we > >> get rid of double slashes and just use single slashes, then it would > >> be > >> SSK at .../CofE-1898/ . > >> > >> Implementation: > >> > >> When a client wants to insert an updatable site for the first time, > >> it > >> includes a flag on the FCP command to insert a site saying so. It is > >> strongly recommended that all site-internal links be relative URIs. > >> > >> The node will then insert the first edition as SSK at .../sitename/1/ > >> (or > >> SSK at .../sitename-1/ ). The inserted metadata will include an "update > >> manifest". This does not however require an extra hop, since it is > >> reproduced on each edition. This specifies that the site is an > >> updatable > >> site, and gives any low-level hints on how to find the next edition, > >> such as: > >> - A DBR automatically inserted by the node (possibly a hierarchy of > >> such > >> DBRs - e.g. year, month, week, day, hour) > >> - A TUK (why not just use TUKs? There are some possible issues with > >> TUKs, such as the fact that they all go through one key. Better to > >> use > >> it as a hint). > >> - The average frequency of updates (possibly quantised) > >> - etc. > >> > >> These are all optional, and we can upgrade them on an ongoing basis, > >> as > >> we have the ability to update the manifest. So in the initial > >> implementation, we wouldn't have to include any of the above. > >> > >> Comments? Is this a good idea? How important is it to get rid of > >> DBRs > >> and classic editions, compared to how important it is to ship 0.7.0 > >> ASAP? How important is it to get rid of the double slash system? > >> -- > >> Matthew J Toseland - toad at amphibian.dyndns.org > >> Freenet Project Official Codemonkey - http://freenetproject.org/ > >> ICTHUS - Nothing is impossible. Our Boss says so. > > > > > > > >> _______________________________________________ > >> Tech mailing list > >> Tech at freenetproject.org > >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > -- > > Matthew J Toseland - toad at amphibian.dyndns.org > > Freenet Project Official Codemonkey - http://freenetproject.org/ > > ICTHUS - Nothing is impossible. Our Boss says so. > > -- > Conrad J. Sabatier <conrads at cox.net> -- "In Unix veritas" > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20051029/bd327018/attachment.pgp>
