W3C

– DRAFT –
Linked Web Storage WG

09 December 2024

Attendees

Present
acoburn, balessan, bendm, cpn, csarven, eBremer, ericP, hadrian, jeswr, present, TallTed, uvdsl
Regrets
-
Chair
acoburn
Scribe
ericP, acoburn

Meeting minutes

<acoburn> https://github.com/w3c/lws-protocol/wiki/Scribe-list

Introductions and announcements

acoburn: you can always request to add stuff to the agenda at the beginning of the meeting, but it's better to propose to the list or reach out to a chair

[no new group members]

Pending Action Items 1

acoburn: no pending actions items

Use Cases Review 2

acoburn: we're getting good use cases
… please continue to provide them and probably more importantly, comment on the existing use cases
… there's a "needs discussion" label that can be added to use cases
… we (chairs) have selected a couple, but avoided the trickier ones to start with
… se selected w3c/lws-ucs#22 and w3c/lws-ucs#14
… there's a connection between them as they both need some sort of notification
… (meta) when you see some intersections or duplicates, please flag them
… hadrian, does this reflect a set you'd like to start with? (not trying to limit to 2)

hadrian: w3c/lws-ucs#20 is to start the draft. pierre antoin proposed a few changes which i merged
… i'd like to get this out of the way so we can have the 1st draft in the main branch
… re two selected use case (issues), i think we also wanted to test whether the dashboard worked
… there are obviously-missing use cases

acoburn: the choice of those two largely came from the number of comments
… the connection between them seemed to merit discussion, but happy to start with others if you prefer

hadrian: perfectly fine

acoburn: [describing them at a high level]
… 14, asynchronous goods delivery, is about providing a mechanism where a 3rd party can write into a storage for a limited time
… 22, notifications, is more general
… allows 3rd party to provide comments about data in the storage

hadrian: i just added 13 to "needs discussion" because it's related
… it's the combination of data and agents that share data

ericP: do we want to take this as an introduction to consider tags and selection or should we just work on these UCs and see what comes out?

acoburn: should we look at hadrian's broad categories?

hadrian: i think it will be easier if the group goes though pre-categorized by the editor

<ericP> +1

hadrian: i'd like to discuss infrastructure

acoburn: fine by me
… certainly when we look at trust, we'll need that

hadrian: i think Tim originally viewed this as peer-to-peer
… (of course, leveraging DNS)
… IDPs were identified as needed
… we need to be able to scale; it's easy to demo stuff a low scale
… trust, non-repudiation etc require delegation to some infrastructure
… so we have to think about how this infrastructure will evolve

acoburn: we also want to think about scope
… when we discuss infrastructure, we can bring in everything on the internet (not possible in our charter)
… we need to acknowledge that there can be our infrastructure but also stuff that others layer on top

balessan: we should focus on the UCs and derive the needed infrastructure
… when we speak of trust, there's an intersection with the Data Spaces work
… if we're talking about interactions between orgs, we should consider other WGs' work

hadrian: +1
… acoburn mentioned scope, which is paramount if we want to meet our charter deadline
… we don't need to define everything in detail, just the characteristics

ericP: that suggests we're defining interfaces
… we need to be able to run tests, so any work towards limiting scope will also limit the feature set
… and what the product can to for users
… this is challenging for products with interoperability tests

acoburn: with the UCs we have in github issues, hadrian can describe the required infrastructure for a UC to be successful
… want to do that assync or start now?

hadrian: i think it must be done assynchronously because it's so much work
… we need to be as simple as possible
… if we don't keep scalability in mind, we won't scale
… i.e. discuss architectures like hub and spoke, etc.
… proposed separation protocol and data formats
… ericP is skeptical we can avoid going into details, i think it's required

uvdsl: re API design and interaction protocol
… Solid spec has lots of API design, Interop spec has lots of protocol

csarven: if you were to define a data format in this WG, which we're not, we could do that to describe e.g. discovery
… i don't think we need to discuss breaking up the spec
… changing one component in the Web Arch doesn't require changing other specs
… typically docs are split up for readability and modularity
… if e.g. auth spec changes, the other components shouldn't be affected by the details of the auth spec because it will have a short shelf-life

acoburn: in the charter, we have an "output", but that doesn't mean it will be a single document
… [to sarvent's point] auth is typically a moving target and we should avoid tighty-binding to it
… hadrian, you labaled nico's (long) UC with "needs discussion"
… as a UC per se, it goes beyond, e.g. mentions implementation
… has anyone read 24 and do they have some comments?

hadrian: nico's UC reveals functionality that many UCs hide
… re moving data from one provider to another, Q is what is the unit of data that can move?
… if i want to move data from one place to another, i don't want to break links
… so we need a resolution mechanism
… analogous with git
… so can nodes be resolved to some repository
… looks to me like a hybrid graph like git + Large File Storage

csarven: agenda request: discuss scope
… looking at UCs some are solution-engineering
… we all want our stuff to work but we need to fit it in two years
… we're talking about shaping up key components that make this thing
… from Solid, i learned that it takes a long time
… and do priory docs address some UCs
… not saying we accept them verbatim, but i think our contract is pretty close to the Solid specs
… we won't be able to solve all decentralization issues

<uvdsl> +1

acoburn: summarizes my concerns as well

acoburn: we'll have to look at UCs and decide whether they're in scope
… even if in scope, it might not be prioritized

Minutes manually created (not a transcript), formatted by scribe.perl version 238 (Fri Oct 18 20:51:13 2024 UTC).

Diagnostics

Succeeded: s/acoburn, you/acoburn: you/

Succeeded: s/archetechtures/architectures/

Succeeded: s/sceptical/skeptical/

Succeeded: s/seperation/separation/

Succeeded: s/to the UCs/to the Solid specs/

Succeeded: s/+present//

Succeeded: s|issue/22 and issue/14|https://github.com/w3c/lws-ucs/issues/22 and https://github.com/w3c/lws-ucs/issues/14|

Succeeded: s|pr/20|https://github.com/w3c/lws-ucs/pull/20 |

Succeeded: s|TallTed, help?||

Succeeded: s/draft minutes//

Succeeded: s/... sarven:/csarven:

Succeeded: s/concearns/concerns

All speakers: acoburn, balessan, csarven, ericP, hadrian, uvdsl

Active on IRC: acoburn, balessan, bendm, cpn, csarven, eBremer, ericP, hadrian, jeswr, TallTed, uvdsl