On 5/19/06, Ian Clarke <ian at locut.us> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I think this is much more complicated than we need, at least for an > initial implementation of RSKs. > > All we really need is to standardize on a "revoked" key within an SSK > that will be checked before Freenet returns the contents of the SSK, > an explanation can be published to the revoked key. Like USKs, an > RSK would be a thin wrapper around SSKs. > > This means that those with the right to publish to the SSK can revoke > it. If you don't trust someone enough to publish to an SSK, why > would you trust them enough to revoke it? > > I just don't think the use-cases that require voting, multiple > trustees, and so on are really all that likely in practice. > > Ian. > > On 19 May 2006, at 11:22, Matthew Toseland wrote: > > > RSKs will be implemented soon. Details: > > > > A "SIMPLE_REVOCABLE" metadata document contains: > > - A target URI. > > - A list of Trustee's > > - int: Minimum # biased votes to block the site > > - int: Minimum # votes to block the site > > - int: Minimum # biased votes to modify the RSK > > - int: Minimum # votes to modify the RSK > > - int: Maximum size of trustee explanations > > - boolean: HTML allowed in trustee explanations? > > > > A Trustee object consists of: > > - A USK URI for the Trustee's notifications. > > - int: Voting bias > > - String: Name of trustee > > - String: Comments on trustee > > > > When it reaches a SIMPLE_REVOCABLE, the node (the FCP client layer) > > will > > fetch all of the URIs for the trustees. It does not fetch them as USKs > > however; it fetches the first version first, and if that exists it > > fetches later versions until it runs out of versions. > > > > Normally, all the trustee URIs will produce DNF. However, sometimes > > they > > will return metadata documents of type REVOCATION_DETAILS. > > > > This consists of: > > - 1 byte: Trustee status code: > > KEY_BLOWN (0) = The RSK key is blown. > > NEW_KEY (1) = There is a new RSK. > > - URI: Explanation. > > - If status code == NEW_KEY, URI: New RSK. > > - If status code == KEY_BLOWN, optional URI: last known good version. > > > > If all the trustee URIs return DNF, then the user will not be alerted. > > If any of them have KEY_BLOWN, the user will be told, and shown the > > names of each trustee and their explanation's (in an iframe). The user > > is allowed to progress to the content anyway if he wants to. If enough > > trustees post KEY_BLOWN, they get a different (stronger) page. They > > can > > access the target if they want to, but only by manually copying a > > non-hyperlinked URI to the location bar. If enough trustees have > > NEW_KEY, with the same key, and none have KEY_BLOWN, then we send a > > permanent redirect to the new RSK location, and then process that. It > > must be an RSK. If the key is blown and there are enough votes for > > a new > > key, then we present the user with the key blown page, and with the > > new > > link on the bottom. > > > > The node will provide a reasonably easy way to post a revocation, via > > the web interface, and via FCP. > > > > Comments? Any way we can improve this? > > -- > > Matthew J Toseland - toad at amphibian.dyndns.org > > Freenet Project Official Codemonkey - http://freenetproject.org/ > > ICTHUS - Nothing is impossible. Our Boss says so. > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFEbg3EQtgxRWSmsqwRAkwCAJ9UyGRvZIIZ2qJM0/qSS7TbFWY6KwCeO+gm > HpJeHNs+uhlsVG0gtuHpr+M= > =9rBF > -----END PGP SIGNATURE----- > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
I like the initial post but as Ian say it is overkill at least for now. The problem is, how hard will it be to update it later to a better solution if needed? As far as I can see Matthew's proposal cover any possible case, including the one Ian argument for being the most likely which is probably is too, but it's not 95% of all cases.
