My current understanding of the plan for how TUKs will work is as follows: There is a new type of key TUK. It is not encrypted. It contains two 32bit integers, one for the current edition number, and one for the expected date of the next version. Then it contains the key for the manifest. And it is all signed with the sites private key.
So when a node makes a new request, it downloads the TUK, then the Manifest, then the Index page, then the images. It appears to me that this could be parallelized. First, instead of containing the key for the manifest, the TUK could include a section encrypted with the normal key that contained the information normally found in the manifest. This would mean, The node storing the TUK does not know the manifest key (of no real significance.), Applications like FMB that need a lot of manifests for messages or files can keep their existing scheme and use a single TUK to reference many of them., And when downloading a Freesite, you get the manifest along with the TUK, which means less network bandwidth used. Second, now that containers are implemented a prefetch tag could be added into the manifest. Containers are important because it means you can limit it to a single file. So if you have "index.html=CHK..... Prefetch=images.zip" the worst a malicious Freesite could do is make you download 1MB of useless data. (assuming you don't automatically start downloading splitfiles) _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
