Meeting minutes
Introductions & Announcements
acoburn: Laurens may have updates for F2F meeting later.
Action items
acoburn: One for Hadren's.. We can skip for now. The other one is for storage providers. We'll reserve for later.
Review prioritization of use cases
acoburn: This one and next is the core for our discussion today.
… We had discussions in the last few weeks. We had polls and strawpolls. They were not binding, but give us information on what people feel about them, for their priority and focus.
… I put them into a spreadsheet
acoburn: I added them up as total, for +1, 0, and -1; included the number of votes; also normalized
… This gives us clear idea what people feel are more important. It's not binding, but informs us -- for those strong negative, unless we have a strong reason, we'd better not work on them
… What's interesting is they drop slowly initially; but after a point, they drop a lot; then too 20-30% range a cluster.
… I suspect the things above 70% is the parts we'll focus
… For lower ones, some may actually fit into the higher ones. E.g. some about access control
… We'll agree on what we focus on in the next year, for our Charter's agreed date
… One thing I'm curious from the group: are there any down there seem surprising? Maybe not just for "reconsidering", but anything surprising, either higher or lower
gibsconf1: The Inbox
acoburn: I suspect for notification, we need a place for receiving them
… Inbox itself may not be (important) enough as requirement itself. But it may need to be pulled in as a part of notifications.
danbri: is it about message queues, as a part of the notifications?
acoburn: We focus on high-level for now. We'll go to mechanism later.
ryey: two questions: the consent based data sharing number seems surprising. Would expect it to be lower than transfer of control
… consent is a complex topic
… also e2e encryption
… this gets a 0 so likely won't be focused on
… this seems like an application level item rather than protocol level
acoburn: For E2EE, there is a split between the votes, quite different from many other ones
… We have same number of "for" and same number of "against"
… while for many others, we actually get many votes on "as extension" or alike, for those in similar situations
… I suspect it will be in application level eventually.
Face-to-face meeting agenda
acoburn: I'm showing a draft of the topics for the F2F meeting
… We have three days (but roughly two+ days), Wednesday - Friday
… For key items, I hope we can put to Thursday
… I'm trying to build on what we have on the straw poll results, for the focus in the F2F meeting
<Zakim> gibsonf, you wanted to ask about zoom in to f2f if can't make it in person
acoburn: coming up with topics for the items in the polls
gibsonf1: For those online, will there be zoom for participation? And for Friday afternoon ...?
acoburn: Yes and yes. Laurens mentioned there will be audio. For those in US, maybe put querying in the afternoon?
<Zakim> bendm, you wanted to ask about notification vs resource changes
bendm: You said subscribe to changes, and notification are very related. I have a feeling it's not really? E.g. notification is for linked data notifications, and changes is for applications, or data related...?
acoburn: there are some points. there are prior arts in ActivityPub, and Linked Data Notifications. All need to be considered. We need to make sure we'll get consensus.
… Answer is: they are related, but they may not all be brought into scope. It's something we'll discuss.
<Zakim> bendm, you wanted to ask about extensibility design choices
acoburn: One thing not listed in the requirements is test suite. We can't have too much time for it, but we should discuss
bendm: I remember we spent some time to talk about some functionality being extensible. E.g., for authentication, you'll have multiple ways. But we haven't really discussed how far we want to go for discussing that, especially in F2F
acoburn: Discovery also has Data Discovery, which also fits to other parts. I suspect you are describing Capability Discovery, that we don't put each implementation on its own part
bendm: I'm fine for that. I have feeling that for some parts we'll fix more than making it extensible. But we'll go through the days and see where we end up
acoburn: also, for authentication, we can spend significant time for it. We'd better timebox each topic.
… we'd better discuss each of them. Though, I'll not going to boil the ocean
ryey: would like to bring up pattern of interactions: authZ, authN, query, etc
… various interaction models (agent-to-agent, user's own storage, etc)
… would like to ground conversations in specific use cases
acoburn: I'm adding delegation (into interaction models), which we may not get to, but useful if we can.
… One other item: next week, many of us will meet in person. So should we still have our regular LWS WG meeting on Monday?
jeswr: Let's not force an agenda if we don't have something
<bendm> +1 to skip
ericP: Second
acoburn: gibsonf1, Are there anything you see probably fit into afternoon rather than morning?
gibsonf1: I'll communicate after the meeting
acoburn: I've shared the link (zoom chat). Everyone feel free to comment on it.
acoburn: copied to here as well
… anything else for today?
ryey: pending PR for requirements
acoburn: commentary on the PRs seem to indicate that these are closer to user stories than requirements
ryey: Authorization Capability -- the requirement focuses on allowing other serivces to interact with that authz mechanism
… User-controlled extensions: this would allow data owners/users to add features to a storage
… Custom information for Clients - mechanism for users to configure custom metadata associated with a resource
… Anonymous Identity Recognition -- pseudoanonimity features
… Data Authenticity Verification: not transmission tampering but rather tampering on disk
… Data Browsing: mechanism to browse/query the contents of the Storage
… Alternative Data Layouts: standard way to change presentation of data structure
ericP: would forward compatibility be required?
ryey: this is more like views in a database
… a server would be responsible for keeping connection between views and original mappings
… Cross-Client Automatic / Simple Login -- the protocol shouldn't make it too difficult for users to login
… Custom Rendering: related to views feature and rendering a website. Not specific to rendering HTML but more focused on generic transformation. This way one could share the URL and also a hint for rendering the resource
ericP: for commentary, please add whether (a) it is important to you and/or (b) it should be listed in the LWS requirements