Re: RWW Use-Case Example: Web-Scale Ticketing Ideas

On Thu, 20 May 2021 at 17:17, Kingsley Idehen <kidehen@openlinksw.com>
wrote:

> On 5/20/21 8:19 AM, Melvin Carvalho wrote:
>
>
>
> 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
>
> Changed title to orient focus.
>
> Here's what exists currently, putting blockchains aside.
>
>    1. I can generate an X.509 Certificate (which an expiration date) that
>    functions as my Web Ticket
>    2. I can ACL protect my RDF documents and even associated services
>
> Both good


>
>    1.
>
> Adding a blockchain to the mix solves the following:
>
>    1. Making my Ticket more copy-proof by tracking ownership via a
>    Blockchain -- rather than depending solely on "private key" access and
>    control on the part of users
>    2. Handling accounting for future royalties etc
>
>
Let's say we want to bootstrap a timestamp server.  Bootstrap is something
the RWW is really good at

Much of what you describe in (1) and (2) can be done on the linked data
side.  The timestamp server is just a witness.  It prevents tampering,
provides audit etc. (aside: we should list the functions it adds at some
point).  Block chains provide ownership rights via PKI, so you can
transition both state, and who controls the ability to change state
(similar but subtly different things)

What do we need for this bootstrap.  We need a way of 'hooking in' to the
block chains (using URIs of course).  So block chains natively dont have
URIs but they do have UUIDs.  This is necessary because they are extremely
compact, and adding a uri would be expensive, that's why it's better on the
RWW side, and out of band

We need a URI scheme for transactions.  It's a simple enough thing to do,
but I was looking around for existing work and I found:

https://w3c-ccg.github.io/blockchain-links/

This doesnt quite do the job because we need inputs and outputs (which are
like specific transactions).  I've raised an issue here:

https://github.com/w3c-ccg/blockchain-links/issues/2

Not a big deal, as we could make our own in a few minutes I would think, we
would just need to name the URI scheme.  That probably completes a decent
chunk of the architecture, and we can be close to the point of writing code
after we name with URIs the things we want to bootstrap


>
>    1.
>
> Links:
>
> [1]
> https://medium.com/virtuoso-blog/understanding-our-lod-connectivity-license-offer-2eef8fffaa7e
> -- example of the X.509 approach that's been in use for a while now re ODBC
> and JDBC Connectivity to the LOD Cloud
>
> --
> 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
>
>