[freenet-dev] (no subject)

[Erendil]

>quote<
We simply give each file (in an SSK/CHK) a timestamp (in GMT), then, when a
person access their SSK to upload, the nodes which receive the files briefly
compare the timestamp. The newer timestamped file overwrites the older
timestamped file in the data store, and when it is requested, the new file
will be present and sent. Eventually, the old file will dissapear as more
nodes are updated. Still, no one knows who uploaded it (you might be passing
along an update), and since no one knows who uploaded it, no one can be
pressured to remove/update/censor it. Only the creator will know who uploaded
it, and thus only they will be able to change it. This would allow a
substantial amount of extra freedom on freenet.
>end quote<

I think we've gotten lot's of ideas, but some of them don't seem to answer my concerns (and everyone else's.)

I'm going to rewrite the idea above:

a.    A person wishes to upload file somefile.html
b.    He uploads somefile.html with the extra metadata
             1.    current time GMT of the original upload
c.    We call this a TUK (Time Updatable Key ...Better name?)
d.    These can be like an SSK (private/public keys...I don't know.)
e.    When a node receives a TUK, it checks to see if it has that TUK already.
             1.    If the node has the TUK
                    a.    and the time on the stored TUK is newer than
                           the time on the TUK received, it does not replace the
                           stored version with the received version
                    b.    and the time on the stored TUK is older than
                           the time on the TUK received, it replaces the
                           stored TUK with the received TUK (and the content)
             2.    If the node does not have the TUK it stores it
f.     If a node receives a request for a TUK
             1.    If the node has the TUK, it sends it.
             2.    If the node does not have the TUK, the search algorithm continues
                    as normal.
g.    This brings up the following
             1.    We may have multiple timestamped copies of a TUK on freenet
                    at any given time
             2.    Whenever a newer copy is found, the older copy is removed
             3.    The precedence of new over old means that if content is popular
                    it will be updated quickly
             4.    If content is unpopular, it will be updated slowly and eventually
                    die out anyways
             5.    Whenever any copy is found, it will be returned, thus avoiding
                    massive waiting times.

Ok, now, I'm going to go through a possible sample of TUK insertation and request, minus the date part of the timestamp as there is no need for that in a simple explanation.

a.    Alabaster has index.html
b.    Alabaster uploads index.html as a TUK with time 1:00am to NodeA
c.    We will refer to this key as TUK@blah/index.html
d.    NodeA does not have any TUK@blah/index.html
e.    NodeA stores it.
f.     NodeA passes it to NodeB who does not have TUK@blah/index.html
g.    NodeB stores it.
h.    NodeC wants this content he heard about, TUK@blah/index.html
i.     NodeC asks NodeA for TUK@blah/index.html
j.     NodeC receives TUK@blah/index.html and stores TUK@blah/index.html
h.    Alabaster wants to add his new blog entry so he changes index.html.
i.     Now, Alabaster uploads index.html as TUK@blah/index.html with timestamp
       2:00am to NodeA
j.     NodeA has an older version of TUK@blah/index.html, so it replaces the old
       TUK@blah/index.html with the new TUK@blah/index.html
k.    NodeA cannot reach NodeB, so the new TUK@blah/index.html is not sent
l.     NodeD wants TUK@blah/index.html now.
m.   NodeD asks NodeB for TUK@blah/index.html. It receives the old one (1:00am)
       and stores it.
n.    NodeB decides it wants to read this phenomenon also. So it remembers that
       NodeA has it. It gets the new TUK@blah/index.html and replaces the old
       one.

In this cycle, several nodes were updated with the new content.
However, each node must eventually request the new content, or the new content will not be circulated, leaving only the old content. This is basically, the content becomes unpopular and it becomes stagnant, eventually dying out.
The unrealistic element of this is that Alabaster would not send it to one node in the first place. Many nodes would receive it, making the new content available quickly.

Alabaster

P.S.      I know it's long, but I was trying to explain every step. I didn't include the receiving of old content, but that's fairly self explanatory after my examples. And, you may hate my suggestions, but I think they're reasonable and they uphold the idea of popular content being more easily available than unpopular content.