- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 20 May 2021 11:17:04 -0400
- To: public-rww@w3.org
- Message-ID: <0db86552-6628-cf3f-2dc7-5074b7412e83@openlinksw.com>
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
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
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
Received on Thursday, 20 May 2021 15:17:25 UTC