[GNUnet-developers] update mechanism

[Martin Uecker]

Hi,

> | I can see some use for this. An update could be implemented by simply
> | defining another root-node R type that carries an signature from
> | the originator (say S_A(R)). The originator can then send an update
> | request using the key for the root-node (single-hash, not double or
> | triple-hash), T, the public key A and a signed new replacement block
> | R' which points to the updated file. We'll also want to add a timestamp
> | to ensure that we update in the right direction.
> | Still, how do you force a node to perform the potentially expensive
> | update operation (find block, verify sig, replace), how do you ensure
> | that the updates are propagated sufficiently long in GNUnet to reach
> | everybody but not too long? What is the (economic) incentive in doing
> | the update? The receiver could just add (keeping R and R') to its
> | set of keys and now have 2 replies to send as replies to a request.

The client can discard the old version if it recieves both as search
results. The reciever has an economic interest to not recieve stale
data.  He might adjust the reputation of the sender accordingly.

People will upload updated content anyway. Defining an update mechanism
gives each node the possibilty to learn about content which is stale and
worthless to the reciever. (There are cases where old versions should
remain on the network, but they can be handled easily by not using the
update mechanim.)

There is another reason for updatable content: It gives the author
control over his publications. This is a good thing. (usenet has a
similar policy for overwriting messages) [1]

Note: The author does not have any power to remove the content if there
is no consent that he should be allowed to do so because everbody can
just issue another R block. This is a goog thing too.


Martin


[1] idea: build a distributed news server on top of gnunet