Do we want TUKs in 0.7.0? If we implement TUKs now, then: - We have them in 0.7.0. - We don't have to implement DBRs. - The content reset coincides with the death of the old DBR and edition formats. We won't get another one before 1.0, unless something drastic happens. - We can change the format of URLs to make manifest lookups correspond to single slashes, like on the rest of the internet, without having to worry about it breaking edition sites.
Issues: - The basic functionality of a TUK is a fairly simple extension to an SSK. Simply give it a version number, and possibly an expiry time. - In order for TUKs to scale, we will need to not pass on *most* TUK requests all the way to the end node; there are some caching issues, these are probably straightforward. - TUKs are vulnerable because all versions of a TUK have the same routing key and are cached on the same node. A malicious node can, for example, only return old versions of the TUK. And they create a "bottleneck". For some uses, e.g. frost, this may be a problem. Future more web of trust based frost implementations might have one queue for each user, in which case the bottleneck isn't a problem. - It may therefore be necessary to combine TUKs with some other form of updatable keys... For example: We could have a metadata level editions system. The node could keep a last-known-edition for each site, and search for the latest edition via binary-ish searches etc. The l-k-e could be updated by hints seen in links to the site, or by a TUK, which could be updated by the metadata for the site itself (if this was not disabled by the update manifest). TUKs would still be very useful in such a system, but they would only contain an edition number, and could be replaced if necessary. The above would work well with passive requests - the node could subscribe to the next few expected editions. I suppose the conclusion is that TUKs are useful right now, even if we don't do the rest, which may not be necessary... it would be very easy for an attacker to selectively censor a TUK based system, without blocking it completely, that is my concern; on a freesite this would be detectable, but on an open forum it wouldn't be, although an open forum will be spammed to hell anyway... (frost etc should use one queue per known client and exploit its web of trust, and only use the public queue for anonymous hashcashed introductions; the problem is that without passive requests, this would put a ludicrous amount of load on the network). But are they worth it? Well, what do we need to do to implement TUKs? A TUK is: - An SSK - With a version number - Possibly a timestamp?? - Any number of different versions of the same key can persist in the datastore at once. - And optionally a "don't recheck before" time - And optionally a recheck period - Major optimizations: -- Don't recheck before the above time. -- Don't recheck more often than the recheck period A TUK request is: - A request for an SSK. - It can ask for a specific version of a TUK, or the latest version, or all versions available (within sane limits!). - It can continue even though it has found the data. - It doesn't always do so. So: - Need to implement SSKs first. SSKs are vital for 0.7.0 anyway. - Probably store all SSKs as TUKs. - Some changes to the datastore. It is still LRU, but you can fetch the latest version of a given TUK, all versions, all versions after a given one, or a specific version. In each of these cases all fetched data is promoted in the LRU. - I still think it may make sense to have small (1kB?) SSK's/TUK's - possibly in addition to 32kB SSKs. This would be useful for many uses of TUKs, and some later options for streams. - Small changes to request logic. I'm uncertain - a content reset is probably a good time to introduce TUKs, and they don't seem that difficult (the historical reason for not doing them has been simply that routing hasn't worked), on the other hand, it will definitely delay 0.7.0. -- 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/20051028/8fcaf8eb/attachment.pgp>
