Re: tracking state changes in a temporal read-write web

On Fri, 21 May 2021 at 16:35, Martynas Jusevičius <martynas@atomgraph.com>
wrote:

> Hi all,
>
> Why do these discussions immediately explode in all possible
> directions? Temporal integrity, blockchain (agnostic), hashing... How
> about we figure out the very *very* basics first, and start building
> from that?
>

Good idea, let me try and understand


>
> I have a suggestion for a simple decentralized use case:
>
>     There are 2 agents running instances of the same application,
>

OK


> where the instances are peers since the application includes both a
> server


OK


> (with an RDF storage backend)


OK


> and a client and can communicate
> both ways.
>

Unsure I understand this.  A server is a fairly simple one-liner these
days.  But a client.  Is that curl, or a browser, or a chat bot, or another
server?


>     One of the agents accesses (dereferences) an RDF document on the
> peer application, and stores that data in its own application.
>

OK


>
> And that's it, to begin with.


I think we can do this, seems more like a bot you are describing


> The intention is that now the agent can
> cross-reference the new data with the rest of the data in its
> application, e.g. using SPARQL if the storage supports it.
>

Cross reference seems a bit like validation here?  An important step, and
actually one I didnt cover originally so thanks for pointing that out.
State changes would benefit from being subject to a set of rules for valid
data


> Authentication, authorization are of course also in this picture, but
> they are orthogonal, so for the sake of simplicity we can skip them
> for now.
>

OK


>
> Is that too simplistic? Then please show me an RDF-based app that can
> do this out-of-the-box.
>

Does such an app exist to your knowledge?

If not I think it's possible to build.  The temporal component in your use
case did not seem obvious to me

So, we'd need to understand what cross referencing means

Would the data store also be public or private?  e.g. something like a file
based store, or require a quad store


> After this, we can proceed to add more requirements to this scenario.
>
> Martynas
>
> On Fri, May 21, 2021 at 4:14 PM Kingsley Idehen <kidehen@openlinksw.com>
> wrote:
> >
> > On 5/21/21 7:34 AM, Melvin Carvalho wrote:
> >
> > 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!
> >
> >
> > Great explanation!
> >
> > Challenge:
> >
> > Persisting this in a form that available for easy recall.
> >
> > Suggestions:
> >
> > 1. Documentation using RDF sentences in a document
> >
> > 2. A visual diagram to complement -- e.g., using http://draw.io
> >
> > Example:
> >
> > 1.
> http://www.openlinksw.com/data/turtle/general/knowledge-graph-manifestation-turtle-jsonld.html
> -- I constructed that for explaining Hypertext, Hyperdata, Hypermedia etc.,
> in relation to Knowledge Graphs; that all started from a draw.io diagram .
> >
> >
> > --
> > Regards,
> >
> > Kingsley Idehen
> > Founder & CEO
> > OpenLink Software
> > Home Page: http://www.openlinksw.com
> > Community Support: https://community.openlinksw.com
> > Weblogs (Blogs):
> > Company Blog: https://medium.com/openlink-software-blog
> > Virtuoso Blog: https://medium.com/virtuoso-blog
> > Data Access Drivers Blog:
> https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
> >
> > Personal Weblogs (Blogs):
> > Medium Blog: https://medium.com/@kidehen
> > Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
> >               http://kidehen.blogspot.com
> >
> > Profile Pages:
> > Pinterest: https://www.pinterest.com/kidehen/
> > Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
> > Twitter: https://twitter.com/kidehen
> > Google+: https://plus.google.com/+KingsleyIdehen/about
> > LinkedIn: http://www.linkedin.com/in/kidehen
> >
> > Web Identities (WebID):
> > Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
> >         :
> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
> >
>
>