13:38:20 <RRSAgent> RRSAgent has joined #lws
13:38:24 <RRSAgent> logging to https://www.w3.org/2025/07/28-lws-irc
13:38:24 <Zakim> Zakim has joined #lws
13:38:30 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/28-lws-minutes.html TallTed
13:39:13 <TallTed> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250728T100000/
13:39:13 <agendabot> clear agenda
13:39:13 <agendabot> agenda+ Introductions and announcements
13:39:13 <agendabot> agenda+ Action Items
13:39:13 <agendabot> agenda+ Continued clarification of requirements
13:39:37 <TallTed> TallTed has changed the topic to: Linked Web Storage Meeting 2025-07-28 -- Agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250728T100000/
13:40:23 <TallTed> previous meeting: https://www.w3.org/2025/07/21-lws-minutes.html
13:40:23 <TallTed> next meeting: https://www.w3.org/2025/08/04-lws-minutes.html
13:44:40 <acoburn> acoburn has joined #lws
13:58:32 <acoburn> zakim, start meeting
13:58:32 <Zakim> RRSAgent, make logs Public
13:58:34 <Zakim> please title this meeting ("meeting: ..."), acoburn
13:58:37 <acoburn> meeting: Linked Web Storage
13:58:40 <acoburn> chair: acoburn
13:58:46 <TallTed> agenda?
13:58:47 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/28-lws-minutes.html TallTed
13:59:00 <gibsonf1> gibsonf1 has joined #lws
13:59:30 <acoburn> thanks, TallTed
14:01:05 <gibsonf1> present+
14:01:41 <eBremer> eBremer has joined #lws
14:01:43 <TallTed> present+
14:01:44 <ericP> ericP has joined #lws
14:01:51 <ericP> present+
14:01:56 <eBremer> present+
14:02:05 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/28-lws-minutes.html TallTed
14:02:11 <bendm> bendm has joined #lws
14:02:11 <acoburn> present+
14:02:15 <bendm> present+
14:02:24 <acoburn> present hadrian
14:02:33 <acoburn> RRSAgent, draft minutes
14:02:35 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/28-lws-minutes.html acoburn
14:02:50 <acoburn> scribenick: bendm
14:03:01 <TallTed> s/present hadrian/present+ hadrian/
14:03:18 <kaefer3000> kaefer3000 has joined #lws
14:03:19 <RazaN> RazaN has joined #lws
14:03:24 <kaefer3000> present+
14:03:25 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/28-lws-minutes.html TallTed
14:03:44 <jeswr> jeswr has joined #lws
14:03:59 <acoburn> zakim, open agendum 1
14:03:59 <Zakim> agendum 1 -- Introductions and announcements -- taken up [from agendabot]
14:04:17 <jeswr> present+
14:04:26 <RazaN> present+
14:04:29 <bendm> acoburn: any announcements?
14:04:50 <ryey> ryey has joined #lws
14:04:50 <bendm> (crickets)
14:04:54 <ryey> present+
14:04:59 <acoburn> zakim, open agendum 2
14:04:59 <Zakim> agendum 2 -- Action Items -- taken up [from agendabot]
14:05:13 <bendm> acoburn: previous hour, chairs and editors were chatting
14:05:22 <bendm> ... we went through the open issues
14:05:22 <bendm> ...
14:05:30 <bendm> ... pending pull requests have been merged
14:05:39 <bendm> ... we're moving these PRs through
14:05:50 <bendm> ... to make the repositories more manageable
14:06:05 <bendm> ... any other open action items before we go to agendum 3?
14:06:22 <bendm> ... there was some open tasks on clarifying use cases and requirements
14:06:38 <acoburn> zakim, open agendum 3
14:06:38 <Zakim> agendum 3 -- Continued clarification of requirements -- taken up [from agendabot]
14:06:40 <dmitriz> dmitriz has joined #lws
14:07:13 <bendm> acoburn: we started with 44 reqs
14:07:17 <bendm> ... we now have 41, that's good
<bendm> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250728/#dfn-service-integration-authentication Requirement Service integration authentication
14:07:27 <bendm> ... we're at #29
14:07:41 <bendm> ... we're basically halfway there
14:07:53 <uvdsl> uvdsl has joined #lws
14:08:34 <bendm> jesswr: to get to something more workable, to a wide range of stakeholders, I propose we start next week forward from one part of the spec, and bring that tot the stakeholders
14:08:48 <bendm> ... reasonable place to start is personal cloud storage
14:08:58 <bendm> ... I started to reach out to stakeholders
14:09:35 <bendm> ... to see who the right other group to engage with are
14:10:04 <bendm> ... my proposal: next week, focus on access grant and access control, starting from user interfaces (?)
14:10:08 <eBremer> eBremer has joined #lws
14:10:16 <eBremer> present+
14:10:25 <bendm> ... today, finish on prioritization
14:10:52 <dmitriz> I think it might be most helpful for this group to specifically focus on the _data model_ of the access control and grant requests.
14:11:11 <dmitriz> because the protocols for those are already decently defined (like IETF's GNAP, w3c's VP Request, etc)
14:11:42 <bendm> acoburn: 29 items to get through is a lot for today, we should go through as much as possible
14:11:53 <bendm> ... we want to set up jesse and eric to move on the actual protocol work
14:12:06 <bendm> ... #29 service integration authentication
14:12:23 <bendm> ... a lot on browser level, this is about auth for everything else
14:12:32 <bendm> ... bots, server-to-server, scripts
14:13:08 <gibsonf1> q+ to ask, would definitely like this one in scope
14:13:15 <bendm> ... (not issue 29, but requirement 29)
14:13:42 <bendm> jesswr: I suggest to reframe this as serverside authentication, not have requirements for specific authentication
14:13:45 <acoburn> ack next
14:13:46 <Zakim> gibsonf, you wanted to ask, would definitely like this one in scope
14:13:59 <bendm> gibsonf1: it would be great to have guidance on this, to have interop between servers
14:14:02 <TallTed> q+
14:14:12 <bendm> acoburn: we don't want to invent a new protocol here, but reuse existing
14:14:13 <acoburn> ack next
14:14:44 <bendm> tallted: the title is unclear for me, phrasing should be better
14:14:48 <bendm> acoburn: I agree
14:15:13 <dmitriz> the good news with this one is that it's a fairly solved space - mtls and http signatures.
14:15:15 <bendm> eBremer: I have a PR open
14:15:28 <bendm> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250728/#dfn-protocol-binding-independence Requirement Protocol binding independence
14:15:28 <bendm> acoburn: req 28: protocol binding independence
14:15:56 <jeswr> jeswr has joined #lws
14:16:10 <jeswr> +1 out of scope
14:16:15 <bendm> ... I suspect this is out of scope of this, but in scope of a separate layer that uses LWS
14:16:19 <kaefer3000> +1 out of scope
14:16:22 <uvdsl> +1
14:16:34 <gibsonf1> +1
14:16:39 <bendm> ... folks are broadly in consensus of that
14:16:52 <TallTed> perhaps "Loose Coupling of Underlying Protocols"
14:16:52 <bendm> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250728/#dfn-trusted-identity-providers Requirement Trusted identity providers
14:16:52 <bendm> ... req 27 Trusted Identity Providers
14:16:59 <bendm> ... this is about a governance model
14:17:13 <bendm> ... I suspect many deployments will have this
14:17:35 <bendm> .... e.g. I have service Y, IdP Z is not allowed by Y
14:17:39 <dmitriz> 27 seems out of scope for the spec.
14:17:47 <dmitriz> +1 to leaving it to implementations.
14:17:48 <jeswr> q+
14:17:51 <bendm> ... suspect implementations will do this any way, and we don't need to specify everything about this
14:17:55 <acoburn> ack next
14:18:12 <uvdsl> q+
14:18:17 <TallTed> q+ to note that trust is a moving target
14:18:17 <bendm> jeswr: governance is a huge challenge by a lot of different people, also outside Solid, so for me, completely out of scope (although very useful)
14:18:18 <acoburn> ack next
14:18:26 <ryey> q+
14:18:53 <bendm> uvdsl: I would this req 27 as follows: not about defining trust, but the requirement to support the definition of trusted identity providers
14:19:02 <bendm> ... i.e. restricting IdPs is possible at all
14:19:29 <ryey> q-
14:19:38 <dmitriz> also Identity Providers is both a vague term, and specific to individual authentication methods.
14:19:44 <ryey> +1 for uvdsl
14:19:48 <bendm> acoburn: so, there needs to be a mechanism to limit the scope of systems that it trusts?
14:20:03 <dmitriz> for example, in Server to Server authentication, who is the identity provider? etc.
14:20:15 <bendm> uvdsl: exact, otherwise a governance model is not possible at all, so that we technically provide the option to do it
14:20:24 <ryey> q+
14:20:28 <gibsonf1> q+ to ask about how an identity provider would not be trusted if identiny protocol used is sound
14:20:29 <bendm> acoburn: enterprise and commercially, that will happen regardless
14:20:31 <acoburn> ack next
14:20:32 <Zakim> TallTed, you wanted to note that trust is a moving target
14:20:33 <dmitriz> q+
14:20:49 <bendm> tallted: 'that will happen regardless' is a dangerous phrasing
14:21:00 <bendm> ... trust is a moving target, changes over time
14:21:28 <bendm> ... e.g. certificate structure: root certificate compromised required a lot of reconfiguration
14:21:48 <bendm> ... at some point, you need to be able to say 'do not trust anything from this location'
14:22:04 <acoburn> ack next
14:22:05 <bendm> ... the spec should give a way to administrators to do that
14:22:17 <bendm> ryey: I agree with Ted and Christoph
14:22:36 <bendm> ... my comment: who should be able to configure that?
14:23:01 <bendm> acoburn: relates to layers of trust: trust at the level of the pod owner is different from the level of an operator
14:23:04 <acoburn> q?
14:23:08 <acoburn> ack next
14:23:09 <Zakim> gibsonf, you wanted to ask about how an identity provider would not be trusted if identiny protocol used is sound
14:23:09 <bendm> ... if we go into this issue, we need to consider all layers
14:23:31 <bendm> gibsonf: This could easily be abused
14:23:32 <bendm> ...
14:23:50 <bendm> ... ideally, the IdP spec is so good that we could trust everyone, but these things could be circumvented
14:23:51 <acoburn> ack next
14:24:02 <bendm> dmitriz: I don't think this item makes sense
14:24:18 <bendm> ... IdP is only relevant in OpenID-Connect
14:24:28 <bendm> ... in other specs, there's no such notion
14:24:38 <bendm> ... this req presumes a specific authentication method
14:24:47 <bendm> ... so I think this should be out of scope
14:24:50 <TallTed> q+ to say that IdP is a term of use in current SWICG discussion of FedID and related (i.e., it's not just in OpenID)
14:24:58 <acoburn> ack next
14:24:59 <Zakim> TallTed, you wanted to say that IdP is a term of use in current SWICG discussion of FedID and related (i.e., it's not just in OpenID)
14:25:13 <bendm> tallted: IdP is a term of use in current SWICG discussion of FedID and related (i.e., it's not just in OpenID)
14:25:27 <bendm> ... it makes a lot of sense to have 'an identity provider'
14:25:37 <uvdsl> q+ to say that IDP may be just another term for issuer of VCs.
14:25:50 <bendm> dmitriz: It happens that FedID  also comes from the context of OpenID
14:25:57 <uvdsl> q-
14:25:59 <bendm> tallted: FedID is broader than OpenID
14:26:33 <bendm> acoburn: maybe we can rename this? to 'trusted identity mechanisms'? something more generic
14:26:47 <bendm> subtopic: Requirements -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250728/#dfn-modern-authentication-methods "Modern authentication methods" & -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250728/#dfn-user-centric-identity-management "User-centric identity management"
14:26:47 <bendm> ... req 26: modern authentication methods
14:26:56 <jeswr> q+
14:27:02 <acoburn> ack next
14:27:03 <bendm> ... this is even more related to OIDC
14:27:32 <dmitriz> so the challenge with this list, is that we're grouping together requirements for at least 3 specs (possibly more). 1) authentication spec, 2) authorization/access control, and 3) read/write protocol
14:27:34 <bendm> jeswr: 26 assumes centralized identity mechanisms, 25 says we should also support self-souvereign identity mechanisms
14:27:40 <TallTed> links please?
14:28:01 <dmitriz> at _very_ least, we should tag which specs the requirement belongs to
14:28:01 <bendm> ... suggestions: support more types of authentication mechanisms, without specifying what form in the requirement
14:28:15 <bendm> acoburn: grouping 25 and 26 makes sense
14:28:17 <eBremer> s/self-souvereign/self-sovereign
14:29:03 <TallTed> oh, you don't mean "merge PR #"; you mean "combine requirements # and #" (I still want links) *and titles*
14:29:04 <bendm> ... there's a similar req that has sub-options, so we could talk about the 'authentication requirement' and have centralized/self-sovereign/... options
14:29:12 <acoburn> q?
14:29:13 <TallTed> q+
14:29:22 <bendm> ebremer: will try to do a PR in the background to merge
14:29:39 <acoburn> ack next
14:30:32 <bendm> tallted: let's use titles and ids
14:31:00 <bendm> acoburn: yes, respec is using a consistent numbering, but we shouldn't refer to the numbers
<bendm> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250728/#dfn-legal-basis-enforcement Requirement Legal basis enforcement
14:31:13 <bendm> ... that said, now, we're talking about 'Legal Basis Enforcement'
14:32:01 <jeswr> q+
14:32:04 <bendm> ... tag access rules with legal grounds (e.g. GDPR)
14:32:06 <acoburn> ack next
14:32:26 <bendm> jeswr: sounds like out of scope for LWS, since we see usage control out of scope
14:32:31 <ryey> +1 for jesse
14:32:32 <ryey> q+
14:32:36 <acoburn> ack next
14:32:58 <dmitriz> q+
14:33:03 <bendm> ryey: I agree with Jesse, and - there might be different ways to specify this, not mature yet, so hard to do at this stage
14:33:08 <acoburn> ack next
14:33:48 <bendm> dmitriz: it seems like we're dealing with different specs: authentication, authorization, ReadWrite protocol
14:34:01 <bendm> ... can we tag/group requirements?
14:34:13 <bendm> acoburn: that's a great a suggestion
14:34:39 <bendm> ... would that help the editors? does it make sense to do?
14:34:58 <bendm> jeswr: it makes sense, Erich and I could do that asynchronously
<bendm> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250728/#dfn-consent-based-data-sharing Requirement Consent-based data sharing
14:35:08 <bendm> acoburn: let's move to 'consent-based data sharing'
14:35:16 <bendm> ... this is a little bit different than access control
14:35:25 <bendm> ... WAC/ACP just gives access
14:35:48 <bendm> ... consent-based model involves explicit interactions, usually has purpose and receipts, and is revokable
14:35:56 <uvdsl> q+
14:36:03 <acoburn> ack next
14:36:45 <bendm> uvdsl: I want to highlight there are two parts: (i) having the ability to give consent, and (ii) being able to verify the consent
14:36:52 <TallTed> change "duration" to (or add option for) "start/end datetime"
14:36:54 <bendm> ... you can support the former without the latter
14:36:57 <kaefer3000> q+
14:37:15 <TallTed> q+
14:37:28 <acoburn> ack next
14:37:34 <bendm> ... the first is like the cookie banner, the second is about cryptographic verification
14:37:44 <bendm> ebremer: I thought we discussed something about logging last time?
14:38:09 <ryey> q+
14:38:10 <bendm> ... that we discussed that it wasn't in scope?
14:38:13 <ryey> q-
14:38:30 <eBremer> ucdsl - I haven't forgotten.  I will be adding it as a linked glossary term to define it as cryptographic
14:38:35 <bendm> acoburn: did you mean 'Auditable Trail?' it was merged with one in the thirties
14:38:46 <eBremer> s/ucdsl/uvdsl
14:38:53 <ryey> q+ to ask difference between explicitly having the notion of "consent" vs using inbox and then an app to handle it
14:39:00 <uvdsl> eBremer, no worries :) just wanted to highlight it to the group as well!
14:39:12 <eBremer> uvdsl, absolutely! :-)
14:39:13 <acoburn> q?
14:39:27 <bendm> kaefer3000: so the second part of 'consent-based data sharing' is actually a point of current req 9
14:39:27 <acoburn> ack next
14:40:04 <bendm> tallted: 'duration' is a broad term, but usually you mean start datetime / end datetime
14:40:20 <bendm> ... the way these are being edited right now makes it hard to keep track of all terminology
14:41:10 <acoburn> q?
14:41:13 <bendm> ... caution: I suggest to just put things together, and do editing later
14:41:15 <acoburn> ack next
14:41:16 <Zakim> ryey, you wanted to ask difference between explicitly having the notion of "consent" vs using inbox and then an app to handle it
14:41:57 <uvdsl> q+
14:41:57 <bendm> ryey:  how is consent different from this being a message to an inbox and a consent handling app?
14:42:11 <bendm> ... is there a need for a different concept?
14:42:31 <acoburn> ack next
14:42:34 <bendm> acoburn: so, would this happen at a different layer than LWS?
14:43:01 <bendm> uvdsl: I think I agree with Aaron, at ryey: inbox is _an_ implementation
14:43:50 <bendm> q+ to say that conflating data interactions with authentication/authorization interactions (i.e. conflating them in the same level) was a bad thing in our dev experience
14:44:03 <bendm> acoburn: this is basically about interoperability
14:44:07 <TallTed> "consent" is a loaded term. "permission to see, read, update, delete" are better.
14:44:10 <bendm> ... so something to debate
14:44:15 <acoburn> ack next
14:44:16 <Zakim> bendm, you wanted to say that conflating data interactions with authentication/authorization interactions (i.e. conflating them in the same level) was a bad thing in our dev
14:44:16 <Zakim> ... experience
14:44:25 <TallTed> q+
14:44:44 <acoburn> scribe+
14:44:47 <bendm> bendm: to say that conflating data interactions with authentication/authorization interactions (i.e. conflating them in the same level) was a bad thing in our dev experience
14:44:58 <kaefer3000> q+
14:44:58 <acoburn> bendm: putting this into the storage layer can add complexities
14:45:03 <acoburn> q?
14:45:06 <acoburn> ack next
14:45:08 <acoburn> scribe-
14:45:25 <bendm> tallted: "consent" is a loaded term. it has legal things making it problematic, "permission to see, read, update, delete" are better.
14:45:52 <acoburn> q?
14:45:56 <acoburn> ack next
14:46:06 <bendm> acoburn: access grants and permissions are going to be a better terminology
14:46:32 <bendm> kaefer3000: I agree that part of consent should be part of another layer, but I wonder what is the minimum needed in the protocol to handle that
14:46:52 <bendm> ... the question is: how do we facilitate the discovery of the resource that such requests should be sent to?
14:47:04 <bendm> ... and so that consent modeling is not part of the spec
14:47:24 <bendm> ... so can we specify a small thing to facilitate the rest
<bendm> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250728/#dfn-data-integrity-verification Requirement Data integrity verification
14:47:41 <bendm> acoburn: next: "Data Integrity Verification"
14:47:50 <bendm> ... there are a number of IETF specifications to address this
14:48:00 <bendm> ... maybe we can just point people to best practice references?
14:48:14 <bendm> ... eg message signatures
14:48:36 <TallTed> q+
14:48:37 <dmitriz> q+
14:48:41 <bendm> ... basically: hash or signature-based mechanisms
14:48:43 <acoburn> ack next
14:48:44 <ericP> there's always TLS
14:49:00 <bendm> tallted: appropriate mechanism is going to vary with the data, how it's stored, how it's accessed
14:49:20 <bendm> ... i.e. encrypted at rest, in transit, etc., will impact the mechanism
14:49:40 <dmitriz> q-
14:49:40 <bengo> bengo has joined #lws
14:49:52 <bengo> present+
14:49:55 <bengo> q+
14:50:02 <uvdsl> present+
14:50:04 <bendm> ... we probably don't have to reinvent the wheel, we should need more loose coupling
14:50:40 <bendm> bengo: this is an important UC for our work, specifically on the write side
14:51:10 <bendm> ... what's not as obvious, is how a reader can later on know later on what the digest of the writer was
14:51:35 <uvdsl> q+ to ask what the specific use cases are for Data Integrity Verification
14:51:37 <bendm> ... I'd like to have affordances on how a server must preserve a digest, so a reader can have assurance
14:51:43 <acoburn> ack next
14:51:52 <acoburn> ack next
14:51:53 <Zakim> uvdsl, you wanted to ask what the specific use cases are for Data Integrity Verification
14:52:24 <bendm> uvdsl: what are the specific use cases for Data Integrity Verification?
14:52:47 <bendm> bengo: a lot is about activitypub data in and LWS server
14:53:12 <bendm> ... eg if I put photos in my LWS, how can I be sure that the server isn't tampering with it?
14:53:46 <bendm> ... eg news publishing: what is read from the server is guaranteed to be what was put by the writer, independent of the lws server
14:53:47 <ryey> q+
14:53:51 <TallTed> creator has to sign everything ... with reliable tools ... and write with reliable tools ... etc.
14:53:51 <ryey> q-
14:54:38 <uvdsl> q+
14:54:39 <bendm> ... another one is about the referent of your DID document: it would be a big deal if a service provider could add their public key to your verification methods
14:54:49 <TallTed> "This is my descriptor document, which I have signed with my private key, and which contains my public key.."
14:54:54 <acoburn> ack next
14:55:10 <bendm> uvdsl: what are the mechanisms that you need in the server?
14:55:11 <dmitriz> q+
14:55:21 <bendm> ... compared to what the application would need to do
14:55:47 <bendm> ... i.e. if the storage server has no access to my private key, isn't it solved?
14:56:10 <acoburn> ack next
14:56:27 <bendm> dmitriz: just want to add: yes, some of this can be handled on http requet level, some on data model and application level
14:56:35 <bendm> ... there's a bit that LWS must handle
14:57:15 <bendm> ... eg if I'm reading and writing JSON document, I can use JWS to sign, we have the digest header to make sure that the http request is handled correctly
14:57:22 <bendm> ... what we need on LWS level:
14:57:34 <bendm> ... non-text, non-structured data documents
14:57:44 <bendm> ... e.g. JPG
14:58:05 <bendm> ... these not have native support for provenance or don't have digest spec
14:58:07 <bengo> I'd also answer: we need some assurances from the LWS spec/server that the server SHOULD or MUST actually persist and then offer reads for the Digest, not just throw it away or tamper with it after the application/client writes it.
14:58:13 <bendm> ... eg via a link to an auxiliary resource
14:58:21 <kaefer3000> q+ to ask (AOB) if there was follow up on the f2f scheduling, which was part of last week's discussion
14:58:48 <bendm> acoburn: concerning the F2F scheduling: there's no news yet
14:59:07 <dmitriz> @bengo: +1, yeah
14:59:07 <gb> https://github.com/bengo -> @bengo
14:59:11 <bendm> ... adjourning, have a good week!
14:59:34 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/28-lws-minutes.html TallTed
14:59:40 <bengo> gb haha ya https://bengo.is/ https://mastodon.social/@bengo
14:59:40 <dmitriz> @gb - I think that's the wrong bengo
14:59:40 <gb> https://github.com/gb -> @gb
15:00:04 <acoburn> RRSAgent, make minutes
15:00:06 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/28-lws-minutes.html acoburn
15:00:29 <acoburn> s/thanks, TallTed//
15:00:37 <acoburn> RRSAgent, make minutes
15:00:39 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/28-lws-minutes.html acoburn
15:01:30 <acoburn> present+ dmitriz
15:01:42 <acoburn> present+ gibsonf
15:01:55 <acoburn> RRSAgent, make minutes
15:01:57 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/28-lws-minutes.html acoburn
15:02:29 <acoburn> s/jesswr/jeswr/
15:02:45 <acoburn> s/jesswr/jeswr/
15:02:50 <acoburn> RRSAgent, make minutes
15:02:52 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/28-lws-minutes.html acoburn
15:04:29 <acoburn> acoburn has left #lws
23:10:50 <dmitriz> dmitriz has joined #lws