48 |
have lost interest.>>> |
have lost interest.>>> |
49 |
|
|
50 |
We don't propose that every byte of information ever published |
We don't propose that every byte of information ever published |
51 |
on the Web should have to be kept around forever. However, |
on the Web has to be kept around forever. However, |
52 |
we do believe that as long as someone does keep a copy, |
we do believe that as long as someone does keep a copy, |
53 |
data should remain accessible, and links should continue |
data should remain accessible, and links should continue |
54 |
to work. |
to work. |
65 |
like cryptographic hashes. |
like cryptographic hashes. |
66 |
A file identified by a cryptographic hash |
A file identified by a cryptographic hash |
67 |
can be downloaded from any server that has a copy; the client |
can be downloaded from any server that has a copy; the client |
68 |
can then check it is the correct file by checking the hash. |
can then check the integrity of the file by checking it against the hash. |
69 |
|
|
70 |
.. <<<Self-verifying means that given the identifier and a file, |
.. <<<Self-verifying means that given the identifier and a file, |
71 |
a client can check that the file matches the identifier.>>> |
a client can check that the file matches the identifier.>>> |
78 |
is not viable on a global scale: |
is not viable on a global scale: |
79 |
"[I]f you put information in a name, it decreases its longevity; |
"[I]f you put information in a name, it decreases its longevity; |
80 |
if you don't you can't dereference it to a resource." |
if you don't you can't dereference it to a resource." |
81 |
However, as we have observed in [fallenstein03storm]_, |
|
82 |
with the advent of |
However, as observed in [fallenstein03storm]_, |
83 |
efficient peer-to-peer lookup mechanisms such as |
with the advent of efficient peer-to-peer lookup mechanisms such as |
84 |
distributed hashtables (DHTs), this observation |
distributed hashtables (DHTs), this observation |
85 |
is no longer true. |
is no longer true. A DHT is quite able to resolve a |
86 |
|
hash-based identifier on a global scale, |
87 |
|
as evidenced by applications like the Cooperative |
88 |
|
File System (CFS, [dabek01widearea]_) and |
89 |
|
the Overnet file sharing client [overneturl]_. |
90 |
|
|
91 |
|
.. SFR (semantic-free referencing) not all that close, |
92 |
|
though semantic-free idea shared (SFR takes along |
93 |
|
many problems of the Web) |
94 |
|
|
95 |
Using DHTs |
.. <<<(Using DHTs |
96 |
to resolve location-independent identifiers on the Web |
to resolve location-independent identifiers on the Web |
97 |
has been proposed by Balakrishnan et.al. |
has been proposed by Balakrishnan et.al. |
98 |
[balakrishnan03semanticfree-andalso-walfish03dns]_. |
[balakrishnan03semanticfree-andalso-walfish03dns]_. |
99 |
|
However, in their work, the location-independent identifier |
100 |
|
merely points to a Web server administered by the publisher |
101 |
|
of a Web page; if the original publisher discontinues |
102 |
|
maintenance of the page, it would still drop off the Web.)>>> |
103 |
|
|
104 |
.. Proposal: A location-independent Web (closest thing is Freenet (ref)) |
XXX move to related work? |
105 |
|
|
106 |
|
.. Proposal: A location-independent Web <<<(closest thing is Freenet (ref))>>> |
107 |
|
|
108 |
We propose, then, to build a location-independent Web |
We propose, then, to build a location-independent Web |
109 |
based on self-verifying identifiers. |
based on self-verifying identifiers. |
110 |
|
|
111 |
The project that is currently closest to this goal is Freenet, |
.. <<<The project that is currently closest to this goal is Freenet, |
112 |
a XXX |
a XXX>>> |
113 |
|
|
114 |
.. Benefits of hash-based addressing: |
.. Benefits of hash-based addressing: |
115 |
- Pages easily movable between servers |
- Pages easily movable between servers |
120 |
- Verifiable |
- Verifiable |
121 |
- Same namespace for local and for non-local data |
- Same namespace for local and for non-local data |
122 |
|
|
123 |
.. SFR (semantic-free referencing) not all that close, |
Using hash-based addressing in such a scheme has several benefits: |
|
though semantic-free idea shared (SFR takes along |
|
|
many problems of the Web) |
|
124 |
|
|
125 |
.. Other projects exploit some of the advantages of hash-based |
- Pages can be moved between servers without breaking links. |
126 |
|
- Links continue to work as long as *anybody* keeps a copy |
127 |
|
of their targets, even if the original publisher does not |
128 |
|
maintain the Web page any longer. |
129 |
|
- Downloaded files can keep their global identifiers. |
130 |
|
Links between two downloaded Web pages automatically work. |
131 |
|
- It is possible to implement load-balancing schemes in which |
132 |
|
a user downloads a page from anybody who happens to have a copy. |
133 |
|
- Different networks can be used to download a file. XXX |
134 |
|
|
135 |
|
.. <<<Other projects exploit some of the advantages of hash-based |
136 |
(storage systems: CFS, PAST; web caching: Squirrel), |
(storage systems: CFS, PAST; web caching: Squirrel), |
137 |
but don't address the Web. |
but don't address the Web.>>> |
138 |
|
|
139 |
.. The infrastructure behind CFS, PAST and Squirrel: Peer-to-Peer |
.. <<<The infrastructure behind CFS, PAST and Squirrel: Peer-to-Peer>>> |
140 |
|
|
141 |
.. Quite recently, several Peer-to-Peer architectures have been |
.. <<<Quite recently, several Peer-to-Peer architectures have been |
142 |
proposed that use hash-based, loc.ind. ids |
proposed that use hash-based, loc.ind. ids>>> |
143 |
|
|
144 |
.. Possibility of desktop integration in ways that the location-dependent |
.. Possibility of desktop integration in ways that the location-dependent |
145 |
Web cannot archieve, through the novel combination of |
Web cannot archieve, through the novel combination of |
148 |
.. However, there's a problem with this: versioning ----- |
.. However, there's a problem with this: versioning ----- |
149 |
Basic problem: Hash-based addressing allows no updates |
Basic problem: Hash-based addressing allows no updates |
150 |
|
|
151 |
|
However, a document refered to by a cryptographic hash |
152 |
|
can obviously not be changed (without making it a different document, |
153 |
|
refered to by a different hash). For most Web pages, this is not |
154 |
|
acceptable [#academic-articles-hashlinking]_. In this paper, |
155 |
|
we examine solutions to this problem that keep the desirable properties |
156 |
|
of hash-based addressing. |
157 |
|
|
158 |
.. Contributions; structure of this paper ---- |
.. Contributions; structure of this paper ---- |
159 |
|
|
160 |
.. Main contrib: Pointer records for implementing updating |
.. Main contrib: Pointer records for implementing updating |
161 |
|
|
162 |
|
The main contribution of our paper are *pointer records*. |
163 |
|
A document is identified by a *pointer*, the hash of a |
164 |
|
public key. A pointer record is a file signed by the |
165 |
|
corresponding private key, containing the pointer's identity, |
166 |
|
the hash of a version of that document, and a timestamp. |
167 |
|
The newest version of a document is obtained by searching |
168 |
|
the peer-to-peer network for all pointer records associated |
169 |
|
with this pointer, and picking the newest one. |
170 |
|
|
171 |
|
This scheme is quite close to OceanStore's concept of |
172 |
|
*heartbeats*. However, the difference is that in OceanStore, |
173 |
|
heartbeats are controlled by an inner circle of servers, |
174 |
|
the *primary replica*, chosen by the owner of the document. |
175 |
|
In this scheme, when a document ceases to be maintained |
176 |
|
by its primary replica, it is impossible/becomes harder/*what*?XXX |
177 |
|
to retrieve the newest version of the document. |
178 |
|
|
179 |
|
(XXX IS THIS TRUE?) |
180 |
|
|
181 |
.. Other contribs: |
.. Other contribs: |
182 |
- The idea of a location-independent Web including |
- The idea of a location-independent Web including |
183 |
location-independent version management |
location-independent version management |
184 |
- Diffs |
- Diffs |
185 |
|
- Permanent signature scheme sketch |
186 |
|
|
187 |
|
In addition to pointer records, this paper XXX |
188 |
|
|
189 |
|
.. Structure of this paper |
190 |
|
|
191 |
|
The remainder of this paper is structured as follows. |
192 |
|
In Section 2, we review related work in version management, |
193 |
|
and find that existing peer-to-peer versioning systems |
194 |
|
do not provide the benefits of hash-based addressing. |
195 |
|
In Section 3, we introduce our fundamental, hash-based data model |
196 |
|
for a location-independent Web. In Section 4, we propose |
197 |
|
a versioning system built on top of this data model. |
198 |
|
In Section 5, we introduce a scheme for storing only |
199 |
|
the differences between versions that works with our |
200 |
|
basic data model, making the storage of past versions |
201 |
|
more economical. In Section 6, we outline solutions |
202 |
|
to the permanency issues raised by the use of |
203 |
|
cryptographic keys (which may be stolen or lost). |
204 |
|
Section 7 concludes. |
205 |
|
|
206 |
|
|
207 |
|
|
208 |
Related work |
Related work |
374 |
.. [#rtg-links] ``http://www.seds.org/spaceviews/cassini/rtgpages.html``. |
.. [#rtg-links] ``http://www.seds.org/spaceviews/cassini/rtgpages.html``. |
375 |
All links dereferenced on October 27th, 2003. |
All links dereferenced on October 27th, 2003. |
376 |
|
|
377 |
|
.. [#academic-articles-can-use-hashlinking] A notable exception |
378 |
|
may be academic articles, in which references to other articles |
379 |
|
are ideally to an immutable version, and in which references |
380 |
|
are generally not circular, making this domain map neatly |
381 |
|
to the properties of hash-based referencing. |