On Sun, Mar 12, 2006 at 12:58:05PM +0100, nacktschneck wrote: > > However IMHO, some form of updatable keys ARE vital for the alpha, so I > > will implement USKs on Monday. > > I'm really looking forward to this. Being not able to easily update > content under the same key was a showstopper in 0.5 from user > perspective, and it was not a good idea to solve the problem on the > application level with dbrs or edition based inserts. > > > I don't believe this will take more than > > a day and a half to implement and debug, but it would be a significant > > improvement on DBRs, with huge potential for future improvements. > > 1 1/2 days sound a little optimistic for me, if it is meant to include > debugging on the real test network. Will this include only > edition-based USKs or date based ones as well? What's your strategy > for finding out the most recent edition of a key without having to do > lots of fetches in the background?
Okay, I'll try to spec this out a bit. Maybe I was being a little too optimistic. But IMHO it is important to have USKs for the first alpha. For simple automated editions ----------------------------- The key isn't necessarily the same. What happens (with pure automated editions): USK at .../CofE/34/ means "the latest known edition, but at least edition 34". This is assumed to exist, until established otherwise; if the node does not know about USK at .../CofE/, then it will return edition 34 and schedule some fetches. USK at .../CofE/0/ means "the latest known edition". If the node doesn't know about USK at .../CofE/, it will try to get an edition - any edition - starting from 0. USK at .../CofE/-34/ means "the latest edition, at least 34, and you can take ages to find it, and verify it". SSK at .../CofE-34/ means "exactly edition 34". Note that this isn't a USK! Note also that we can't use the slash to separate the edition from the site, because a slash normally denotes a manifest lookup. I expect normally people will link to the positive versions. Now, why does this help us? Because Fproxy will pick up on edition updates and send a 304 (permanent redirect) to the new URL! This will modify the actual URL in the browser's location bar, and in theory should also update URLs in stored bookmarks. If the user thinks that the page is too old, he can reload the page to see if there is a more recent version, or make the USK negative. Or, possibly more realistically, he can watch the fproxy user events page. Any recently visited USK site is automatically subscribed to, and if updates are detected which have not been browsed, a notification will be sent to the user updates page. With hierarchical DBRs ---------------------- We publish, for a USK, a hierarchy of DBRs: - this year - this quarter - this month - this week - today - this quarter-day - this hour - this quarter-hour If any of these exist, they will give us an index into the sequence, to a specific edition number. Now, how do we actually implement this? Bear in mind that these are 1kB SSKs. We can fetch all of them at once without imposing a huge load on the network. We may want to start at the bottom, fetching first the quarter-hour DBR, then if that fails, the hour DBR etc. We will do the inverse for inserts. But probably we will just fetch all of them. If we get a /0/ request, we look up the DBRs, and don't return until we have got the DBR. If we get a /-<number>/ request, we look up the DBRs, and don't return until we have got the DBR, and have checked the next few slots for updates (negative implies a thorough, and slow, search). If we get a /<positive number>/ request, we look up the DBRs, but in the background, returning immediately with whatever we have already. Prefetch -------- We may want to detect USKs in a web page at the point of sending it to the browser, and start searching for them at that point. This would improve speed and accuracy. > I'll be back online tomorrow evening and could help with some testing. > I'm really intersted in having working USKs ASAP. > > Gru?, > nacktschneck -- 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/20060313/f4199348/attachment.pgp>
