– DRAFT –
Linked Web Storage

Introductions & announcements

gibsonf1: working with solid since 2019, running graphmetrix. Coming from the construction industry, an architect
… integration with Oracle. We are an integration platform, coming from the smart server side.
… we are very interested because of the scale of our customers, it's a massive amount of data. We have to solve the problem on our side for millions of datapoints. We're very interested in the search side.
… you have to have search for massive amounts of data. The backend is common lisp.
… most of the code is built by me.

<csarven> Linked Data Hypergraph

gibsonf1: we also have a patent for linked data hypergraph

<gibsonf1> its a patent pending actually for LDH, not a patent yet

Portability: data identifiers & locators

<acoburn> Slides

ericP: introducing a seminar on portability
… slides available: https://hackmd.io/udygiH3STieqHniB38h1ig

<ericP> https://hackmd.io/@ericP/SybL2qT6Jl#/

ericP: sharing screen
… clarifying the concepts and problem statement on screen: https://hackmd.io/@ericP/SybL2qT6Jl#/
… portability to a new provider should happen with acceptable one-time and run-time cost
… overview of the DNS features that work and what makes them work
… how do we handle dereferencing without introducing points of failure
… presenting DNS, distributed ledgers and federations or shared registries.

<csarven> ^ hah

<csarven> ericP -- Can you copy/paste your slides or link to them (if it can be persistent or you want it to be) into a comment in the lws-ucs issue on Portability?

hadrian: the term "stable, cross-provider identifiers" captures much of what I was trying to capture with portability
… you mentioned keri and IANA for providers. IANA is more of a governance entity to correct problems
… the ability to correct disputes is an important element
… having a dispute resolution process without prescribing how might be something to consider

<ericP> dispute resolution analog to IANA is very interesting

hadrian: I stated that DNS doesn't "scale well". It scales *out* very well. Here, we are talking about scaling *up*. For example, a few zones with many, many records

<ericP> +1 to DNS's ability to scale out vs scaling up

hadrian: I don't think LWS should prescribe a particular solution; instead, it should prescribe what the criteria are for a solution

csarven: I want to be mindful of the charter and the scope
… I don't want us to boil the ocean, we need to work within the scope of the charter
… what kind of products are we writing the requirements for?
… we need to draw a line because at some point it goes outside the charter

<Zakim> acoburn, you wanted to note that we do not want to preclude possible solutions

acoburn: agree that we don't want to increase the scope. we don't want to solve the issue, we want to make sure that we don't preclude working solutions

<csarven> s/for? /for? For example, applications and servers generally working or part of the Open Web Platform

<TallTed> both `q+` and `queue+` work ... as you can see from zakim's doubled ack

<Zakim> gibsonf, you wanted to DNS scaling and current implementation use

gibsonf1: pretty cool irc automation, i'm impressed
… people have many accounts in many places, DNS works well for organizations, maybe we should have a spec for users
… DNS is very tried and true
… i'd be very nervous to introduce another mechanism

bendm: to be a bit pragmatic, is it possible the next step to be to continue with the webid and then provide some sort of extension?

<csarven> s/it goes outside of the charter/if it goes outside the charter someone will raise a flag

acoburn: we don't yet have consensus on this issue, we are trying to figure out what the scope is and the intersection with our charter.
… one option may be for us to specify what are the characteristics of an identifier
… that would allow us to potentially use DIDs or other technologies, now and in the future.
… this is not how we'll resolve the issue for all time

<Zakim> ericP, you wanted to say that DIDs have provided a lot of the groundwork; i'm just trying to clarify what the underlying tech relies on

ericP: I wasn't promoting these technologies, just providing an overview.

<Zakim> bendm, you wanted to ask how to evaluate such a more high-level set of requirement

bendm: if we stay to general, how will this work for implementers?

<ericP> +1 to thinking about interoperable test suite

acoburn: we need at least 2 implementations for every requirement. you don't need a solution for every permutation

<bendm> clear, thanks!

hadrian: agree re interop issue
… +1 to cost considerations
… IMO, much of the costs should be hidden in the infrastrcutre

<gibsonf1> ... +1 to complexity cost consideration

csarven: talking about the cost, is not just about operations, but the cost of building the solutions. They must not be overly complex

csarven: we should prefer simple solutions over complex ones ( https://www.w3.org/TR/design-principles/#simplicity )

<ericP> +1 to modeling identifiers being central to our tech

Use cases updates

hadrian: Issue 140 touches on portability
… miro board to model relationship between use cases and requirements
… more issues have "needs discussion" label
… by end of this month (April) all issues will be out of triage

ryey: is there anything expected from our side?

hadrian: just add comments to the issues. Trying to have async conversations because time is limited in this call