>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 at blah/index.html
d. NodeA does not have any TUK at blah/index.html
e. NodeA stores it.
f. NodeA passes it to NodeB who does not have TUK at blah/index.html
g. NodeB stores it.
h. NodeC wants this content he heard about, TUK at blah/index.html
i. NodeC asks NodeA for TUK at blah/index.html
j. NodeC receives TUK at blah/index.html and stores TUK at 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 at blah/index.html with
timestamp
2:00am to NodeA
j. NodeA has an older version of TUK at blah/index.html, so it replaces the
old
TUK at blah/index.html with the new TUK at blah/index.html
k. NodeA cannot reach NodeB, so the new TUK at blah/index.html is not sent
l. NodeD wants TUK at blah/index.html now.
m. NodeD asks NodeB for TUK at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021129/7663fd3d/attachment.html>
