Re: Evolution of the RWW -- a Temporal Web -- Towards Web 4.0 (?)

On Tue, 18 May 2021 at 16:52, Kingsley Idehen <kidehen@openlinksw.com>
wrote:

> On 5/18/21 6:39 AM, Melvin Carvalho wrote:
>
>
>
> On Tue, 18 May 2021 at 03:26, Kingsley Idehen <kidehen@openlinksw.com>
> wrote:
>
>> On 5/17/21 4:59 PM, Nathan Rixham wrote:
>>
>> On Mon, May 17, 2021 at 8:52 PM Henry Story <henry.story@bblfish.net>
>> wrote:
>>
>>> > On 17. May 2021, at 20:53, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>> > On Mon, 17 May 2021 at 19:50, Henry Story <henry.story@bblfish.net>
>>> wrote:
>>> > > On 17. May 2021, at 03:33, Nathan Rixham <nathan@webr3.org> wrote:
>>> > >
>>> > >
>>> > > A loosely coupled immutable timestamped record of state changes
>>> allows deployment of resources to be broadly tech and protocol agnostic.
>>> For example several previous states of a document could be stored on IPFS,
>>> with the stateless protocol HTTP providing the most recent state, and a
>>> chain exposing timestamped pointers to the previous states.
>>> >
>>> > You can also get quite far just by adding link between version states
>>> using memento for example.
>>> > I am trying that out in the new Solid Server I am putting together.
>>> There are comments in the code here:
>>> >
>>> https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/src/main/scala/run/cosy/ldp/fs/Resource.scala#L223
>>> >
>>> > Thanks Henry
>>> >
>>> > This looks interesting, I've had a look at the comment you pointed to,
>>> and it looks interesting, tho I didnt understand it fully
>>> >
>>> > Would it be possible to describe in a couple of sentences for those
>>> that are not intimately familiar with memento
>>>
>>> I have not implemented memento fully myself. It builds on rfc5829 and
>>> allows one to link to archives that keep
>>> copies of versions, though the server can be it’s own archive I believe.
>>>
>>> >
>>> > I can imagine a work stream for a temporal web based on this approach,
>>> if there's interest
>>> >
>>> > The thing that particularly interests me is what I'll term quite
>>> vaguely, a web-scale temporal web.  What I mean by this is, that the
>>> timestamp operation (aka the witness operation) is global scope and not
>>> local.  Meaning if any one website goes down, the timestamping record will
>>> still be there allowing a reconstruction of the history.  Providing
>>> resilience.  In 2021, we have specialized time stamping servers (commonly
>>> referred to as pubic block chain) which can provide this time travel type
>>> functions.  From your comment there is a time travel in memento too.  In
>>> any case, interested in your findings, if you'd like to share ...
>>>
>>> I think there is a clear need for any read-write web server such as
>>> Solid to keep versioning information,
>>> just to help restore versions in case a buggy hyper-App writes some
>>> data.  That use case does not require
>>> global consensus on version states. So I think that is local versioning
>>> will clearly be the first
>>> priority. Trellis-LDP implements somehting like this too, so I am
>>> following in the footsteps to get a
>>> better understanding of it.
>>>
>>
>> Agree, that's the trouble with using a stateless protocol to manage state!
>>
>> Exposing version via headers is a neat solution, I guess you can
>> implement etag and if none match on write requests to avoid updating a
>> resource for which you have a stale state / which has already changed
>> without you knowing. That is probably good enough for most cases.
>>
>> I guess chains come in to factor when you need reliable timestamps, and a
>> provably tamper proof immutable chain of previous states.
>>
>>
>> Yes!
>>
>> Throughput (and associated economics) remain challenges (as far as I
>> know) since blockchains are still database management systems albeit a
>> specialized variety where transaction logs are based on various consensus
>> protocols.
>>
>
> They are finite resources due to the highly replicated, resilient and
> fault tolerant nature
>
>
>> Imagine trying to track the evolution of the description of various
>> entities in DBpedia since 2007, I don't know how it wouldn't hit all the
>> scalability thresholds re both throughput and $$$.
>>
>
> Fascinating use case.  Well It's fair to say we could probably track a
> single page quite well.  Tracking all the pages would be quite a challenge,
> but in 10 years with 5G and 100TB of data as common, this may actually be
> within reach and affordable
>
> The question arises as to why you'd want to do such a thing.
>
> The answer is that an independent timestamp server allows you to
> decentralize the client server model.  The read write web as it is today is
> highly reliant on client server centralization.  We have not yet made
> inroads into decentralizing that model leading to most things on the web
> going through a trusted third party, tracking you, or trying to sell you
> something
>
>
> *Use-Case Example*
>
> Problem: Creator Conundurum
>
> I *painstakingly* put together an RDF document that provides details about
> the Beatles that's missing from DBpedia, Wikidata, and Musicbrainz such as:
>
> 1. Song Instrumentalists
>
> 2. Recording Location
>
> 3. Song Producer
>
> 4. Instruments per song
>
> 5. etc..
>
I think this part is solved using linked data, because you can say anything
about anything.  You could do this in RDF or JSON(-LD).  Now you have, for
the sake a simplicity, a document containing your data


> I want to publish this to the Web, but not for $0.00 since there is a
> serious opportunity cost associated with the production of the work in
> question.
>

Publishing we can do too.  But you want to do access control and also paid
access control.  Or a pay wall or something like this.

Solutions:

1. A hosted service, for example:
https://docs.lnpay.co/paywall/create-paywall

2. Create your own version of that service

3. Combine together the WebACL spec with a payments workflow (which we
could flesh out here), possibly using HTTP 402, and returning a header
telling the client how to pay

4. A more generic distributed service where the server could be an agent
that manages the access control and rights to your published resource.
This would be more advanced, but the kind of thing I see as a good prototype


> Challenges:
>
> 1. How do I express and assert ownership?
>

In Linked Data we express ownership via statements/quads, which can be
definitive if linked to a website.  Or via a signature which makes it
portable.  In cryptographic world most often a public key is used to
demonstrate ownership, and you will own the private key


> 1. How do I track use over time and receive appropriate monetary credits?
>

Two paths for this.  One is a public record, the other is recorded
privately.  Public data to track amounts received (aka a ledger) could
reuse the same linked data pattern that describes the state, but in another
part of the witnessed state (say, a diferent folder)


> Blockchain offers me NFTs as a potential ownership assertion mechanism. It
> also offers an ability for me to track credits due over time via a Smart
> Contract.
>

So the underlying block chain can track ownership of public keys (there's
some neat tricks with ECC keys and delegated ownership that I think you'd
like), you would NOT want to put a smart contract in the block chain imo,
as they can get complex and are better suited to be at the web layer.

>
> Issues with Blockchain:
>
> 1. Which of the zillion tokens + platform combos to I choose from?
>
Pick one in the spirit of royalty-free standards so one without a premine
used to enrich the founders (which unfortunately is over 99%).  Bitcoin and
derivatives (lightning, liquid, rootstock) are safe bets.  There's a few
others, which we could document.


> 2. Ultimately, do any of these actually scale to the levels required?
>

Sure, provided that you use the space well, and use the block chain simply
as a timestamp server.  So you 'commit' to a block chain when you want a
definitive state, or there is an important ownership transition.  This is
something we could spec out, if there's an appetite

BTW I love this use case because it would enable many more things, such as
paid podcasts, entertainment etc.  I think it's doable once we get the
plumbing done (stuff openlink is good at), and I've added this use case to
a new thread

>
>
> By externalizing the time component and making the data, code, and
> deployment components commodity, or access controlled commodities, you can
> start to have a read write web of humans and agents.
>
>
> This isn't an all or nothing situation i.e., we cannot look at the notion
> of a RWW as not being in existence without all the pieces in place, as we
> see them, based on our individual preferences and perspectives.
>
>
> I would encourage a more flexible approach based on use-cases, existing
> solutions, and establishment of degrees of optimal-fit in regards to
> platform independence and interoperability.
>
>
> The agents are really just a decentralization of a central server
> operating over a standards based API.  The RWW standards based APIs exist
> today, but the decentralized agents to run against them, largely do not,
> meaning we fall back to the persistence of central servers, or ephemeral
> clients and agents, that my run in a browser, or as a process, but almost
> inevitably do not build up enough history to become useful
>
> The web, ephemeral as it is, still works incredibly well, as an amorphous
> mass (in space).  The hyperlink as a super key is something that lives in
> time, and accrues reputation.
>
>
> Hyperlinks functioning as Super Keys are simply pointers to an address in
> a distributed computer that manifests as an Entity Relationship Graph
> (Graph) comprising an ever increasing number of Networks.
>
> Note, I make a distinction between Graph and Network in that the latter is
> comprised of nodes that are connected by relationship types (relations)
> that are transitive in nature. For example, the Web (*as most experience
> it*) comprises documents connected by a "links_to" relation that provides
> the basis for algorithms such as Google's Page Rank etc..
>
>
> With the RWW as a driver of a state machine for the web, its not just
> about robust versioning, it's about making decentralized web scale agents
> as first class as the dominant central server model, too ...
>
>
> It requires micro-agents rather than the browser monolith that currently
> dominates the landscape :)
>
>
> Kingsley
>
>
>
>>
>>
>> It would be nice if various approaches worked together.
>>
>>
>> Yes, interoperability is vital.
>>
>> --
>> 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
>>
>>
> --
> 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
>
>