13 |
|
|
14 |
\begin{abstract} |
\begin{abstract} |
15 |
We present Storm, a storage system which unifies the |
We present Storm, a storage system which unifies the |
16 |
desktop and the public network. Storm assigns each document |
desktop and the public network, making Web links between |
17 |
|
desktop documents more practical. |
18 |
|
Storm assigns each document |
19 |
a permanent unique URI when it is created. Using peer-to-peer |
a permanent unique URI when it is created. Using peer-to-peer |
20 |
technology, we can locate documents even though our URIs |
technology, we can locate documents even though our URIs |
21 |
do not include location information. |
do not include location information. |
22 |
Links continue to work unchanged when documents are emailed |
Links continue to work unchanged when documents are emailed |
23 |
or published on the network. |
or published on the network. |
24 |
We have extended KDE to understand |
We have extended KDE to understand |
25 |
torm URIs. Other systems such as GNU Emacs are able to use Storm |
Storm URIs. Other systems such as GNU Emacs are able to use Storm |
26 |
through an HTTP gateway. |
through an HTTP gateway. |
27 |
\end{abstract} |
\end{abstract} |
28 |
|
|
75 |
.. non-breaking links seem not globally resolvable: |
.. non-breaking links seem not globally resolvable: |
76 |
|
|
77 |
A major obstacle to hypermedia |
A major obstacle to hypermedia |
78 |
on the desktop is broken links. A user receiving |
on the desktop are broken links. A user receiving |
79 |
hyperlinked documents by email, for example, would have to reconstruct |
hyperlinked documents by email, for example, would have to reconstruct |
80 |
the original directory structure; otherwise the links |
the original directory structure; otherwise, the links |
81 |
will not work. |
will not work. |
82 |
Many hypermedia systems |
Many hypermedia systems |
83 |
assume that identifiers either |
assume that identifiers either |
99 |
to be resolved on a global scale. |
to be resolved on a global scale. |
100 |
Balakrishnan et al. [balakrishnan03semanticfree]_ argue |
Balakrishnan et al. [balakrishnan03semanticfree]_ argue |
101 |
that DHTs are suitable for the next generation |
that DHTs are suitable for the next generation |
102 |
Reference Resolutions Services (RRS) [#]_. |
Reference Resolution Services (RRS) [#]_. |
103 |
DHTs can not only be used to efficiently retrieve documents, |
DHTs can not only be used to efficiently retrieve documents, |
104 |
but also metadata *about* documents. For example, |
but also metadata *about* documents. For example, |
105 |
unlike many link services that only query a limited |
unlike many link services that only query a limited |
106 |
set of servers for links [hill94extending]_, |
set of servers for links (e.g., [hill94extending]_), |
107 |
all published external links to a document can be found using |
all published external links to a document can be found efficiently using |
108 |
a DHT. |
a DHT. |
109 |
|
|
110 |
.. [#] Domain Name System (DNS, RFC 1101) is a widely used RRS |
.. [#] The Domain Name System (DNS, RFC 1101) is an RRS |
111 |
system in the Internet. |
system widely used on the Internet. |
112 |
|
|
113 |
.. Freenet's cryptographical identifiers: |
.. Freenet's cryptographical identifiers: |
114 |
|
|
118 |
Location-independent identifiers enable non-breaking links |
Location-independent identifiers enable non-breaking links |
119 |
on the desktop and the Web: |
on the desktop and the Web: |
120 |
When a document is published |
When a document is published |
121 |
on the Web, it would have the same URI as on the |
on the Web, it will have the same URI as on the |
122 |
author's local desktop; when a link to a document is emailed, |
author's local desktop; when a link to a document is emailed, |
123 |
the receiver could follow the link as long as their |
the receiver can follow the link as long as their |
124 |
software can locate the linked document-- on its local |
software can locate the linked-to document-- on its local |
125 |
harddisk, attached to another email, on the work group server |
harddisk, attached to another email, on a work group server |
126 |
or on the |
or on the |
127 |
public Internet. |
public Internet. |
128 |
In Freenet [freenet-ieee]_, an anonymous P2P |
In Freenet [freenet-ieee]_, an anonymous P2P |
129 |
publication system, *cryptographic hashes* [#]_ |
publication system, *cryptographic hashes* [#]_ |
130 |
are used for location-independent identifiers of |
are used as location-independent identifiers of |
131 |
documents versions. |
document versions. |
132 |
|
|
133 |
.. [#] A cryptographic hash |
.. [#] A cryptographic hash |
134 |
is short bit-string (often 160 bits) |
is short bit-string (often 160 bits) |
164 |
Storm (for STORage Module) |
Storm (for STORage Module) |
165 |
is a library for both local and distributed storage |
is a library for both local and distributed storage |
166 |
and publishing. |
and publishing. |
167 |
On the lowest level, storm handles data in *blocks* |
On the lowest level, Storm stores data in *blocks*, |
168 |
which are immutable byte sequences. |
which are immutable byte sequences. |
169 |
As opposed to filesystems, Storm uses |
As opposed to file systems, Storm |
170 |
uses Freenet-like cryptographic identifiers to |
uses Freenet-like cryptographic identifiers. |
|
manipulate the blocks. |
|
171 |
This may seem like a bad tradeoff: while these identifiers |
This may seem like a bad tradeoff: while these identifiers |
172 |
enable secure location-independent references, they |
enable secure location-independent references, they |
173 |
do not allow |
do not allow |
174 |
the documents referred to by the identifiers to change |
the identified documents to change |
175 |
and |
and |
176 |
are also less comprehensible for humans. |
are also less comprehensible to humans. |
177 |
However, these downsides are dealt with by the higher abstraction |
However, these downsides are dealt with by the higher abstraction |
178 |
levels |
levels |
179 |
of Storm. |
of Storm. |
184 |
of *pointer blocks* |
of *pointer blocks* |
185 |
to build mutable documents on top of |
to build mutable documents on top of |
186 |
the lowest layer append-and-delete-only model. |
the lowest layer append-and-delete-only model. |
187 |
A pointer block is simply a storm block which says |
A pointer block is a Storm block which says |
188 |
"The identifier X points to document Id, and this block overrides |
"The identifier *X* points to the current version of |
189 |
the previous pointer blocks a, b" and contains |
document *Y*, and this block overrides |
190 |
a digital signature of the above information. The pointer Id |
the previous pointer blocks *a, b*" and contains |
191 |
|
a digital signature of the above information. The pointer *Y* |
192 |
contains the public key used for signatures --- this allows |
contains the public key used for signatures --- this allows |
193 |
only the originator of the document to validate new versions. |
only the author of the document to validate new versions. |
194 |
A suitable user interface around pointers allows the user to |
A suitable user interface around pointers allows the user to |
195 |
still see old-style file names, but with the file names attached |
still see old-style file names, but with the file names attached |
196 |
to his/her person, not to a particular computer. |
to his/her person, not to a particular computer. |