– DRAFT –
Linked Web Storage

Introductions & Announcements

acoburn: First topic is Annoucments and intro.

Action items

acoburn: Next item on agenda "Open action Items"

acoburn: One from Hadrian "Context around Storage provide user" but he is not available.

Prioritization of use cases

acoburn: last week we went through lot of requirements.

acoburn: we have 39 requirements we got through a lot, 27 of them. Lets go on to the rest.

acoburn: face to face meetings should be helpful to have a clear understanding of what needs to go in core fo the specfications
… one of the things we have been doing basically going through we need to priortize what needs to discuseed in f2f meeting

<RazaN> +1 in the Scope -1 out of scope.

acoburn: We have LWS poll for specfiactions for everyone to add to the poll

<acoburn> Server to server authentication

STRAWPOLL: Server-to-server Authentication

<gibsonf1> +1

<acoburn> +1

<ericP> +0

<bartb> +1

<pchampin> +1

<TallTed> +1

<bendm> +1

<ryey> +1

<laurens> +1

<acoburn> Scalable Storage Management

STRAWPOLL: Scalable Storage Management

<ericP> +0

<bendm> +1

<RazaN> +1

<bartb> -0

<gibsonf1> +1

<TallTed> +1

<acoburn> +0 (Scalability is important, possibly as a non-normative section)

<laurens> -1

<pchampin> +0

ryey: Was this requiremnt aimed at unifying different storages, or more about back end storages like triple stores etc.?

acoburn: Back end can be partition or scale

ryey: text in the specificition document is not clear.

acoburn: to me word the scalability is very slippery, its seems to indicate logical structure of the back end on presistent layers.

<ryey> +0 (maybe as non-normative)

<bendm> -0 (I misunderstood)

<acoburn> Performance and Scalability

STRAWPOLL: Performance and Scalability

<acoburn> +0 (Requirements shouldn't prevent scalable implementations)

<bartb> -1

acoburn: next Performance and Scalability is also related to scalability

<laurens> +0 (rather vague)

<RazaN> +0

<ericP> +0

<bendm> -0

<gibsonf1> +0 (on spec not preventing scalability of implementations)

<TallTed> +0

<ryey> +0.5 (performance is important; but not necessarily as "requirement" on its own)

<pchampin> +0

<acoburn> Profile management

STRAWPOLL: Profile managament

acoburn: The idea is to have different identifers for an entity.

<TallTed> +1

<bendm> +1

<RazaN> +1

<gibsonf1> +1

<bartb> +0

<acoburn> +1

<laurens> +1

<ryey> +1

<ericP> -0 # timeline concearns

<pchampin> +0.5 (using multiple identities should not be prevented, but not sure if the protocol should have specific features for this)

ryey: i need some clarification: by entity are we talking about agent or softaware? In principle anyone can create as many profiles as they want.

acoburn: here entity can means they can be bot or the can be work for some software. but when we got into specification we will look into that

ryey: When we talk about storages and there are two different profiles and different authorization.

acoburn: Question of Access control one of the topic for Face 2 Face meeting and lot of the discussion . do other folks have other thoughts about this particular requirement

gibsonf1: people may be have a main identifier, and several other ones

<acoburn> Group-Based Access Control

<gibsonf1> +1

STRAWPOLL: Group based Access Control

<gibsonf1> +1

<acoburn> +1

<ryey> +1

<bartb> +1

acoburn: Whether this should be core part of specfication

<RazaN> +1

<bendm> +1

<ericP> +1

<pchampin> +0.5 not sure about v1

<TallTed> +1 (so many requirements could be clarified with "as in Unix-like systems")

<acoburn> View-Based Data Sharing

STRAWPOLL: View-based Data Sharing

<gibsonf1> +0 (Seems like that would be access control the way its phrased)

<TallTed> +0.5

<bendm> -0 (very useful, but I don't see it happening for v1)

<bartb> +0 (great implementation feature, need not be in spec)

<acoburn> +0 (this would be a nice extension feature)

<pchampin> +0

<RazaN> +0

<ryey> +0.5 (leaving possibility for this to be supported, but doesn't have to be in core spec)

<ericP> -0

<RazaN> +0

<acoburn> Federated Data Queries

STRAWPOLL: Federated Data Queries

<ericP> -0 # prefer that be separate

<pchampin> +0

<bendm> -0 (that's a tall order wrt current specs, no?)

<TallTed> +0 (this is a pretty big lift for v1)

<gibsonf1> +0 (but not on Sparql as the solution)

<acoburn> -1

<bartb> -0

<RazaN> +0

<acoburn> Collaborative Editing

<ryey> +0 (for optimization, but not core spec)

STRAWPOLL: Collaborative Editing

<laurens> -1

<TallTed> +0 (this is a pretty big lift for v1, even optionally, as that option will impact interop)

bendm: I would like to know what the implications of this requirements would be. Adding some data somewhere or metadata need to be required for api.

acoburn: Certain metadata hints maybe helpful but i am not expert in CRDTS.

<ryey> +0 (too complicated for conflict resolution; but necessary hooks or APIs may be provided)

<gibsonf1> +0

bendm: if we have metadata maybe we have later extension of anykind

<bartb> -1

<acoburn> -1

ryey: I have some experience in working with CRDTs. They are not magic: any CRDT algorithm for merging will preserve only some aspects of the data. This is hard to do with graph data such as RDF, much more feasible with JSON.

ericP: if we include everything we don't want to preclude, we'll have a lot of wandering requirements

<bendm> -1

<ericP> -1

<acoburn> Timeseries data support

STRAWPOLL: Time Series Data Support

<laurens> -1

<bendm> -1 (that's a whole other can of worms 😅)

<acoburn> -1

<RazaN> -1

<bartb> +0

<ryey> -1 (unless hooks or APIs can resolve this)

<gibsonf1> -0 (Could be treated as a server capability beyond spec)

<pchampin> -1

<TallTed> -1 (way too complex for v1, especially given other already heavy lifts)

<ericP> -1

<acoburn> Self-Describing Website Publication

STRAWPOLL: Self Describing Website Publication

<laurens> -1 (too many security implications)

<bendm> -1

<gibsonf1> +1

<acoburn> -1 (ditto about security)

<bartb> -1

<ericP> +0

gibsonf1: just curious: what are the security implications? What about providing one public container, and only publish what's in it?

<ryey> +0.5 (or can be combined with other mechanisms for similar purposes)

<TallTed> -1 (this feels more like a broad use case than a narrow requirement)

<pchampin> +0

acoburn: basic security models are based on domain names, if you are able to set a cookie and have some java script setup for that, if could you then use it to access data you are not supposed to. This is why, for example, github.com uses a separate domain github.io for user content.

<TallTed> "self-describing website" and "persistent URIs" are big parts of my concern

gibsonf1: is there documentation regarding that?

<acoburn> Profile Interaction UI

STRAWPOLL: Profile Interaction UI

<laurens> -1

<bendm> -1

<TallTed> -1 (UI is not Protocol)

<acoburn> -1 (this seems like the domain of apps, not the LWS protocol)

<bartb> -1

<gibsonf1> -1

<RazaN> -1

<ericP> -1

<ryey> -0.5 (more like an app, not for protocol; unless it implies APIs to interact with such functionality)

<pchampin> -1

<acoburn> Personal Data Projection

STRAWPOLL: Personal Data Projection

<bendm> -0

<ericP> -0

<TallTed> -1 (protocol inherits HTTP ConNeg; transformation is or should be outside of protocol's remit)

<acoburn> +0 (Great feature but not for the core)

<gibsonf1> +0

<bartb> -1

<ryey> +0 (good to have relevant mechanisms / APIs to support this; but not necessarily the function itself)

<pchampin> +0 (ditto acoburn)

acoburn: We have reviewed all requirements. I'll compile that and have somethig to show next week.

Face-to-face meeting agenda

acoburn: we dont need to set the agenda but i would like to know who is going to attend in face to face in person. what would be useful as some of these from the LWS polls

acoburn: Complex requirements would be around authentication and query

acoburn: Are there other thoughts, things be on the agenda to discuss face to face meeting?

<pchampin> +1 to the topics proposed by acoburn

acoburn: one other thing we want to consider: there are three days, some folks want to leave on firday and arriving on wednesday so thursday is a good day to have a more focused discussion.

acoburn: any logistics or any other items?

laurens: i already sent information on the mailing list. everyone who is attendign let us know so we can manage the arrival and have badges avaialble for evryone at the desk to collect.

<laurens> https://lists.w3.org/Archives/Member/member-lws-wg/2025Sep/0001.html

laurens: I will check will pchampin to provide a link for remote calling. We should have technical means to allow remore participation, but probably only audio.