# W3C Solid Community Group: Weekly

* Date: 2023-08-23T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* Aaron Coburn
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* [Rahul Gupta](https://cxres.pages.dev/profile#i)
* April Daly
* Michael Toomim
* [Wouter Termont](https://github.com/woutermont)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* Oz

---

## Announcements

### Meeting Guidelines
* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
* [W3C Solid Community Group Meeting Guidelines](https://github.com/solid/specification/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 Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* 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.

### Scribes
* Virginia

### Introductions
* MT: Computer scientist working on the [Braid project](https://braid.org/). Talked to Rahul and TimBL. Will listen in for a while.

---

## Topics

### Special Topic Meetings
URL: https://github.com/solid/specification/discussions/555
* SC: Added one entry for #525 end of September.
* SC: There's a week that TPAC is happening.

### WIP Implementation Feedback
* SC: Please share any implementation feedback or interest to implement. Links to products/projects and demos welcome.
* RG: Interaction with Braid Project when proposing PREP at IETF. Invited Michael to see if there's interest in implementing state synchronization for Solid.
* RG: Braid Project: <braid.org>
* RG: Braid Specification: <https://github.com/braid-org/braid-spec>
* EP: Here's the link to my SAI + Webhook + Web Socket demo from yesterday: URL https://youtu.be/CvTunOWu7mM?si=-kATZzEyHjlpkJyj
* SC: We have some notes from demo session. Will find a way to share. We has presentations and also discussion on how it's best to store/share recordings.

### Reflect WG independence in charter
URL: https://github.com/solid/solid-wg-charter/pull/47

* eP: I think we should clarify the situation, since it seems unresolved.
* eP: Last week there was a PR from Barath, approved by Aaron and Justin, and later it was merged very quickly. Sarven commented and reverted it later on. I'd like us to clarify the situation and whether the problem was with the proposal or the process. It's not common that we make a PR, merge and revert.
* SC: If how we have been doing things or there's lack of clarity on any process then I am all for clarifying, so we all have the same understanding. There's a thread with some responses. If there's new information, the discussion can continue there. If there's a dispute on what's been said, we can cover there. Anything besides that we can provide guidance on how people can participate better. I don't have anything to add.
* eP: I understand the expected process is PR is open for longer with more time to discuss, bring up during weekly, have some sort of decision. Main problem was the process wasn't observed. Proposed, merged within days.. not enough time to properly discuss.
* SC: 28 minutes.
* eP: We can ask Barath to resubmit and be mindful of following the proper process.
* SC: Are you proposing that he resubmits?
* eP: If the person wants to propose a change that was rejected on process, then it's fair to ask them to make the proposal. We can inform everyone to follow the process.
* SC: Besides the procesx there were technical issues with the content of that PR. PR introduced errors and undoing something that was well-covered. There's a lack of understanding on prior discussions and work we've done to arrive at that point. It is based on existing understanding on how transitions happen, and liason between WG and existing CG works on the same topic. Removal ?? there's a problem there already. It should not stop anyone from resubmitting but the review will be the same. In addition to the fact that it is illegitimate to push and merge just because they have access.
* PAC: I agree that there was probably not enough time for CG to discuss, changes are debatable. However some concern has been expressed. My understanding is the current text makes it look like the WG would be subordinated to the CG which is not the intention of the text and not the way WG should work under W3C. The concern has been expressed, we can agree on a better way to adcress. We can tweak this so it makes it less like WG would be subordinated to CG.
* SC: Is there anything that implies that?
* PAC: My reading of the text was not that.
* WT: I think that if some people indeed have such a different interpretation of the text they could indeed bring it in a more constructive way than merging a PR within 20 minutes. and also the sentence was there is exactly the one proposed by W3C itself so i don't see how it'd lead to a different interpretation.
* AC: In a charter you want to be really clear and unambiguous because there will be a lot of different people from different contexts in and out of W3C looking at it. This is not common text. If you look at any other WG this is not part of the template, not part of any WG especially those with an associated CG. There are many ways to make the text better but we need to make sure that WG/CG are independent. The way the text reads is that the WG is subservient to the CG. That is not common and outside what I'd expect of any working group which is why I supported that change.
* WT: I did not say it was common. Just said it's part of a number of WG charters and it's a sentence proposed by W3C in their guides with the intention of providing WG with this incubation phase, and even says incubation phase could be different from a CG. I'm all for rephrasing to make clearer. I just didn't agree with the way it was done.
* SC: The sentence in question perhaps:
>The Working Group will not adopt new proposals until they have matured through the W3C Solid Community Group or another similar incubation phase.
* SC: There are a number of existing charters in place that do explicitly call out the relationship between CG and WG as well as W3C guidelines on the notion of incubation. It's not like WG can only adopt deliverables from their CG. Case in point we do have WebID spec as deliverable and that was not incubated in CG. CG is not even necessary but W3C is expecting some sort of incubation and CGs are good places for that. The existing text literally says that. The text does not lock itself to CG, says "similar incubation phase". I want to emphasize that acknowledgment/interpretation of that text mentioned in comments in the PR, there is a response given to that in the thread.
* SC: On a technical level, the proposed PR is removing that expectation on how a relationship should happen. The other issue is the process, 28 minutes to merging the PR, without the majority of CG even being aware, the chairs not approving, W3C staff not around.
* OO: I am reading the text. Does the WG decides something is mature enough or CG? I read it as WG is not allowed to take any new proposals until CG says it's okay.
* SC: Rest of W3C documentation does not give that hint. WGs decide themselves, proposals can come from anywhere. If we're working on a spec in CG and w decide it's mature, it can propose it and WG can decide. If not in CG, anyone working outside the CG can go through the same process and propose, and WG will decide.
* OO: That is clear but the text does not reflect.
* SC: There's a lot of process related information that is taken for granted. We can't spell out anything. Not saying every detail needs to be hidden. Current text does say WG makes the final call.
* PAC: I have no problem with the existing text (previous to the PR). If some people interpreted the wrong way maybe it's worth trying to fix. I agree with SC that a lot of knowledge is taken for granted but we should make it clearer if we can. It's up to W3C members to make the final call. WG decides to ask for recharters and AC approves. I don't think it's a good idea to remove the text completely as the PR did, but we could clarify.
* eP: I will post the link to these minutes on the PR thread and invite anyone with concerns to raise an issue.
* SC: Is there any dispute as to why that commit was reverted?
* OO: The process has changed a few times in the last few months. Might be worth writing down what the current one is. Barath made the first commit than we made extensive edits. CG started making edits around July. Barath did not know the process had changed.
* SC: Which ones?
* OO: As long as an editor approves it, you can merge.
* SC: That did not incorporate the CG in any way. There was no deliberation.
* OO: Can we write down the process?
* SC: There's contributing guide but I will have a look. Just because there's a lack of clarity in the process does not entail that due diligence should not be followed on top of how we've been updating the charter through months of work in the open.
* OO: All I am saying is more clarity can't hurt because looking at history there have been a lot of merges like that in May, June..
* WT: I would like to ask, we all agree clarity is good, but for now let's try to tackle another topic.

### Tracking specs changing to use RFC 911x
URL: https://github.com/solid/specification/issues/471#issuecomment-1685201553

* SC: Emphasis here is that we need to doublecheck any impact on conformance or interoperability.
* SC: Implementers and test suite devs should be aware.
* WT: Based on a few people who raised the obsolted HTTP specifications in our reports, I created a few PRs that make necessary changes to used the new ones. All but the Protocol are extremely straightforward. Only in the Solid Protocol there's a need for mroe reviews. Double check that I didn't miss anything that would affect the conformance.
* eP: https://httpwg.org/specs/rfc9110.html#rfc.section.B.3
> The terms "payload" and "payload body" have been replaced with "content", to better align with its usage elsewhere (e.g., in field names) and to avoid confusion with frame payloads in HTTP/2 and HTTP/3. (Section 6.4)
* WT: Good point, that's indeed one of the changes. I only checked the conformance requirements/sentences. I might have missed terminology related changes.
* eP: Great that you created all these PRs, it was long overdue.
* SC: Wonder if it actually changes anything in conformance or breaking anything. Besides spec level updating I want to make sure we have implementors and test suites be aware of what's being changed.
* RG: I've raised an issue at WT's request to make sure that after that a review is done: https://github.com/solid/specification/issues/562

### Interest in State Synchronization
* MT: Braid is related to the notifications spec you're working on. The problem you have is what happens when a resource in a solid pod changes, how do you notify all the clients with real time updates? The spec you have now, there's a stream of updates and when a new one comes clients can ask for the new state. Some limitations are lack of support for collaborative editing, ???
* MT: Braid is an attempt to add synchronization directly into ??? What is every URL on the web was natively capable of collaboratively edited, gives you live updates automatically. Every URL would have an offline mode so you can use without connection and will sync automatically, have peer-to-peer editing of resources. Braid would give you these features. Specification itself is broken up into different features you can use independently.
* eP: Is there something you could demo in another meeting?
* MT: Yes, I'd love to.
* SC: We have a short slot open on these calls on Wednesdays. We're trying to have dedicated meetings for demos, we had one yesterday.
* MT: I'll present next week.

### Align shared core terminology
URL: https://github.com/solid/specification/discussions/557

* SC: Follows action of https://github.com/solid/specification/blob/main/meetings/2023-08-16.md#rename-server-to-something-more-specific--resource-server-or-storage-server-or-

### General vs domain-specific interoperability
URL: https://github.com/solid/specification/discussions/554

### [AuthN & AuthZ] Server side clients (apps) - Solid OIDC
URL: https://github.com/solid/specification/issues/504#issuecomment-1687212176

### Solid Demos