solid · uvdsl · Sep 2, 2026
diff --git a/meetings/2026-09-02.md b/meetings/2026-09-02.md
@@ -0,0 +1,162 @@
+# W3C Solid Community Group: Weekly
+
+* Date: 2026-09-02T14:00:00Z
+* Call: https://meet.jit.si/solid-cg
+* Repository: https://github.com/solid/specification
+
+## Chair
+
+* Christoph Braun - [uvdsl](https://github.com/uvdsl)
+
+## Present
+
+* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
+* Christoph Braun - [uvdsl](https://github.com/uvdsl)
+* Alain Bourgeois
+* TimBL
+* Roberto S.K. Breitman
+* [Matthias Evering](https://solidweb.me/testpro/)
+* [Jesse Wright](https://jeswr.org/#me)
+* [Erich Bremer](https://ebremer.com)
+* <a href="https://csarven.ca/#i" rel="schema:attendee">Sarven Capadisli</a> (joined 14:20Z)
+
+
+### Regrets
+
+* 
+
+## Scribe
+
+* Christoph Braun - [uvdsl](https://github.com/uvdsl)
+
+---
+
+### Meeting Guidelines
+
+* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
+* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
+* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
+* Join queue to talk.
+* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.
+
+### Participation and Code of Conduct
+* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
+* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Conduct](https://www.w3.org/policies/code-of-conduct/)
+* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
+* If this is your first time, welcome! Please introduce yourself.
+
+---
+
+## Introductions
+
+
+
+## Announcements
+
+### OS Tools meeting - today!
+https://www.w3.org/groups/cg/solid/calendar/
+
+Topic - SPARQL: https://lists.w3.org/Archives/Public/public-solid/2026Aug/0007.html
+
+
+## dokieli open hours (doh!)
+
+URL: https://dokie.li/events#dokieli-open-hours
+
+* SC: This is a public meeting for anyone using or contributing to dokieli or curious about how an authoring/annotation/notification system comes together. Ask questions, report what is not working, walk through an authoring or annotation workflow, or ***discuss the underlying standards***. No agenda is required and no registration is needed.
+
+## Actions Review 
+
+* eP to follow up on TPAC meeting with Social CG/WG - to follow up after this meeting
+* JW to follow up on TPAC meeting on Identity - to post under the GitHub issue to tag the interested groups - topics: CIDs and FedCM
+
+## Topics
+
+### Demos
+
+#### SAI organization admins feature
+
+* eP: I should have it ready for 5 min demo by then
+* ... the idea is to explore how enterprises can have admin roles.
+* ... *Showcasing a user who acts as an admin for an organisation.*
+* ... *Showcasing an invitation of an agent to join an organisation.*
+* ... *Showcasing accepting the invitation which can be seen by the admin.*
+* ... *Showing a 35 step sequence diagram.*
+* ... this is not trivial.
+* ... *goes through the diagram step by step.*
+* CB: Do you have a link to the diagram?
+* eP: Not yet. will publish.
+* ... main point is that there are three security domains.
+* ... it is a mix of public protocol and implementation detail.
+
+### Add creator definition and requirements to record and protect creator
+
+URL: https://github.com/solid/specification/pull/807
+
+* CB: #807 targets the editors draft of the Solid Protocol and proposes to add creator definition and requirements to record and protect creator.
+* ... The PR was opened on Jul 19 (more than 10 days and two meetings ago) and has received feedback which was addressed exhaustively.
+* ... Merging if no objections.
+* eP: objecting! so far 0 interest or feedback from server implementers and very limited feedback in general - 1 approval and 1 change request
+* ...: relevant discussion in LWS WG https://github.com/w3c/lws-protocol/issues/238
+* SC: Yeah, so, no, that's not how things work in a CG. There is a clear misunderstanding on how to be constructive in a CG.
+  1. There is plenty of interest in the community as the PR is tied to prior issues and discussion spanning over several years. That's a significant data point for incubation.
+  2. If other Groups are looking into the general concept based on prior work/interest/incubation from the Solid CG towards implementation, that alone is sufficient.
+  3. LWS WG discussion is irrelevant to this PR. The only commonality is the general notion of creator being uttered and one can virtually connect it to anything else on the web re "creator". It has no useful input.
+  4. The so called "change request" undermines all the feedback given, and it doesn't appear to be done in good faith considering all the tangents that the PR discussion already carried forward. The mere preference of one person on how it should be designed does not serve as a blocker. It is a different design. They can go and build that design and implement. Moreover, the objector has not commited to implement neither a server or a client that would use their preferred solution. So, it has no grounds on how it should be designed. Certainly not above the one presented in the PR, even if they met the bar they are trying to assign to others but instead of themselves.
+  5. As the author of the PR, and editor/author of the Solid Protocol, I have ensured that the proposed design is internally consistent with the rest of the Solid Protocol. The alternative solutions are not aligned with the rest of the specification as it stands.
+  6. There is already one client implementation, and that is significant input. If anything, that is a stronger signal that there is *actual* use and willingness to use, for a use case that is being addressed as opposed to judging the fitness by server implementors alone or committing to implement the design, but no actual use / consumer of it.
+  7. There is no requirement or a blocker that an implementation needs to exist to update an ED or even necessarily a release for a TR / CG-DRAFT/FINAL. So, citation needed if that's being used as an actual grounded argument. In other words, just because eP is objecting, it doesn't mean that the PR is blocked. There is this whole notion of working towards... "consensus"... that actually needs to unfold, and clearly that needs support from the other chairs to move things forward.
+  8. I request that eP should read https://www.w3.org/policies/code-of-conduct/#disruption . I'd also like to request that another chair (besides eP) processes this PR in a constructive manner.
+* CB: Dear elf Pavlik,
+  I see that your objection is based on two parts:
+  (1) that there was no feedback from server implementers
+  (2) that there was limited feedback in general, with 1 approval 1 one change requst.
+* ... On (1), this is wrong. Melvin, Jesse, and myself are all Server implementers. I provided substantial feedback to the PR to help address feedback from the others.
+* ... On (2), the PR has seen 69 comments from 7 commenters (Sharon, Melvin, Jesse, myself, Ted and yourself) so far, which is far from being limited feedback. You provided many questions and comments yourself. I explained patiently that the grounds for your change request and blocking of the PR are  not based on a technical issue with the PR at hand.
+* ... As such, the objection is not substantial and does not block merging the PR into the ED.
+* eP: I do not question that there is interest in solving this issue / functionality.
+* ... what I question is the interest in the proposed solution
+* ... 2, yes there is feedback from server implementers but no approval
+* ... 3, on the request of chairs processing the PR, Christoph and myself are quite heavy involved, so Theo would be the one process it.
+* ... 4, main question is how we manage Solid Protocol. Do we change and break things. If we do that, fine. My problem is that we try to signal stability.
+* ... 5, on the server implementers, there is a bigger impact on clients, you can have it implemented in CSS in like a day, and that is why we should rely on feedback from client implementers.
+* ... To me, it feels rushed to merge it into core.
+* CB: Ack your comments here. My main problem that I see us dancing around is your point on 4) , namely how we go about working on the Solid Protocol. That is something that informs the rest of the points, e.g., 5) what we merge into "core", there is no "core", there is the ED and there is the TR (CG-DRAFT). No notion of stability on the ED other than what's just there. Everything that is in the ED can or is up for discussion and can be changed afterwards, so your suggestion to say well lets put it in there and see how people respond / implement and feedback on it in there, namely put it in writing and so then people see this works that way or not, and change or remove the feature. That is how the ED has been operating in the past. So, that was my understanding of how we work on the Solid Protocol. Therefore, I'm repeatedly express my confusion on whateer the blocker is or the procedure for it.
+* SC: I think CB covered most of what I want to say. We have the Editor's Draft because of historical reasons, not because W3C requires a CG to have an ED. It comes down to CG DARFT and CG-FINAL. Even a WG can choose to redefine everything, as LWS does, there is no gravitas on what we define. There is no rocket-science about this feature. Even PUTing is still within the Protocol and the Server can decide to process it or to reject it. That notion has been part of Solid since the very beginning from LDP containment. It is not a new topic. It is the same now for the description resource. It is the simplest change, it provides something that people want it. You mention Jesse, he can speak for himself. I read his comment as saying that this is valuable content. Either his comment is to be classified as not useful or he seems to find it useful.
+* JW: I have not reviewed in-depth. I neither approve or reject to this PR.
+* eP: Again, there is no contest in that there is no desire to have that functionality.
+* ... CB can you clarify whether there are two levels of hurdles re ED and CG draft
+* CB: {will add later} ED in a sense has the lowest bar. {some historical stuff} Once there is a "release" for a TR / CG-DRAFT, that release is to be reviewed so everyone is on the same page. Nothing prevents us from merging the PR now. And if in 1h an implementer finds an issue can open a PR to change things.
+* SC: We can even drop the ED. CG can publish unlimited CG DRAFT updates.
+* ... historically, we kept the ED very close to the CG DRAFT. We collected the changes, and at some point we would publish a new version of the CG DRAFT. I dont want to discuss process and guidelines in the middle of the PR, I always point to the contributing guidelines - if you have a problem there, open an issue about it - this PR is content, in my opinion that solution is good as is. It is completely fine as is. I am fine with dropping ED. It is just a document that we hack around with.
+* ... I am completely open to directly working on the CG DRAFT. In fact, some specs in the CG dont have a ED? I think? I believe the QA is only a CG DRAFT. All the PRs get directly go in there.
+* ... I dont want to discuss this again, for ACP we had half of an implementation before we merged into the spec.
+* ... Are we applying varying standards here?
+* ... That PR is going into so many directions to stall. I prefer if people look at if the feature is benecial and there is a solution proposed, that is fine.
+* ... If there is no alternative, I dont even want to entertain the hypthetical alternative solution in the PR of a concrete solution.
+* eP: In my review, I set the bar that it will be automatically be going into the CG DRAFT.
+* ... If in two years there is a different way to solving that problem, can we get committment from everyone to have breaking changes.
+* ... if we merge it now, wont that be a breaking change in the future and then be harder to update.
+* SC: I think you have to lower the bar waaay down in the CG. Most of what we do is just experimentation. N3 patch for example. Just by definition, working on the CG DRAFT, there are changes. Get enough changes, and publish.
+* ... WG can grab whatever they want or not and work with it.
+* ... I am PRing the ED out of common practice. 
+*  [scribe lost the plot on process discussion]
+* ... Any new feature includes a breaking change (in the sense of conformance).
+* eP: Again, SC is not very often at the meeting, I would like a written commitments on the record that if in half a year that if it is a breaking change then we can evaluate without the issue of adaption cost.
+* SC: Is there confusion what a CG DRAFT is? Of course you can make these changes. This is nothing that needs discussion.
+* CB: As participants requested a chair to process the PR, I officially nominate Theo to review PR#807.
+
+
+## Add Public Keys section
+
+URL: https://github.com/solid/webid-profile/pull/130
+
+
+
+## Actions 
+
+Theo to review PR#807.
+
+
+## Decisions
+