So as soon as I got home last night I remembered something. What may be helpful is that perhaps the content at the TUK contains both an expected update date as well as the content previously discussed. This way, if a TUK is retrieved after only a few hops, but the expected update date has not yet occurred, the value in that TUK version is used. However, if the expected update date has passed, another request goes out (at HTL 15? at an HTL specified in the SSK via TUK.updateSearchHTL=?), and the most recent TUK value is found. This way, TUKs won't necessarily be searched for at a full HTL depth always, but in the case that the TUK isn't retrievable or the suggested update date has passed, the full HTL will be used.
Also, I don't think the TUK content should be limited by fred to be a small size (e.g. 1k as discussed on IRC). For normal freenet publishing purposes, yes it should be severely limited when interpreted through the .UseTUK= metadata flag to be a single value ([0-9a-zA-Z]*), but I can imagine FMB and other similar systems using a single inbox or outbox containing their messages, rather than relying on the SSK@<key>,<entropy>/fmb/<date>/<slotNum> (yikes, I can't believe it took over a full hour for my post last night to go through. damn thee mailmain && / || cryptomail!) So, um, er, thoughts? -jrandom !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ CryptoMail provides free end-to-end message encryption. http://www.cryptomail.org/ Ensure your right to privacy. Traditional email messages are not secure. They are sent as clear-text and thus are readable by anyone with the motivation to acquire a copy. !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
