2 |
Versioning for a location-independent Web: Stopping the shoulders of giants from rotting away |
Versioning for a location-independent Web: Stopping the shoulders of giants from rotting away |
3 |
============================================================================================= |
============================================================================================= |
4 |
|
|
5 |
.. (tentative title) |
META: |
6 |
|
|
7 |
|
(tentative title) |
8 |
|
|
9 |
Title suggestions and comments: |
Title suggestions and comments: |
10 |
|
|
13 |
Works even in ad hoc environments |
Works even in ad hoc environments |
14 |
... |
... |
15 |
|
|
16 |
|
Important issue: the main message. Is it: |
17 |
|
|
18 |
|
This is a nice way to do versioning |
19 |
|
|
20 |
|
This is a distributed block-based versioning system |
21 |
|
|
22 |
|
This is a distributed block-based system for getting the WWW static pages |
23 |
|
feature set from P2P |
24 |
|
|
25 |
|
This is a way to avoid web rot (the Cassini-Huygens thing) by allowing |
26 |
|
storage of old versions (this is VERY different from the location-independent |
27 |
|
web name... more like a side effect) |
28 |
|
|
29 |
|
This is a way to do an ad hoc networking web |
30 |
|
|
31 |
|
|
32 |
|
The MAIN goal of this work remains unclear and needs |
33 |
|
discussion. I think our getting this paper in depends on exactly that: |
34 |
|
a CLEAR main goal, a good presentation that will generate discussion. |
35 |
|
|
36 |
|
REAL: |
37 |
|
|
38 |
Abstract |
Abstract |
39 |
======== |
======== |
278 |
No versioning model |
No versioning model |
279 |
------------------- |
------------------- |
280 |
|
|
281 |
PAST [rowstron01storage]_ is a persistent storage system that use |
PAST [rowstron01storage]_ is a persistent storage system |
282 |
[rowston01pastry]_ for locating data in a Peer-to-Peer environment. |
that uses pastry [rowston01pastry]_ |
283 |
|
for locating data in a Peer-to-Peer environment. |
284 |
Nodes and data items are distributed uniformly based on the hash |
Nodes and data items are distributed uniformly based on the hash |
285 |
identifier in a PAST network. Free Haven [dingledine00free]_ |
identifier in a PAST network. Free Haven [dingledine00free]_ |
286 |
provides a distributed anonymous persistent data storage. It uses |
provides a distributed anonymous persistent data storage. It uses |
375 |
blocks is available. |
blocks is available. |
376 |
|
|
377 |
The benefits of starting from this basic model are numerous: |
The benefits of starting from this basic model are numerous: |
378 |
XXX |
|
379 |
|
- simple to implement - existing models cover this well |
380 |
|
|
381 |
|
- can be made to work with peers that join and leave small |
382 |
|
ad hoc networks often (and the global "net" less often) |
383 |
|
|
384 |
|
- robust - all state of the system is in the blocks |
385 |
|
|
386 |
In this framework, we shall define a system of *pointers*: |
In this framework, we shall define a system of *pointers*: |
387 |
some types of identifiers that refer to a block but whose |
some types of identifiers that refer to a block but whose |
406 |
|
|
407 |
This Section gives our main contribution: a way |
This Section gives our main contribution: a way |
408 |
to implement a persistent, distributed versioning |
to implement a persistent, distributed versioning |
409 |
system relying only on the abstraction presented |
system relying only on the block abstraction presented |
410 |
in the previous section. |
in the previous section. |
411 |
|
|
412 |
Our system is based on adding blocks to the system |
Our system is based on adding *pointer record* |
413 |
|
blocks to the system. Pointer record blocks are similar |
414 |
|
to Oceanstore's heartbeats but the important difference |
415 |
|
in our system is that they are also represented as simple |
416 |
|
data blocks. |
417 |
|
|
418 |
|
|
419 |
The PointerID is a combination of a public key of the |
The PointerID is a combination of a public key of the |
420 |
owner of the pointer (possibly a certificate) |
owner of the pointer (possibly a certificate) |
421 |
and an identifier. The association of the PointerID to |
and an identifier. The association of the PointerID to |
422 |
a particular data block is specified by adding a special |
a particular data block is specified by adding a |
423 |
*pointer block* into the system, which contains |
pointer block into the system, which contains |
424 |
|
|
425 |
- the PointerID |
- the PointerID |
426 |
- the block ID |
- the pointee: a block ID |
427 |
- a timestamp |
- a way to sequence pointer blocks: either a |
428 |
- (optionally) a list of pointer blocks *obsoleted* by this pointer block |
timestamp, |
429 |
|
a list of pointer blocks *obsoleted* by this pointer block, or both |
430 |
|
- a digital signature of all the above data, using the private |
431 |
|
key corresponding to the public key in the PointerID |
432 |
|
|
433 |
|
Then we can define, using the reverse indexing framework |
434 |
|
of the block abstraction, index functions such as the following: |
435 |
|
|
436 |
|
- all pointer blocks with the given PointerID |
437 |
|
- all pointer blocks with the given PointerID with timestamps in the given range |
438 |
|
- the latest (timestamp / unobsoleted) pointer block with the given PointerID |
439 |
|
(this index will benefit from the ability to determine locally the "relevant" |
440 |
|
blocks for a given index) |
441 |
|
|
442 |
|
The choice between timestamps and obsoletion lists or both allows |
443 |
|
some latitude in the semantics of pointers; timestamps define |
444 |
|
a strictly linear version order, whereas obsoletion lists |
445 |
|
allow branching, i.e. having more than one "current" version. |
446 |
|
(XXX Also possible: timestamp and time of the latest version timestamp |
447 |
|
and we obsolete all versions we know with timestamps after that time - |
448 |
|
gives more "coverage") |
449 |
|
The obsoletion lists are most relevant in a context such as blogging where |
450 |
|
a user might sometimes submit new entries using a mobile device and sometimes on a |
451 |
|
desktop machine. If the blocks do not obsolete each other, the software |
452 |
|
can notice this and help the user bring the versions back to synch. |
453 |
|
|
454 |
|
|
455 |
.. - In this section, we discuss a particular way |
.. - In this section, we discuss a particular way |
456 |
of implementing pointers (this is our main contribution) |
of implementing pointers (this is our main contribution) |
528 |
- will be there only if someone *wants* to store those versions |
- will be there only if someone *wants* to store those versions |
529 |
unwanted versions get purged |
unwanted versions get purged |
530 |
|
|
531 |
|
- spam with a stolen key? |
532 |
|
|
533 |
|
- formulas for efficiency? |
534 |
|
|
535 |
- spamming with new versions (only author due to DS, but still) |
- spamming with new versions (only author due to DS, but still) |
536 |
|
|
537 |
- Copyright issues |
- Copyright issues |
554 |
|
|
555 |
|
|
556 |
|
|
557 |
Notes |
|
558 |
===== |
.. NOTES ================================================================= |
559 |
|
|
560 |
|
|
561 |
.. [#cassini] ``http://www.seds.org/spaceviews/cassini/rtg.html`` |
.. [#cassini] ``http://www.seds.org/spaceviews/cassini/rtg.html`` |
562 |
|
|
569 |
are generally not circular, making this domain map neatly |
are generally not circular, making this domain map neatly |
570 |
to the properties of hash-based referencing. |
to the properties of hash-based referencing. |
571 |
XXX Except for "in press", "unpublished manuscripts", ... |
XXX Except for "in press", "unpublished manuscripts", ... |
572 |
|
|
573 |
|
|
574 |
|
|