21 |
|
|
22 |
We propose *pointer records*, |
We propose *pointer records*, |
23 |
signed files containing a document's id, |
signed files containing a document's id, |
24 |
its current version's hash, and a timestamp. |
its current version's hash, and a timestamp, |
25 |
Pointer records are shared and sought for |
which can be shared and sought for |
26 |
through the network like ordinary files. |
through the network like ordinary files. |
27 |
We also present the Storm data model, |
We also present the Storm data model, |
28 |
an API for P2P networks and other kinds of storage |
an API for P2P networks and other kinds of storage |
33 |
can have the same URI while residing on any host on any network. |
can have the same URI while residing on any host on any network. |
34 |
Past versions of a web page |
Past versions of a web page |
35 |
remain accessible as long as anybody keeps a copy. |
remain accessible as long as anybody keeps a copy. |
36 |
|
|
37 |
We discuss our preliminary implementation |
We discuss our preliminary implementation |
38 |
as well as possible applications of pointer records |
as well as possible applications of pointer records |
39 |
and the Storm data model outside the P2P Web. |
and the Storm data model outside the P2P Web. |
68 |
benefits from hash-based addressing)--- |
benefits from hash-based addressing)--- |
69 |
|
|
70 |
If the Web worked like a filesharing system, there would be |
If the Web worked like a filesharing system, there would be |
71 |
no central point of failure for a web page; it could be downloaded |
no central point of failure for a web page; a page could be downloaded |
72 |
from any host that has a copy. This would save bandwidth |
from any host that has a copy. This would save bandwidth |
73 |
and increase availability. However, if the Web worked like |
and increase availability. However, if the Web worked like |
74 |
a filesharing system, web pages could not be updated. |
a filesharing system, web pages could not be updated. |
87 |
that do offer an update mechanism. *CFS* [dabek01widearea]_ |
that do offer an update mechanism. *CFS* [dabek01widearea]_ |
88 |
is a file system based on Chord [stoica01chord]_, storing |
is a file system based on Chord [stoica01chord]_, storing |
89 |
data in a distributed hashtable (DHT). CFS identifies |
data in a distributed hashtable (DHT). CFS identifies |
90 |
different users' trees by the users' cryptographic keys; |
different users' directory trees by the users' cryptographic keys; |
91 |
it stores in its DHT mappings from these keys to the |
it stores in its DHT mappings from these keys to the |
92 |
the current version of the tree. A node participating |
the current version of the tree. A node participating |
93 |
in the DHT will update a mapping if the update message |
in the DHT will update a mapping if the update message |
156 |
replica ceases to function, the current version cannot be |
replica ceases to function, the current version cannot be |
157 |
determined any longer (for some applications, this only happens |
determined any longer (for some applications, this only happens |
158 |
30 seconds after the primary replica disappears). |
30 seconds after the primary replica disappears). |
159 |
In Freenet, this isn't possible anyway; files only |
In Freenet, files only |
160 |
remain on-line as long as they are requested regularly. |
remain on-line as long as they are requested regularly in any case. |
161 |
In the Content-Addressable Web proposal, the situation |
In the Content-Addressable Web proposal, the situation |
162 |
is the same as on the current Web. |
is the same as on the current Web. |
163 |
|
|
217 |
an API formalizing the notion of searching for data |
an API formalizing the notion of searching for data |
218 |
by hash and content. The API is used by applications |
by hash and content. The API is used by applications |
219 |
such as browsers and implemented for each P2P network |
such as browsers and implemented for each P2P network |
220 |
accessed. Pointer records can be implemented |
accessed. Pointer records may be implemented |
221 |
on top of the Storm model, rather than separately |
on top of the Storm model, rather than separately |
222 |
for each P2P network. |
for each P2P network. |
223 |
|
|
241 |
In Section 2, we introduce pointer records. |
In Section 2, we introduce pointer records. |
242 |
In Section 3, we present the Storm data model. |
In Section 3, we present the Storm data model. |
243 |
In Section 4 we discuss some applications |
In Section 4 we discuss some applications |
244 |
of pointer records, and Section 5 gives an overview of our |
of our contributions, and Section 5 gives an overview of our |
245 |
implementation. Section 6 concludes. |
implementation. Section 6 concludes. |
246 |
|
|
247 |
|
|
260 |
because it *points* to different versions |
because it *points* to different versions |
261 |
(identified by hash) over time. |
(identified by hash) over time. |
262 |
|
|
263 |
The pointer id is the hash of the pointer's *charter*, |
As the pointer id, we use the hash of the pointer's *charter*, |
264 |
a file including identification information for the pointer's owner, |
a file including identification information for the pointer's owner, |
265 |
the entity that has change control over the document. |
the entity that has change control over the document. |
266 |
This can be the owner's public key, or information about the CA |
This can be the owner's public key, or information about the CA |