- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 20 May 2021 18:00:14 -0400
- To: public-rww@w3.org
- Message-ID: <b8a4cb27-6681-121b-8e3f-782a7921e380@openlinksw.com>
On 5/20/21 2:23 PM, Melvin Carvalho wrote:
>
>
> On Thu, 20 May 2021 at 17:17, Kingsley Idehen <kidehen@openlinksw.com
> <mailto: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 <mailto: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 <mailto: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
>>>> <mailto:henry.story@bblfish.net>> wrote:
>>>>
>>>> > On 17. May 2021, at 20:53, Melvin Carvalho
>>>> <melvincarvalho@gmail.com
>>>> <mailto:melvincarvalho@gmail.com>> wrote:
>>>> > On Mon, 17 May 2021 at 19:50, Henry Story
>>>> <henry.story@bblfish.net
>>>> <mailto:henry.story@bblfish.net>> wrote:
>>>> > > On 17. May 2021, at 03:33, Nathan Rixham
>>>> <nathan@webr3.org <mailto: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
>>>> <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
>> <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/
> <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
> <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
>
In regards to Name Services and Blockchains, do take a look at:
[1] https://docs.stacks.co/build-apps/references/bns -- which is did:
scheme based
[2] https://github.com/decentralized-identity/universal-resolver --
Universal Resolver Project (also did: scheme based)
[3] https://blog.cloudflare.com/cloudflare-distributed-web-resolver/ --
ipfs based
--
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
Received on Thursday, 20 May 2021 22:00:34 UTC