Meeting minutes
<acoburn> https://
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/
… 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/
… 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