Ok, lots of chatting on IRC today about updatable keys, spawned by "<toad_> we must do something about this silly edition site prejudice" Almost two hours later, I think we've got something.
Proposal: Add a new key type that supports secure sites that: - are like edition sites that can be bookmarked - are like DBR sites, but don't dissapear when they aren't inserted - doesn't allow people to delete their content - allows people to backtrack to old versions without much trouble Summary: There are two parts to the proposal - a new key type and some supporting metadata. The new Time Updatable Key (TUK) contains in its payload only the latest site edition number. The TUK itself is signed by the site's owner, and nodes throughout freenet have access to the update date through standard datastore/FNP mechanisms. Whenever a TUK collision occurs, the one with the latest timestamp wins, replacing the old version. So, here we are with a new key containing a value that can be updated. Typical (proper) usage would have the TUK contain an ever increasing edition number (or milliseconds since epoch, for you DBR fans). The way the TUK would be made useful would be by adding support for TUKs to SSKs, ala DateRedirect.UseTUK=true or Redirect.UseTUK=true The TUK itself is located at TUK@<pk>,<entropy>/<name>-TUK/ where <pk> and <name> are the same as from the SSK (this we didn't discuss on IRC, or maybe we did and I missed it. toad?) This way, when a site is inserted at SSK@<key>,<entropy>/<name>// containing Redirect.UseTUK=true, fred looks for TUK@<key>,<entropy>/<name>-TUK/ Once it finds a TUK it redirects the action to SSK@<key>,<entropy>/<TUKvalue>-<name>/ where TUKvalue is the content in the TUK. People can go to the beginning by attempting to fetch SSK@<key>,<entropy>/0-<name>/ (or, for that damn Colours author, SSK@<key>,<entropy>/f640c0-<name>/) While a malicious author attempting to make backtracking hard can do so (by not using monotonously incrementing 0 originated numbers as TUK values), normal freesite authors should have a link to their explicit edition (ala movable type permalinks): <a href="/SSK@<pk>,<entropy>/<TUKvalue>-<name>//index.html">this version</a> and a link to the bookmarkable, updating page: <a href="/SSK@<pk>,<entropy>/<name>//index.html">this site</a> The threat of Big Scary Dood coming over and forcing the normal freesite author to update their TUK pointing at content they don't approve of to a "cleansed" version is minimal, as reasonably normal people can decrement to previous version (e.g. SSK@<pk>,<entropy>/5-<name>// to SSK@<pk>,<entropy>/4-<name>//) Malicious TUK-based freesites however aren't necessarily so easy to decrement. Is there anything I've missed toad? Does anyone have any questions, problems, or suggestions? I know TUKs have been discussed off and on for long periods of time - does this address the qualms people had with previous proposals? This is all based on the point of view of the normal freesite development - anyone care to comment from the perspective of FMB/Frost? -jrandom (btw, I have the irc log from this afternoon discussing this that I can post up on a freesite (if toad has no objections). Its only 24k.) !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ 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
