tracking state changes in a temporal read-write web

this is the outline of a strategy to track state changes in a temporal
read-write web

by no means the only strategy, but an aim to generalize some of the recent
discussions

1. Data as a declarative state machine

The data can be considered as a declarative state machine, offering state
transitions

Simple case is one document, but it's useful to have multiple documents
over a set of quads (linked data) or directory tree (file system)

It seems standard practice to track this data using a hash function. So the
first step would be to hash the document or tree or knowledge base into a
chain of hashes.  Git or other VCS systems do this, similarly with single
documents you could take a sha2, for example, and maintain a chain of
hashes that way

2. Bootstrapping a timestamp server to witness hashes

Robust global timestamp servers have existed for over a decade, popularized
by the bitcoin project, often referred to as block chains, because data is
tied to those timestamps in the form of 'blocks' of data.  Users compete
for space on those blocks based on an auction basis, as they are a finite
resource, to make them spam resistant

The chain of hashes described in (1) can be tracked on the blocks of the
timestamp server, which tend to have a common transaction format.

What is needed is hash1,hash2,hash3...hashn to be sequenced in time from a
definitive start, or genesis.  That genesis can become an identifier for
the chain of linked data which we wish to securely witness.

Block chains typically follow a transaction in time from spent -> unspent.
The terminology is that of inputs and outputs.  This can be thought of as
source and destination.

The transactions are identified as cryptographic hashes, with an array of
outputs.  In order for a timestamp server to track a chain of linked data,
we need to construct a URI for the linked data hashes (hash1,2...n) and for
the block chain transactions (tx1,2,...) with the first tx being a genesis
identifier

Gaps needed to fill:  create URIs for hash1,2,...n.  Create URIs for
tx1,2...n

3. Two way links between state machines

Two way links between those state machines ensure strong coupling between
the two systems providing a bootstrap.  So from the case of the linked
data, you need a pointer to the transaction URI.  And from the block chain
you need a pointer to the hash URI.

From a block chain there's a couple of ways to do this, one is the
so-called OP_RETURN which allows you to embed data in at transaction.  The
other is known as 'tweaking' a public key on order to add a hash
(hash1,2...n in the web chain)

Linking from linked data to a transaction, once you have a URI can be done
in a number of ways.  But as linked data is designed to link to other URIs
it's quite doable by putting it onto the data structure.  Another
technique, for example in VCS is to put a link in the commit message, as
commit messages are part of the chained tree

4. Ensuring Temporal Integrity

Once (1), (2), (3) are in place.  Change can be made to the state machine,
and new hashes generated.  With the example of git we can commit hashes to
a file system, or a centralized server such as github

But, If we want to commit at web scale, we can do so as follows:

Firstly generate a hash of the new state.  Then move the transaction in the
block chain along to point to this new state.  The transaction itself has
PKI based ownership rights which have a variety of ways to manage and
transfer ownership including so-called "multi sig" ownership where any N of
a given M actors need to agree on a transition

Finally, point the web chain back to this new transaction once it is
confirmed

This will progress the web chain in time and mirror it on the underlying
time stamp server

The resulting system creates a temporal read write web state machine
anchored to the strong assurances of an underlying timestamp server

This is a sketch outline of something that could be turned into a prototype
or MVP, and also illustrating the gaps in technology that we need, namely
to create two URI schemes, to hash web state, and describe state
transitions, for data and for agents

Appreciate this is a sketch outline right now, feedback welcome!