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. -------------- 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/devl/attachments/20060519/949b5d42/attachment.pgp>
