Matthew Toseland wrote:
On Sat, Nov 09, 2002 at 06:38:58PM +0100, Thomas Leske wrote:
The argument against updateable keys was, that they would allow
to forcibly remove content from the network. But this is not
the case, if only the sequence number is updateable and the update
of the real data is just emulated.
No, this is not the problem preventing updatable SSKs.
I was talking about the problem, if one would make a new updateable
key type, that allowed the replacement of real data (removing the old).
Therefore I want to restrict its content to sequence numbers.
The keys for the real data are like those used for edition based
freesites:
SSK@.../foobar-1//
SSK@.../foobar-2//
...
The problem is, to find the current version.
It would be better to have a static key like:
SSK@.../foobar//
This retrieves a new kind of redirect to the key "SSK@.../foobar-"
followed by the number, that is found under a certain updateable key,
and "//". (You could implement ARKs the same way.)
The updateable key is determined by a public key.
Valid contents are: a positive integer number and a signature for
that number. For the number 0 the signature is omitted.
Contents with higher numbers are more current than those with lower
numbers.
Requests and inserts are not distinguished. They contain the
following Data:
public key
number with signature
The reply contains:
the same or a higher number with signature
How a node handles a request/insert:
1) Determine whether the signature is valid (except for the number 0).
2) Replace the old data and the old data source, if the number is higher.
3) If it was, then ignore the failure table.
4) Propagate the request/insert:
- for each reply, execute steps 1 and 2
Requests would have to always go the full hops to live. This makes them
slow, and introduces huge overhead relative to edition based sites.
No, as stated in 3), a node ignores the failure table only, if it sees a
newer key in the request. This is meant to propagate the new key.
5) Send the reply
6) If a higher value than the one in the request was returned,
then count that as a use of the data.
(Increase popularity of the data in the data store.)
The first routing step must be random, in order to avoid that requests
get stuck at the same evil nodes over and over again, that always
return outdated numbers.
There is no overhead compared to conventional edition based freesites,
because the authors can save the image link to the next edition.
What do you think about that?
How do you ensure that all nodes find out about an update?
It is not ensured. An outdated answer to a query for an updateable key
is like a failure for a conventional key.
_______________________________________________
Tech mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/tech
