[GNUnet-developers] Other way to updateable content

[Igor Wronsky]

On Sun, 26 Jan 2003, Tom Barnes-Lawrence wrote:

>  That's the main thing. Whether or not *some* of the content wouldn't
> be updatable isn't really a problem to me- as long as at least some of
> it can be updated, that concept of a growing www-like network of references
> I'm so keen on can become a reality (one way or another).

Ok, while taking a shower I came up with a simpler scheme for
allowing updateable content. Some of you will probably scream
"noo!!!!", but please read my whole argument.

The main idea is very simple: let us allow rewriting of the
entry point - and nothing else. Have a special block like
(namespace,pointer_to_actual_data,serial#,signature).
When wanting to modify something, increment serial# and change
pointer_to_actual_data. Insert actual data and the new
entry point. When searching, do query like query(namespace,
serial#>=wanted). When node gets this query, it'll look
if local data store has anything matching the requirements.
If yes, it will return the data AND forward the query,
this time requiring serial#>localserial#. If not, just
forward as-is. When receiving data from some other node,
the signature is checked, if it matches, write to disk,
overwriting everything with serial# less than this, and
send reply to whoever originally requested.

There might be technical problems, but the main problem
people will see, is political, mainly censorship: what if a nasty
person gets hold of the secret key and tampers with the entry
point? I have two answers. First: no actual content can be
censored even if this is allowed. Anyone can have linked to the
content, or made a list of their hashes someplace. Second: the
tampering is already possible in edition-based mechanism,
in a way that we can't trust anything except the "first edition"
to come from the original author. And in addition, note
that we are not *forcing* anyone to use a rewritable entry-
point. Someone w/ ultraparanoia on can always insert
a "perpetual" entry point pointing to some fixed data.

The gain of this method is very simple: the author can
publish the modifications whenever he likes, the modded
entry point replaces the old ones automatically, and
this can be done quite transparent to the end user
(except maybe with some "hey I found a even more recent
version" -interruptions).

Also this can probably be integrated easily to the current
namespace proposal without requirement for a new block type,
a flag (bool rewritable) probably suffices.

Comments?


ps. Christian, you sounded mildly sceptical of the fproxy
issue. However, such a scheme is quite popular in freenet,
and gives it atleast some community feeling. If gnunet
can be competitive with freenet in transferring raw
data, there is no reason why the fproxy wouldn't work
as good or better in gnunet env.


Igor