13:55:23 <RRSAgent> RRSAgent has joined #lws
13:55:28 <RRSAgent> logging to https://www.w3.org/2025/07/14-lws-irc
13:55:28 <Zakim> Zakim has joined #lws
13:55:45 <acoburn> acoburn has changed the topic to: Linked Web Storage Meeting 14 July, 2025
13:56:10 <acoburn> zakim, start meeting
13:56:10 <Zakim> RRSAgent, make logs Public
13:56:12 <Zakim> please title this meeting ("meeting: ..."), acoburn
13:56:18 <acoburn> meeting: Linked Web Storage
13:56:28 <acoburn> RRSAgent, make minutes
13:56:30 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/14-lws-minutes.html acoburn
13:56:40 <TallTed> present+
13:56:57 <acoburn> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250714T100000/#agenda
13:56:57 <agendabot> clear agenda
13:56:57 <agendabot> agenda+ Introductions and Announcements
13:56:57 <agendabot> agenda+ Action Items
13:56:57 <agendabot> agenda+ Requirement list winnowing
13:57:21 <TallTed> previous meeting: https://www.w3.org/2025/07/07-lws-minutes.html
13:57:21 <TallTed> next meeting: https://www.w3.org/2025/07/21-lws-minutes.html
13:57:25 <eBremer> eBremer has joined #lws
13:57:39 <acoburn> chair: acoburn
13:57:44 <acoburn> present+
13:58:46 <eBremer> present+
14:00:33 <gibsonf1> gibsonf1 has joined #lws
14:00:36 <kaefer3000> kaefer3000 has joined #lws
14:00:39 <gibsonf1> present+
14:00:57 <ericP> ericP has joined #lws
14:01:57 <dmitriz> dmitriz has joined #lws
14:02:04 <ryey> ryey has joined #lws
14:02:35 <kaefer3000> present+
14:02:59 <ryey> present+
14:03:16 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/14-lws-minutes.html TallTed
14:03:22 <hadrian> hadrian has joined #lws
14:03:22 <hadrian> present+
14:03:49 <acoburn> scribenick: dmitriz
14:03:54 <dmitriz> present+
14:03:56 <dmitriz> scribe+
14:04:18 <acoburn> zakim, open agendum 1
14:04:18 <Zakim> agendum 1 -- Introductions and Announcements -- taken up [from agendabot]
14:04:40 <dmitriz> acoburn: today is going to be a lot about looking at the Requirements
14:04:47 <bendm> bendm has joined #lws
14:04:52 <bendm> present+
14:05:25 <jeswr> jeswr has joined #lws
14:05:28 <jeswr> present+
14:05:43 <Monsecom> Monsecom has joined #lws
14:05:50 <Monsecom> present+
14:06:19 <acoburn> zakim, open agendum 2
14:06:19 <Zakim> agendum 2 -- Action Items -- taken up [from agendabot]
14:06:44 <dmitriz> acoburn: I know Pierre-Antoine is working on Echidna integration on our Use Cases & Reqs doc
14:06:55 <dmitriz> ... I know there's some open PRs. if he does join later, we may come back to this one
14:07:06 <dmitriz> ... unless Hadrian or Eric B. knows where that stands
14:07:41 <dmitriz> hadrian: I did review and approve the PR. There's an issue with HTML generation, so I haven't merged it yet
14:08:11 <dmitriz> acoburn: I'll add an action to follow up with Pierre-Antoine to sort out Echidna
14:08:27 <kaefer3000> q+
14:08:41 <dmitriz> ... I know there's an open PR 168, and a related issue about duplication of definitions...
14:08:51 <dmitriz> ... once all that gets settled, which I think is more of an editorial kind of decision
14:09:00 <dmitriz> ... but if you want to just move forward with that, please do
14:09:03 <acoburn> ack next
14:09:22 <dmitriz> kaefer3000: what's the best way of following the Use Cases discussion today, on our screen?
14:09:40 <dmitriz> acoburn: I'll share a link. each PR has a Preview on it, so that's what I'll be linking to
14:11:06 <acoburn> -> https://pr-preview.s3.amazonaws.com/ebremer/lws-ucs/pull/170.html#requirements Requirements Section in PR 170
14:11:19 <hadrian> q+
14:11:26 <acoburn> ack next
14:12:09 <dmitriz> hadrian: we didn't know how many requirements will be on the list. so, those columns could have been many. we decided - if the table becomes too wide, we'll break it up into relevant sections
14:12:19 <dmitriz> acoburn: just ignore the table right now, it's for a future step
14:12:29 <dmitriz> ... lets jump to the next item
14:12:31 <acoburn> zakim, open agendum 3
14:12:31 <Zakim> agendum 3 -- Requirement list winnowing -- taken up [from agendabot]
14:13:14 <dmitriz> ... this gives us a first pass on reqs, not a final list by any means
14:13:21 <dmitriz> ... there are 44 requirements as of this PR. that's a lot
14:13:31 <dmitriz> ... there's also a lot in here that arguably should not be requirements
14:13:49 <dmitriz> ... this won't be formal voting, I just want a straw poll, to get a sense
14:14:26 <acoburn> -> https://docs.google.com/spreadsheets/d/1HrR4OcEQug41vmz_mRyKUmovzb4r2qULxm_-eS9vUAw/edit?gid=0#gid=0 Requirements triage
14:15:10 <dmitriz> ... so lets get a sense for high/medium/low priority for normative text
14:15:16 <dmitriz> ... and there will be some items we're just not doing
14:15:24 <dmitriz> ... I'm hoping to get a sense for clusters
14:16:43 <kaefer3000> q+
14:16:48 <TallTed> q+
14:16:49 <acoburn> ack next
14:17:04 <TallTed> q-
14:17:16 <dmitriz> kaefer3000: it would be great to know this discussion in advance, so we can be prepared
14:17:23 <TallTed> +1 advance notice of this polling would have been very helpful
14:17:26 <dmitriz> acoburn: that's why this is just a very preliminary straw poll discussion
14:17:54 <TallTed> even just as "a very preliminary straw poll"
14:18:29 <dmitriz> ... I think we can go over these at a high level (there will be multiple passes)
14:18:36 <dmitriz> ... the alternative is, we postpone this for another week
14:18:50 <gibsonf1> +1 on high level pass
14:19:28 <kaefer3000> q+
14:19:29 <dmitriz> acoburn: ok, lets at least go over these and identify what each one is, to familiarize
14:19:34 <acoburn> ack next
14:20:13 <dmitriz> kaefer3000: so, the first question on the column is "Plan to implement?". I just want to raise - we're here to specify a protocol, so there are some things that everybody must implement, but it shouldn't be part of the protocol
14:20:24 <dmitriz> ... so we should be clear that this is more of a 'should it be in the standard'
14:20:41 <dmitriz> acoburn: right, great question. I would expect that a number of these would have plenty of implementers, but not be part of the spec.
14:20:43 <dmitriz> q+
14:20:59 <dmitriz> ... for example, time series data support. there might be lots of interest, but no plans to implement it
14:21:21 <dmitriz> ... are there things that would make implementing hard? etc.
14:22:08 <acoburn> scribe+
14:22:20 <acoburn> dmitriz: the plan to implement is more about filtering items out
14:22:23 <acoburn> scribe-
14:22:40 <dmitriz> acoburn: ok, so, Personal Data Projection
14:23:19 <dmitriz> ... this is about 'can you take personal data of some sort, and convert it to other formats (consumable by non-LWS applications for example'
14:23:51 <gibsonf1> q+ to ask definition of personal data - anything in a data pod owned by a person?
14:23:58 <acoburn> ack next
14:24:01 <acoburn> ack next
14:24:02 <Zakim> gibsonf, you wanted to ask definition of personal data - anything in a data pod owned by a person?
14:24:18 <dmitriz> ... so let's do, 3 (high likelihood to implement), 2 (medium likelihood), 1 (low likelihood), 0 (non-normative), -1 (won't do)
14:26:09 <dmitriz> dmitriz: the question really seems to be "automated content negotiation on the _server side_"
14:26:09 <dmitriz> acoburn: right
14:26:16 <gibsonf1> q+ to say you would have to be more specific about which formats, etc
14:26:27 <acoburn> ack next
14:26:28 <Zakim> gibsonf, you wanted to say you would have to be more specific about which formats, etc
14:26:47 <dmitriz> gibsonf1: if added to the spec, it would need to specify which formats, right
14:27:28 <bendm> q+ how is this different from service integration?
14:27:41 <acoburn> ack next
14:28:13 <dmitriz> bendm: how is Personal Data Projection different form Service Integration? but lets just go over these and familiarize
14:28:26 <dmitriz> acoburn: yes, lets do that, we can spend this meeting going over and expanding the terms
14:28:45 <dmitriz> ... the question is going to be - server side vs client side
14:28:56 <dmitriz> ... (this is regarding Personal Data Projection)
14:28:59 <ryey> q+
14:29:05 <acoburn> ack next
14:29:10 <TallTed> q+
14:29:38 <dmitriz> ryey: I created that use case (data proj.), it applies to - converting between RDF data formats.
14:29:59 <acoburn> ack next
14:30:02 <jeswr> q+
14:30:09 <dmitriz> ... rather than RDF data to non-RDF
14:30:30 <dmitriz> TallTed: this feels like its' not so much asking the protocol to do the transformation, as it is asking the protocol to support the client requesting a different content type than the server might have on hand
14:30:34 <eBremer> q+
14:30:40 <dmitriz> ... so, this is more content negotiation.
14:31:11 <acoburn> ack next
14:31:35 <dmitriz> jeswr: it seems we're hitting an issue that these requirements are too ill-defined to have an in-depth discussion
14:32:09 <dmitriz> ... can I suggest that for the rest of the meeting, we time box each of these to 2-3 mins, and try and assign someone based on the discussion, to write out the requirement more clearly
14:32:09 <eBremer> q-
14:32:20 <dmitriz> acoburn: that would be great.
14:32:40 <dmitriz> ... ryey, would you be able to wordsmith and expand that requirement?
14:32:45 <dmitriz> ryey: sure
14:33:21 <kaefer3000> suggestion as per Ted's remark: add "the possibility to request" between support and projection
14:33:26 <dmitriz> acoburn: lets go to the next one. Profile Interaction UI
14:33:33 <dmitriz> ... standardizing a method for clients to fetch and display a profile
14:33:40 <dmitriz> ... specifically for interacting with contacts
14:33:47 <dmitriz> ... are there questions about this one?
14:33:53 <bendm> no questions about that
14:33:55 <gibsonf1> q+ don't quite understand it
14:34:06 <ryey> s/it applies to - converting between/it also applies to - converting between/
14:34:20 <acoburn> ack next
14:34:22 <dmitriz> ... both of these items came from Sir Tim. I suspect they have to do with a Data Browser like UI
14:34:22 <TallTed> q+
14:34:47 <dmitriz> gibsonf1: can you give some examples of these, how would the UI trigger, what would the UI be for? I don't quite understand it
14:35:16 <dmitriz> TallTed: to me, this feels like two different things. 1) fetch and display profile, very different from 2) follow message or share (that seems more like ActivityPub domain)
14:35:26 <dmitriz> ... so, number 43 be two separate things
14:35:45 <eBremer> i can do it
14:35:47 <dmitriz> acoburn: any volunteers to clarify the text or refactor the wording?
14:36:09 <dmitriz> acoburn: next one, Bring Your Own Data apps
14:36:19 <dmitriz> ... enabling third party applications to interact with user-managed storage, to discover capabilities.
14:36:31 <dmitriz> ... my first question is - is this actually a requirement? seems more like a user story
14:36:36 <kaefer3000> q+ to ask what a Storage capability is
14:36:42 <jeswr> agree that it is more a story
14:36:47 <acoburn> ack next
14:36:49 <gibsonf1> q+ on app generated data definition
14:37:13 <dmitriz> kaefer3000: what kind of capabilities are foreseen here? unclear.
14:37:26 <bendm> q+ to combine/replace it with 20
14:37:27 <acoburn> q?
14:37:31 <dmitriz> acoburn: this is an extremely broad requirement, it's more of a 'this is the whole point of the spec' kind of thing
14:37:38 <acoburn> ack next
14:37:39 <Zakim> kaefer, you wanted to ask what a Storage capability is
14:37:41 <acoburn> ack next
14:37:42 <Zakim> gibsonf, you wanted to comment on app generated data definition
14:37:49 <dmitriz> gibsonf1: app generated content versus what
14:37:55 <dmitriz> ... what's non-app-generated content?
14:38:15 <dmitriz> acoburn: I'm kind of in agreement with Dmitri - this is less a requirement and more of a high level description of this whole project
14:38:18 <TallTed> q+
14:38:46 <acoburn> ack next
14:38:47 <Zakim> bendm, you wanted to combine/replace it with 20
14:38:48 <dmitriz> kaefer3000: the key here - the app can manage its own data, versus that of other apps. maybe that clarifies?
14:39:16 <dmitriz> bendm: requirements 7 and 20 already cover this, I don't see what item 42 adds.
14:39:25 <dmitriz> acoburn: would you be able to take this one and maybe combine it with the others?
14:39:31 <jeswr> q+ can we just remove this requirement now?
14:39:36 <acoburn> q?
14:39:37 <dmitriz> bendm: sure.. I'll just remove it, and make sure everything is covered by 7 and 20
14:39:40 <acoburn> ack next
14:40:11 <dmitriz> TallTed: this feels premature. a 'bring your own data' app is one to which you feed data which came from someplace else. it's not about the app managing its own data, it's about the app interacting with _my_ data I already had
14:40:27 <dmitriz> ... so for example, I'm changing my photo album app from one to another, keeping all the photos, tags, metadata, etc.
14:40:35 <dmitriz> ... just changing the tool I'm interacting with photos, etc.
14:41:10 <gibsonf1> That sounds like semantic interoperability
14:41:46 <dmitriz> acoburn: let's go to Network Flexibility. can the protocol work in environments with dynamic IPs, NATs, etc
14:42:09 <dmitriz> ... my initial reaction is - why do we want to specify routing in the protocol, that seems way too low-level
14:43:16 <dmitriz> acoburn: next, Self-Describing Website Publication.
14:43:27 <dmitriz> ... can you do website content hosting directly from storage
14:43:52 <TallTed> q+
14:43:56 <acoburn> ack next
14:43:57 <bendm> q+ to ask whether that's actually requiring transformations
14:43:57 <gibsonf1> +1 on generating website (already supported TrinPod)
14:44:15 <dmitriz> TallTed: yeah, I don't think this is about Projection. I'm not sure that any part of this really belongs in the LWS protocol.
14:44:34 <dmitriz> ... this is more of an application of a number of tech that already exists, like HTTP, DNS, content type headers, etc
14:44:37 <gibsonf1> q+ on website
14:44:45 <acoburn> ack next
14:44:46 <Zakim> bendm, you wanted to ask whether that's actually requiring transformations
14:45:00 <dmitriz> bendm: I was going to say the same, not about transformation, just about serving existing content from off-server
14:45:05 <acoburn> ack next
14:45:06 <Zakim> gibsonf, you wanted to comment on website
14:45:28 <dmitriz> gibsonf1: on this one, we support it, and it does require server work, to say that a website's files (html etc) be displayed as a website
14:46:02 <kaefer3000> q+
14:46:09 <acoburn> ack next
14:46:14 <dmitriz> acoburn: lets go to Time Series Data support
14:46:27 <dmitriz> kaefer3000: issue 31 is quite extensive, maybe we need a summary/clarification?
14:46:34 <dmitriz> acoburn: I agree
14:46:54 <gibsonf1> +1
14:47:00 <dmitriz> ... I think issue 31 was an automated summary of what existed in those issues. Fred, can you go back and make sure the requirement is an accurate distillation of the issue? thanks
14:47:19 <dmitriz> acoburn: ok, Time Series Data Support. this involves storing, querying and aggregating time-based resources for multi-dimensional analysis
14:47:30 <TallTed> q+
14:47:37 <acoburn> ack next
14:47:45 <dmitriz> TallTed: again, I'm not sure this belongs in protocol
14:48:14 <bendm> q+ how is that different from 44?
14:48:16 <dmitriz> ... some of this is - this is the first time we're looking at this
14:48:26 <acoburn> ack next
14:48:30 <dmitriz> acoburn: that's fine, my gut reaction too is that it's not appropriate for the protocol
14:48:39 <ericP> ericP has joined #lws
14:48:46 <dmitriz> bendm: yes, I was wondering, protocol capability wise, how the original need is different from creating projections on top of existing data
14:49:02 <ryey> q+
14:49:08 <acoburn> ack next
14:49:25 <kaefer3000> q+
14:49:30 <dmitriz> ryey: to me, the time series thing implies a performance requirement
14:49:47 <acoburn> ack next
14:50:19 <dmitriz> kaefer3000: the examples in the use case is just storing data about readings into a pod. no mention of aggregation
14:50:27 <dmitriz> ... but the issue is fairly generic, not sure we need to keep it
14:51:01 <dmitriz> acoburn: I'll reach out to Jacopo, ask him to clarify
14:51:06 <dmitriz> ... and next week we can decide
14:51:15 <dmitriz> ... ok, we have time for probably one or two more
14:51:29 <dmitriz> acoburn: ok, Collaborative Editing -- this is basically CRDT merges, concurrency support, locking
14:51:43 <dmitriz> ... anyone want to elaborate?
14:51:47 <gibsonf1> q+
14:51:52 <acoburn> ack next
14:52:50 <jeswr> q+
14:53:14 <acoburn> ack next
14:53:22 <dmitriz> acoburn: does anyone want to clarify this one?
14:53:38 <dmitriz> dmitriz: I might, depending on what the other stories on replication and sync are
14:53:49 <kaefer3000> it was said that collaborative editing is just a special case of replicate and sync
14:53:49 <dmitriz> jeswr: we should ask NextGraph for clarification on this one
14:54:08 <TallTed> q+
14:54:09 <dmitriz> ... on what client and server capabilities are
14:54:14 <acoburn> ack next
14:54:18 <dmitriz> dmitriz: agree
14:54:26 <dmitriz> TallTed: this feels like this overlaps with bring your own data apps?
14:55:00 <dmitriz> acoburn: ok, tiem for one more
14:55:06 <dmitriz> ... Delivery Receipts.
14:55:23 <dmitriz> ... this one is - does the protocol have a mechanism for sending verifiable receipts or acks when resources are created, modified, requested
14:55:29 <kaefer3000> q+
14:55:54 <dmitriz> ... this came from the Auditable Proof/Receipt of Authorization issue
14:55:56 <acoburn> ack next
14:56:12 <dmitriz> ..kaefer3000: yes, sounds a lot like auditing, so, this needs logging functionality
14:56:35 <dmitriz> ... the thing in the other document is a bit different (delivery receipts)
14:56:55 <gibsonf1> q+ sounds like Read event (and write event etc)
14:57:13 <dmitriz> acoburn: yes, this sounds like item 9, Auditable Trail. those should be combined
14:57:37 <acoburn> ack next
14:57:49 <TallTed> should it be downloadable once? or as many times as the authorized authenticated entity GETs it? or....? (and does this belong in protocol, or in data management?)
14:58:08 <dmitriz> gibsonf1: this sounds more generic - read/write event audit, rather than purchases specifically
14:58:11 <dmitriz> acoburn: ok, we're at time
14:58:19 <TallTed> some software sales permit license to be downloaded once (though it can then be replicated); others allow re-downloads
14:58:25 <dmitriz> ... let's stop for today, we'll continue over the next week or two
14:58:27 <kaefer3000> I asked whether should auditable trail, i.e. logging changes in access rights, be part of the prodotol?
14:58:38 <dmitriz> ... please review these and familiarize
14:58:41 <kaefer3000> q+
14:58:49 <jeswr> q+
14:58:50 <acoburn> ack next
14:59:02 <bendm> I'm happy to have a look at 37 to merge with 9
14:59:12 <dmitriz> kaefer3000: we've had a few instances of - the summary doesn't match the issues. can we do a quality pass over this?
14:59:39 <bendm> q+ to say to edit 37/9
15:00:26 <dmitriz> jeswr: I was going to suggest - for the items we haven't covered yet, people can go through them and identify ones they can elaborate requirements for async
15:00:33 <dmitriz> ... do we have a mechanism for people to self-assign?
15:00:43 <dmitriz> ... and also do the quality assurance etc
15:01:12 <bendm> can we meanwhile get suggestion/review rights on https://docs.google.com/spreadsheets/d/1HrR4OcEQug41vmz_mRyKUmovzb4r2qULxm_-eS9vUAw/edit?gid=0#gid=0 ?
15:01:59 <acoburn> RRSAgent, make minutes
15:02:01 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/14-lws-minutes.html acoburn