Some parts of this message have been removed.
Learn more about Nabble's security policy.
I've been trying to understand how namespaces are supposed to support updates.
As I understand it, a namespace advertisement contains a string called the root, which can be used in a namespace search. A result of a search of a namespace may contain a string which can be used for a subsequent search, and it looks like the search code will initiate a search using this string automatically.
Thus one could post a file under the keyword A with next_id set to B, and subsequently publish a file under keyword B with next_id set to C, and finally publish a file under keyword C. This would allow someone to find all three files using repeated searches starting with A. The question is: how does this differ from publishing all three files under the keyword A? In terms of speed, a single search for A is likely to be faster than performing a series of searches starting with A. In terms of completeness, the answer is less clear. Possibly a chain of searches would be more likely to locate all the files, because each search only has to produce one result. On the other hand, a single failed search in the middle of chain means that none of the files in the rest of the chain will be found, so I would suspect that the odds of the search finding *most* of the files would be higher with a single keyword search than with a chain once the chain reached a certain length.
If the above mechanism provides a way to perform updates, I don't see it. When the ECRS paper states that, "since SBlocks are signed, it is possible to allow updates," the point is that updating an existing file involves deleting the old version, so we want the originator of the content to be able to do that, without allowing anyone else to do so. A scheme to do this might work as follows:
Allow an SBlock to include a 16 bit version number. (For backward compatibility, the version number is optional, and an omitted version number is equivalent to a version number of zero.) The rules for dealing with version numbers are:
1) Any time a host sees an SBlock with a given version number, it gets rid of versions of the SBlock with lower version numbers.
2) A host does not earn trust for supplying an obsolete version. This means that if a host is doing a search, gets one version of an SBlock, and then receives a later version, it should revoke the trust credited to the host that provided the older version and give it to the host that provided the newer version. This rule means that there is no incentive for hosts to keep old versions around.
3) If a host receives an obsolete version of an SBlock, it can request a refund of the trust expended on the search by sending a more recent version of the SBlock. This requires a new message type. This rule means that hosts which have cached obsolete SBlocks are likely to be provided with updated versions of those SBlocks. (Otherwise, a host might cache an obsolete version of an SBlock indefinitely, since it would receive periodic search requests that matched it.)
To allow a user with a given version of a file to see if a more recent version of the file exists, we need a variant of the keyword search which specifies the minimum version number that is being searched for. It would be conceptually simplest to say that a search with a version number of N would return any version greater than or equal to N. To allow for reasonably efficent Bloomfield filtering, I would suggest that a search specifying version number 0 should query the data base for any version of the file, and a search with a nonzero version number N should query for versions N through at least N+4.
Versioning only applies to search records. Since DBlocks and IBlocks may be shared by different files, I don't see any way to explicitly get rid of the IBlocks and DBlocks from an obsolete version of a file. Once the obsolete version of the file no longer shows up in searches, there will be no more requests for the IBlocks and DBocks (unless they are, in fact, shared by a different file), and they can be pushed out of caches to make space for blocks thare are being requested.