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.
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
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?
_______________________________________________
Tech mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/tech
