1 |
|
============================================================================================ |
2 |
|
Versioning in a location-independent Web: Stopping the shoulders of giants from rotting away |
3 |
|
============================================================================================ |
4 |
|
|
5 |
|
(tentative title) |
6 |
|
|
7 |
|
Introduction |
8 |
|
============ |
9 |
|
|
10 |
- Introduce location-independent Web idea (citing |
- Introduce location-independent Web idea (citing |
11 |
benefits from hash-based addressing) |
benefits from hash-based addressing) |
12 |
|
|
13 |
- `Standing on the shoulders of giants`_: Webrotting example |
- Standing on the shoulders of giants: Example of Web links rotting away |
14 |
- History of location-dependence: `TBL ref`_ |
- History of location-dependence: `TBL ref`_ (like in HT'03 paper) |
15 |
- Location-independent, semantic-free, *self-verifying* |
- Location-independent, semantic-free, *self-verifying* |
16 |
identifiers (ref SFR paper (Balakrishnan et.al. IPTPS'03), |
identifiers (ref SFR paper (Balakrishnan et.al. IPTPS'03), |
17 |
ref Walfish paper); example: hash-based (ref |
ref Walfish paper); example: hash-based (ref |
48 |
location-independent version management |
location-independent version management |
49 |
- Non-linear versioning through obsoletion |
- Non-linear versioning through obsoletion |
50 |
|
|
|
- Related work |
|
51 |
|
|
52 |
- In this section, we summarize how existing |
Related work |
53 |
peer-to-peer systems deal with versioning. |
============ |
54 |
|
|
55 |
- No updates: |
- In this section, we summarize how existing |
56 |
|
peer-to-peer systems deal with versioning. |
57 |
|
|
58 |
- PAST |
- No updates: |
|
- Free Haven |
|
59 |
|
|
60 |
- Centralized updates: |
- PAST |
61 |
|
- Free Haven |
62 |
|
|
63 |
- SFS &c; destructive updates |
- Centralized updates: |
64 |
- Publius (apparently); destructive updates |
|
65 |
- Oceanstore; non-destructive, linearly versioned updates |
- SFS &c; destructive updates |
66 |
|
- Publius (apparently); destructive updates |
67 |
|
- Oceanstore; non-destructive, linearly versioned updates |
68 |
|
|
69 |
- Network-level destructive updates: |
- Network-level destructive updates: |
70 |
|
|
71 |
- Freenet |
- Freenet |
72 |
- SFR (apparently) |
- SFR (apparently) |
73 |
- CFS |
- CFS |
74 |
|
|
75 |
- Conclusion: Doesn't provide the benefits of |
- Conclusion: Doesn't provide the benefits of |
76 |
hash-based addressing; doesn't allow accessing |
hash-based addressing; doesn't allow accessing |
77 |
past versions |
past versions |
78 |
|
|
79 |
|
|
80 |
|
Pointer records |
81 |
|
=============== |
82 |
|
|
83 |
|
- Basic model of underlying system: Only blocks and reverse indexing |
84 |
|
(nicely provided through DHT) |
85 |
|
- Key idea: Pointers are abstract references that *point* |
86 |
|
to different blocks (versions) over time |
87 |
|
- The association between a pointer and a version is formed |
88 |
|
by a special kind of block, the *pointer record* |
89 |
|
- Signatures |
90 |
|
- Timestamp for ordering the records/versions (note on problems |
91 |
|
this entails-- if a computer's clock is set into future etc) |
92 |
|
- Implementable in other systems, too |
93 |
|
- Carries over the four benefits from hash-based addressing: |
94 |
|
|
95 |
|
- Version references movable between servers |
96 |
|
- Past versions accessible as long as anyone keeps a copy |
97 |
|
- Load balancing (download the pointer record from whoever has it) |
98 |
|
- Can use one addressing scheme for *updateable* information, |
99 |
|
searching different networks for versions |
100 |
|
|
101 |
|
|
102 |
- Pointer records |
Non-linear versioning for asynchronous collaboration |
103 |
|
==================================================== |
104 |
|
|
105 |
- Basic model of underlying system: Only blocks and reverse indexing |
- (also one person using more than one computer) |
|
(nicely provided through DHT) |
|
|
- Key idea: Pointers are abstract references that *point* |
|
|
to different blocks (versions) over time |
|
|
- The association between a pointer and a version is formed |
|
|
by a special kind of block, the *pointer record* |
|
|
- Signatures |
|
|
- Timestamp for ordering the records/versions (note on problems |
|
|
this entails-- if a computer's clock is set into future etc) |
|
|
- Implementable in other systems, too |
|
|
- Carries over the four benefits from hash-based addressing: |
|
106 |
|
|
|
- Version references movable between servers |
|
|
- Past versions accessible as long as anyone keeps a copy |
|
|
- Load balancing (download the pointer record from whoever has it) |
|
|
- Can use one addressing scheme for *updateable* information, |
|
|
searching different networks for versions |
|
107 |
|
|
108 |
- Non-linear versioning for asynchronous collaboration |
Permanent signatures |
109 |
|
==================== |
110 |
|
|
111 |
- (also one person using more than one computer) |
- To archieve the permanence alluded to above, need to |
112 |
|
take into consideration stolen/cryptoanalyzed private keys |
113 |
|
- Simple measure: use only hashes; but obviously, we don't |
114 |
|
want to do that always |
115 |
|
[could do it in academic articles, though...] |
116 |
|
- Will now outline two schemes for permanent signatures. |
117 |
|
The first comes from the literature, but has patent problems; |
118 |
|
the second is a sketch of a system invented by us. |
119 |
|
|
120 |
- Permanent signatures |
- KASTS: |
121 |
|
|
122 |
- To archieve the permanence alluded to above, need to |
- ... |
|
take into consideration stolen/cryptoanalyzed private keys |
|
|
- Simple measure: use only hashes; but obviously, we don't |
|
|
want to do that always |
|
|
[could do it in academic articles, though...] |
|
|
- Will now outline two schemes for permanent signatures. |
|
|
The first comes from the literature, but has patent problems; |
|
|
the second is a sketch of a system invented by us. |
|
123 |
|
|
124 |
- KASTS: |
- Our system: |
125 |
|
|
126 |
- ... |
- ... |
127 |
|
|
|
- Our system: |
|
128 |
|
|
129 |
- ... |
Conclusions |
130 |
|
=========== |
131 |
|
|
132 |
- Conclusions |
- To make the Web a solid foundation for standing |
133 |
|
on the shoulders of giants. |
134 |
|
|
135 |
|
|
|
.. _Standing on the shoulders of giants: urn:x-storm:pointer-0.1:sep34hb5jkkzu6dqhzpt4ivymr4nzwg7:vd4chieqzy4f5pw6gl6jcpvuglxjdvy7:html |
|
136 |
.. _TBL ref: http://www.w3.org/DesignIssues/NameMyth.html#What |
.. _TBL ref: http://www.w3.org/DesignIssues/NameMyth.html#What |