Brandon's idea about filtered requests gave me an idea of how
to implement updatable documents without resorting to any form
of broadcasting.
The keys themselves are a digital signature of a text identifier.
The Nym is stored as a CHK-referenced document whose contents are
the public key of the signer and any metadata he chose to include.
Inserting:
The initial and subsequent Request.Insert messages contain the key
(which is the same for all revisions), the text identifier from which
the key was made in a PlaintextKey field, a revision number in a
Storable.DocumentRevision field, and the CHK of the signer's public
key in a Storable.DocumentSigner field. As the request is routed
normally, each node that does not choose to be the storage node may
(and should) record in its permanent storage the key, signer key,
and revision number (but not plaintext key or the document itself).
These may be used by later requests as detailed below. The node
that does store the document does the same, but also sends the
Reply.Insert message if it verifies that the key is in fact the
signature of the plaintext key with the signer's public key. This
is the important part: at any point in this route, the presence of
a document or record of a document with the same key but lower
revision number should be treated the same as the absence of the
document; and in fact, if a node contains an earlier revision of
the document it should be deleted and replaced with the new one.
Requesting:
This is trickier, but I think it makes the scheme work: Request.Data
contains the key, and the StorableDocumentRevision field with the
latest revision the requestor knows about ("1" if it knows nothing).
The request _never stops early, but always takes every hop specified
in its HopsToLive_. This is not a "broadcast", but more like a "probe",
in that it is still directed. At each hop, if an instance of the
document is found, a field RevisionFound is created or updated that
contains the highest revision number found to that point in the route.
Each node can also use the revision number it recieved to update its
record of the latest revision of that document. When the Hops are
exhausted, the final node sends a Reply.NotFound message as usual back
along the route. As each node forwards this reply back to the
requestor, the node (if any) that had previously contained the latest
document (and it knows this because the RevisionFound matches what
it put there), takes the Reply.NotFound and changes it to Reply.Data
for the rest of the route home (of course, this might happen to be
the same as the final node in which case no Reply.NotFound is ever
sent). As usual with all these messages, nodes update their records
of the latest revision as they forward messages.
Will this work as I think it does?
--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
