13:48:28 <RRSAgent> RRSAgent has joined #lws
13:48:32 <RRSAgent> logging to https://www.w3.org/2026/07/06-lws-irc
13:48:32 <Zakim> Zakim has joined #lws
13:49:04 <acoburn> acoburn has changed the topic to: Linked Web Storage WG - 2026-07-06 - https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20260706T100000/
13:49:12 <acoburn> zakim, start meeting
13:49:12 <Zakim> RRSAgent, make logs Public
13:49:14 <Zakim> please title this meeting ("meeting: ..."), acoburn
13:49:24 <acoburn> meeting: Linked Web Storage
13:49:37 <acoburn> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20260706T100000/#agenda
13:49:37 <agendabot> clear agenda
13:49:37 <agendabot> agenda+ Introduction & Announcements
13:49:37 <agendabot> agenda+ Vote: Storage Description & CID (PR -> https://github.com/w3c/lws-protocol/pull/183 https://github.com/w3c/lws-protocol/pull/183 )
13:49:37 <agendabot> agenda+ Discussion: Auxiliary Resources next steps (PR -> https://github.com/w3c/lws-protocol/pull/180 https://github.com/w3c/lws-protocol/pull/180 )
13:49:39 <agendabot> agenda+ Discussion: Notifications data model (PR -> https://github.com/w3c/lws-protocol/pull/185 https://github.com/w3c/lws-protocol/pull/185 )
13:49:42 <agendabot> agenda+ Discussion: Introduction text (PR -> https://github.com/w3c/lws-protocol/pull/158 https://github.com/w3c/lws-protocol/pull/158 )
13:49:53 <acoburn> rrsagent, make minutes
13:49:54 <RRSAgent> I have made the request to generate https://www.w3.org/2026/07/06-lws-minutes.html acoburn
13:50:55 <acoburn> previous meeting: https://www.w3.org/2026/06/29-lws-minutes.html
13:51:10 <acoburn> next meeting: https://www.w3.org/2026/07/13-lws-minutes.html
13:51:17 <acoburn> chair: acoburn
13:51:35 <acoburn> present+
13:57:38 <termontwouter> termontwouter has joined #lws
13:58:33 <TallTed> present+
13:59:16 <acoburn> rrsagent, make minutes
13:59:17 <RRSAgent> I have made the request to generate https://www.w3.org/2026/07/06-lws-minutes.html acoburn
14:00:09 <ericP> ericP has joined #lws
14:00:35 <elf-pavlik> elf-pavlik has joined #lws
14:00:48 <ericP> present+
14:00:54 <elf-pavlik> present+
14:00:56 <eBremer> eBremer has joined #lws
14:01:02 <termontwouter> present+
14:01:35 <gibsonf1> gibsonf1 has joined #lws
14:01:42 <gibsonf1> present+
14:02:18 <pchampin> present+
14:02:32 <laurens> laurens has joined #lws
14:02:34 <laurens> present+
14:03:15 <jeswr> jeswr has joined #lws
14:03:22 <eBremer> present+
14:03:29 <acoburn> zakim, open agendum 1
14:03:29 <Zakim> agendum 1 -- Introduction & Announcements -- taken up [from agendabot]
14:03:33 <gibsonf1> scribe+
14:03:34 <jeremycaine> jeremycaine has joined #lws
14:03:42 <jeremycaine> present+
14:04:51 <gibsonf1> acoburn: a few other small things after main agenda items.  Any announcements?
14:05:03 <acoburn> zakim, open agendum 2
14:05:03 <Zakim> agendum 2 -- Vote: Storage Description & CID (PR -> https://github.com/w3c/lws-protocol/pull/183 https://github.com/w3c/lws-protocol/pull/183 ) -- taken up [from agendabot]
14:05:21 <ryey> ryey has joined #lws
14:05:24 <ryey> present+
14:06:22 <gibsonf1> ... takes current storage description with same structure and uses cid documents rather than invent lws specific things.
14:06:25 <elf-pavlik> q+ to ask if it impacts storage id ?== storage root in any way
14:06:32 <acoburn> ack next
14:06:33 <Zakim> elf-pavlik, you wanted to ask if it impacts storage id ?== storage root in any way
14:07:04 <gibsonf1> elf-pavlik: does this impact storage vs root container id?
14:08:41 <jeswr7> jeswr7 has joined #lws
14:08:49 <gibsonf1> acoburn: Needs to be canonical url - it may need to be root or identifier of storage
14:09:49 <gibsonf1> elf-pavlik: like the approach
14:09:51 <gibsonf1> q+
14:10:06 <jeswr> q+ reminder on what is the value of making this a CID
14:10:12 <acoburn> ack next
14:10:16 <acoburn> scribe+
14:10:50 <acoburn> gibsonf1: a little worried about this now. If the CID has to be the root container, that might case problems.
14:11:00 <elf-pavlik> as I understand we would have storage !== root container with this approach
14:11:12 <TallTed> s/might case problems/might cause problems/
14:11:14 <elf-pavlik> due to access control impact I think
14:11:20 <pchampin> q+
14:11:23 <acoburn> ... if the CID is the storage itself as an entity and if it needs to == root container, it would make it difficult to have multiple root containers
14:11:33 <TallTed> q?
14:11:50 <TallTed> q- reminder
14:11:58 <gibsonf1> acoburn: yes, we need to work this out before moving on of storage vs root.
14:12:18 <elf-pavlik> q+ to comment on potential benefits
14:12:33 <gibsonf1> jeswr: is the cid just a describer of metadata
14:12:39 <elf-pavlik> q+ dmitri
14:12:48 <gibsonf1> acoburn: this just allows us to reuse the cid structure
14:13:05 <acoburn> ack elf-pavlik
14:13:05 <Zakim> elf-pavlik, you wanted to comment on potential benefits
14:13:10 <dmitriz> dmitriz has joined #lws
14:13:22 <dmitriz> q+
14:13:48 <gibsonf1> elf-pavlik: could be useful for webhooks , would like to explore this more
14:13:55 <acoburn> ack next
14:14:05 <elf-pavlik> q- dmitri
14:14:43 <elf-pavlik> +1 to pchampin clarification
14:15:03 <gibsonf1> pchampin: respond to gibsonf1 - no risk that this would force storage to be same as root container - it does not prevent storage and root container to be same but can easily be separate
14:15:10 <acoburn> ack next
14:15:39 <acoburn> q?
14:15:40 <gibsonf1> dmitriz: I think its fine to separate storage from root container
14:15:48 <elf-pavlik> +1 to just having storage and root container separate and use CID
14:16:20 <gibsonf1> acoburn: given discussion, need to clarify this more before going to a vote
14:16:24 <gibsonf1> +1
14:16:37 <acoburn> zakim, open agendum 3
14:16:37 <Zakim> agendum 3 -- Discussion: Auxiliary Resources next steps (PR -> https://github.com/w3c/lws-protocol/pull/180 https://github.com/w3c/lws-protocol/pull/180 ) -- taken up [from
14:16:40 <Zakim> ... agendabot]
14:18:29 <termontwouter> give me a sec
14:18:58 <elf-pavlik> q+ to request a document to use as a reference (rule of thumb) for when to use media-type, profile, preference etc.
14:21:43 <gibsonf1> termontwouter: the idea is if you have a resource and linkset at same url can retrieve using content negotiation.
14:22:17 <TallTed> big echo via wouter ... please mute when not speaking
14:22:25 <dmitriz> +1 to what Aaron is saying - linkset via conneg will be tough, better give it its own url
14:22:44 <TallTed> s/big echo via wouter ... please mute when not speaking//
14:23:17 <termontwouter> termontwouter has joined #lws
14:23:25 <termontwouter> q+
14:23:33 <gibsonf1> acoburn: main concern is that by using content location, server could have trouble content negotating with the string.  Prefer header might be a better way to do it.  By reserving a type, we will necessarily restrict a server from storing a content of that media type.
14:23:35 <gibsonf1> q+
14:23:36 <acoburn> ack next
14:23:37 <Zakim> elf-pavlik, you wanted to request a document to use as a reference (rule of thumb) for when to use media-type, profile, preference etc.
14:24:20 <pchampin> q+
14:25:16 <gibsonf1> elf-pavlik: could establish a common way to do it.  probably can use same approach with linkset and container with the content-type.
14:25:57 <gibsonf1> acoburn:  Being consistent is a generally good.  Maybe open an issue on this.
14:26:26 <gibsonf1> ... we can just open the issue and continue discussion there
14:26:32 <acoburn> ack next
14:28:18 <gibsonf1> termontwouter: agree that container is the same problem.  I agree its ideal to ask for metadata directly, not clear that using a header also specifies the format of the response as a content-type would.
14:28:33 <acoburn> -> profile parameter in linkset RFC https://www.rfc-editor.org/rfc/rfc9264.html#name-the-profile-parameter-for-m
14:28:40 <acoburn> ack next
14:28:43 <acoburn> scribe+
14:29:12 <acoburn> gibsonf: what is the concern about saving files
14:30:48 <gibsonf1> acoburn:  Want to be careful about different media-types being stored.  For example, specifying not storing json etc.  Linksets are a niche case, but any constraints on particular media-types should have a high bar on being supported.  and be very careful about this.
14:30:50 <gibsonf1> q+
14:31:43 <acoburn> gibsonf1: from my perspective, the Accept content-type is what a server sends back
14:33:12 <gibsonf1> acoburn:  example: 2 LWS servers.  If implementations are saving things as files, if there is a memento version, there would be some confustion.
14:33:19 <gibsonf1> q+
14:34:20 <acoburn> gibsonf1: so basically, if an impl is saving resources as direct files (bytes), there might be problems
14:34:29 <termontwouter> q+
14:34:49 <pchampin> I claim this is a spec issue, and I can explain why
14:34:57 <acoburn> ack next
14:35:50 <elf-pavlik> gibsonf1 underlying storage, filesystem, db, object storage etc. doesn't seem relevant to anything discussed here
14:35:59 <acoburn> scribe-
14:36:41 <gibsonf1> pchampin: this is a spec problem: whenever accept media type x, it does have some implications with primary vs auxialry resources.
14:36:48 <elf-pavlik> q+ to request more snippets http headers + body in the issue
14:37:01 <acoburn> ack termontwouter
14:38:22 <gibsonf1> termontwouter: agree its a spec problem.  Agree with pchampin on just using linkset type, but do not see the problem of a server saving it in a way they prefer
14:38:27 <acoburn> ack elf-pavlik
14:38:27 <Zakim> elf-pavlik, you wanted to request more snippets http headers + body in the issue
14:38:28 <pchampin> I agree that the 'profile' trick reduces the surface of the issue, and makes it potentially acceptable, but that's a hack :)
14:38:55 <pchampin> q+
14:40:02 <gibsonf1> elf-pavlik: the memento example sounds interesting - would like to hear more on that.  would like to ehar more from Erik Wilde
14:40:34 <gibsonf1> dmitriz: Why the general approach of switching to auxiliary resource on content negotation instead of a separate url
14:41:16 <gibsonf1> acoburn: Inrupt will generally use a separate url for auxiliary resource.  In this group how to negotiate if using the same url.
14:41:29 <acoburn> scribe+
14:41:30 <elf-pavlik> i don't see it as switching just supporting such approach as option/optimisation
14:41:41 <acoburn> gibsonf1: our use case has a single resource
14:41:52 <acoburn> ... the client can ask for various representations
14:42:00 <acoburn> ... no aux resources, just one resource
14:42:21 <acoburn> dmitriz: how do you deal with binary blobs? text encoding?
14:42:40 <acoburn> gibsonf1: our data is all RDF. Files are pointers from within the RDF
14:42:42 <elf-pavlik> q+ to clarify the text encoding question
14:43:16 <acoburn> ... any entity has multiple states, and the state can be serialized as a triple. Hence a tree resource
14:43:26 <acoburn> ... compound resource is what some might call it
14:43:32 <acoburn> q?
14:43:42 <acoburn> ack next
14:44:18 <acoburn> ack next
14:44:26 <acoburn> scribe-
14:47:22 <gibsonf1> pchampin: trying to optimize on this with primary vs auxiliary resource to reduce hops.  The same might apply for metadata etc, this is why the profile trick might lead to more complexity (a hack)  to acoburn, for the case where primary and auxiliary resource are the same, scary that differen responses with same media type
14:48:46 <gibsonf1> pchampin:  I thought acoburn meant that I could get different linkset responses in the same linkset media type on same uri whether or not I include the prefer header
14:49:30 <termontwouter> q+
14:50:15 <acoburn> ack next
14:50:16 <Zakim> elf-pavlik, you wanted to clarify the text encoding question
14:50:46 <pchampin> s/the prefer header/the prefer header, and I would not like that
14:51:15 <gibsonf1> elf-pavlik: would be good to have artifacts from conclusion of conversations.  What do you mean by text encoding vs binary?
14:52:56 <gibsonf1> dmitriz: just curious how implementation internal saving of files.  To me there is a conceptual difference between primary and auxiliary resources.  For me they are completely difference.  They have different access controls, different lifecycles, etc.
14:52:59 <gibsonf1> q+
14:53:17 <acoburn> ack next
14:53:25 <gibsonf1> acoburn:  I think you're right to this getting to a key question on these different resources
14:54:46 <elf-pavlik> q+ to request keeping discussion focused on real world usage examples
14:54:52 <pchampin> dmitriz, I agree this is conceptual difference; note that the current text *allows* some auxiliary resources to be the same as the primary resources, as an implementation choice
14:55:11 <gibsonf1> termontwouter: the point of the PR was about being able to implement in different ways.  I don't think the prefer header spec would always return same representation with different content type
14:55:26 <elf-pavlik> q-
14:55:46 <acoburn> ack next
14:56:22 <acoburn> gibsonf: one worries was about talking about resources in this way, where we get away from HTTP talking about resources
14:56:39 <pchampin> termontwouter, I read RFC7240 (the return=representation.concise part) differently than you; I don't think it contradicts my earlier point, but we can take this offline
14:56:51 <acoburn> ... in an ideal world, we don't have aux ideas to describe first idea
14:57:04 <acoburn> ... there are impls that require separate resources
14:57:26 <termontwouter> +1 to Fred's point about resource-based terminology
14:57:32 <acoburn> ... in our impl architecture, all different representations can be unified under a single resource
14:58:58 <pchampin> RRSAgent, make minutes
14:58:59 <RRSAgent> I have made the request to generate https://www.w3.org/2026/07/06-lws-minutes.html pchampin
14:59:33 <acoburn> present+ dmitriz
14:59:45 <acoburn> present+ jeswr
15:00:01 <acoburn> rrsagent, make minutes
15:00:03 <RRSAgent> I have made the request to generate https://www.w3.org/2026/07/06-lws-minutes.html acoburn