[Gzz-commits] manuscripts/pointers article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/11/03 11:34:53

Modified files:
        pointers       : article.rst 

Log message:
        edit pointer record section

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/pointers/article.rst.diff?tr1=1.91&tr2=1.92&r1=text&r2=text

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.91 
manuscripts/pointers/article.rst:1.92
--- manuscripts/pointers/article.rst:1.91       Mon Nov  3 10:23:46 2003
+++ manuscripts/pointers/article.rst    Mon Nov  3 11:34:52 2003
@@ -227,65 +227,53 @@
 Pointer records
 ===============
 
-This Section gives our main contribution: a way
+In this section, we present our main contribution: a way
 to implement a persistent, distributed versioning
 system with no centralized components. 
 
-Our system is based on *pointer record* 
-data blocks - small files that, like Oceanstore's heartbeats,
-state that a given version of a given pointer points to
-a given hash, with a digital signature.
-However, contrary to other systems, our
+We assume that individual versions of a document
+are identified by their cryptographic hash.
+What we need is a way to identify a document
+across updates; we call this identifier a *pointer id*,
+because it *points* to different versions
+(identified by hash) over time.
+
+The pointer id is the hash of the pointer's *charter*,
+a file including identification information for the pointer's owner,
+the entity that has change control over the document.
+This can be the owner's public key, or information about the CA
+from which the owner's current public key can be obtained.
+The charter can also include a semantic-free random
+bitstring, to distinguish the pointer from all other documents
+owned by the same entity.
+
+To associate pointers with versions, our system uses *pointer records*
+small files that, similar to Oceanstore's heartbeats,
+are signed by the pointer's owner, and
+contain at least the following information:
+
+- The pointer id.
+- The hash of a version of the document.
+- A timestamp.
+
+The pointer record with the most current timestamp gives
+the current version of the document. All available records
+taken together form a full history of the document.
+
+In addition to the above information, a pointer record
+may contain a list of versions that the current version
+is based on. If a user edited the document, this would be
+the previous version. If the system merged two versions
+created by different users, this would be the two merged versions.
+The resulting directed acyclic graph can be used to detect
+situations where a document has been concurrently edited
+on two different machines, requiring a merge.
+
+Contrary to other systems, our
 system treats pointer records as *first-class citizens*;
 pointer records
-are treated just as normal data blocks/files 
+are treated just as normal data files 
 and may reside on any host.
-
-Below, we shall use |PointerID| and |BlockID| for identifiers
-of blocks and pointers, respectively.
-
-The |PointerID| is a combination of a public key of the
-owner of the pointer (possibly a certificate)
-and an identifier (usually a semantic-free random bitstring). 
-The association of the PointerID to
-a particular data block is specified by adding 
-to the system a pointer data block which contains
-
-..  |PointerID| raw:: latex
-
-    {\idstyle PointerID}
-
-..  |BlockID| raw:: latex
-
-    {\idstyle BlockID}
-
-- the |PointerID|
-- the current pointee: a |BlockID|
-- a timestamp
-- (optionally) a list of pointer blocks *obsoleted* by this pointer block
-- a digital signature of all the above data, using the private
-  key corresponding to the public key in the |PointerID|
-
-Then we can define, using the reverse indexing framework
-of the block abstraction, index functions such as the following:
-
-- all pointer blocks with the given |PointerID|
-- all pointer blocks with the given |PointerID| with timestamps in the given 
range 
-- the latest (timestamp / unobsoleted) pointer block with the given 
|PointerID| 
-  (this index will benefit from the ability to determine locally the "relevant"
-  blocks for a given index)
-
-The choice between timestamps and obsoletion lists or both allows
-some latitude in the semantics of pointers; timestamps define 
-a strictly linear version order, whereas obsoletion lists
-allow branching, i.e. having more than one "current" version.
-(XXX Also possible: timestamp and time of the latest version timestamp
-and we obsolete all versions we know with timestamps after that time - 
-gives more "coverage")
-The obsoletion lists are most relevant in a context such as blogging where 
-a user might sometimes submit new entries using a mobile device and sometimes 
on a
-desktop machine. If the blocks do not obsolete each other, the software
-can notice this and help the user bring the versions back to synch.
 
 
 ..  - In this section, we discuss a particular way