# W3C Solid Community Group: Weekly

* Date: 2025-04-02T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://matrix.to/#/#solid_specification:gitter.im
* Repository: https://github.com/solid/specification

## Present
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* Alain Bourgeois
* [Rahul Gupta](https://cxres.pages.dev/profile#i)
* [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) (OpenLinkSw.com)
* [Erich Bremer](https://ebremer.com/profile#me)
* Hadrian Zbarcea (late)
* [Sarven Capadisli](https://csarven.ca/#i) (joined 15:37 UTC)
* Rui Zhao (late)
* Jesse Wright

---

## 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/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.

### Scribes
* Erich Bremer

### Introductions
* [name]

---

## Topics

### Changing CG meeting timeslot

* eP: I saw Jesse asking on matrix if we could have it back-to-back with LWS calls which are Mondays 10AM-11AM ET
* TT: Preceding LWS (so 9AM-10AM ET) would be painful but doable. Following LWS (so 11AM-Noon ET) would conflict with VC-EDU.
* JW: doesn't want to cause chaos
* eP: this would mean that SolidCG would also follow daylight saving changes, similar to LWS
* JW: More people will joint today, we can ask them as well.

### CSS components library

* Alain: There is some momentum around components for CSS (FedCM, google auth, proxy, webFinger, ...).
* ... The currently available lists (forum, solidproject.org, catalog) could be used but they are in my opinion difficult to follow. Github repo are quite easy to follow with email notifications: just need to follow the repo to be notified of changes.
- What about an "awesome-solid" list in github?
- and/or a solid-contrib/css-components (one folder per component
* Alain: we dont have location to put them. We're working on email confirmation and things like that. I find it very difficult to receive info when things are changing. We are not easily able to be notified of any new things coming in.
* JW: I think it is a great idea to have them in a findable place. I would consider to them to put it under the core css name space.
* Alain: I would agree with that. I would first offer them to css if css takes them we transfer the component to css.
* eP: I think we would want to open a discussion on css and coordinate with them before committing to any changes.
* JW: I think it would be appreciated if you (ep) handle the action item for this.
* Alain: we have more components coming in and that we are beginning to work on
* eP: can we make up a list and drop them into the discussion. We can use matrix chat.
* Alain: we dont have any email notification for anything on solid unless it is on github.

ACTION: eP: gather links to extensions from matrix and create discussion in CSS repository

* Alain: Awesome solid list
* JW: ... The easy way would be...
* RG: I think this is redundant to Jeff's catalog unless there is a search for awesome keyword.
* ...: I think this should be taken over by the ODI, the entries that are submitted by people.
* JW: I do see the challenge that Alain is raising, it is hard to see changes and be notified. I see value in a script that creates a markown presentation. I also agree that we shouldn't have redundant copies. We could move the catalog to solid namespace.
* eP: The repo for the data it should already be in solid namespace.
* Alain: The initial issue was notifications by email. With the awesome name I don't have idea but I see many people using that name. People may look for it and that would add visibility.
* eP:
* Alain: It is more compliated to update that list than update the list on github
* eP: we want to have a single source of truth...we need to have these things in sync
* JW: issue template is a good idea. Awesome lists have a strict structure....possible to parse the markdown into RDF...possible to have the tooling..make changes..depending on the change could sync to each other.
* RG: loss of info going from one to another only work in markdown to rdf
* eP: maybe we can create a few issues...then everyone can propose on how they are addressing theose requirements. I dont expect to resolve this issue today. https://github.com/solid/catalog/
* RG: ...maybe 2-3 days of work for a developer...
* JW: serveral applications to generate forms from SHACL
* eP: would someone like to take an action to experiment with this?
* Alain: alot of things proposed involve involvement but who will do it? Its a problem of resource, that's all.
* eP: I agree with you. How about we take a structured approach and open a few issues...maybe propose your solution of a light-weight awesome list...
* Alain: can we had this as a discussion item 2-3 three weeks from now?

ACTION: eP to add it to agenda in two weeks

### solid pod email/whatsapp notification
* Alain: Could we be more open to the outside world by adding a solid pod email or whatsapp notification? I don't know if this should be be a specification or a server recommendation.
* Alain: we want to eat our own food...the one we may have may actually work but I don't see anyone using it...every week we post the new minutes letting people know there is a new meeting report there
* eP: notifications not implemented on the subscriber side...generally useful to bridge solid notifications to existing used methods..
* Alain: do you think we need some specification...first we can inquire what has already be done by ???
* eP: ...we can have a subscriber that uses web hook channel...
* Alain: do you know anyone who has implemented such an app
* eP: Michiel?
* Alain: if we want to eat our own dogfood we need return from our server and find ways to do that other wise we are locked inside ourselves. We have to change momentum
* eP: I would see whatsapp as secondary...other automation services that could take the email and forward to other services.
* Alain: what could be the way forward? Find out what Michiel has done.

ACTION: Alain to reach out to Michiel

### PR 711
see https://github.com/solid/specification/pull/711#issuecomment-2772257350

* MdJ: tiny issue...stirred unrest in the community...take a break..have a discussion how we can make peaceful progress...if we have this much discussion on such a small issue we will never build anything
* JW: The issue got messy indeed. The WG was happy for CG to continue with this kind of changes. There was a lot of siloed discussions around that issue. Moving forward we should have more, ideally all of those discussions in open. The particular conversation I recall in relation to pausing, was a concern that some implementers would not be on board with adoption the change. We want to have support from those implementers before rushing the merge. I also spoke with Ruben, to clarify all his comments in the PR, so I can formulate clarifications as requested. Based on request of all of those groups, and request not to create implementation burden on parsers. I created proposal where there is a response from CSS that they are willing to implement.
* JW: What are we doing with a current PR?
* JW: How do we avoid thish chaos of discussions in future PRs?
* MdJ: If we merge this PR and say that 'it was a rough ride but we got there in the end', we may create image that this is how the Solid Project works. I don't want to create that image or work this way.
* JW: Scope clarification first. We say Solid Project here, there are different groups and authorities in play. This is CG topic and question how CG wants to behave and proceed. ODI doesn't want to claim authority over CG drafts. I'm contributing to the specs as an open source contributor.
* HZ: You and others said that we should keep conversations more public. In my experience it doesn't always work. The decisiosn have to be made in public and in transparent way. Sometimes understanding of what's going on is better in private. I often reach out directly when I have an issue. Ruben said in the comment that CSS is open to implement the changes. However I think the Ruben understands the problem better than most. Other implementers may not know what they are getting into. I would prefer to talk about it more.
* SC: A lot of things here. This is W3C CG which has expectations to how it works. Unless there are IPR or conduct issues everthing is on public record. Some people may not be in the group and we may reach out and gather that input. In the PR we have taken that feedback. I haven't heard from anyone else that will not implement based on technical reasons. Until there is official transfer of N3 Patch to elsehwere, this is still incubated in this CG. We may get things wrong, a lot of things can be improved. We can only continue working on it untill it's best represented.
* SC: Looking at PR all feedback seems to be addressed. Unless there is new feedback it looks in good state to be merged. If there is something specific outstanding on this PR we need to put it on record. We can't operate based on private conversations. There was prior decision in CG that we are not going to work on the protocol draft any more. LWS by the charter were ready to take what the CG was publishing, ED or latest published version. We went throught that, we fixed it, we can move on with business as usual.
* RG: Few comments. First I think there is almost an attemtp to srive for perfect consensus. I guess a lot of back and forth can be avoided if we don't try to make everyone happy. I miss having permanent STM slot. Otherwise we end up with permathreads going for months. We need a space to discuss those technical topics. We had a consensus that we don't need to solve it permanantly but only solve it where problems of SolidOS can be adressed for now. Later we can work on making it more acceptable for the community. Trying to solve it all in one leap can lead to this paralisis.
* AB: I find position of Sarven interesting. We have PR which was laregly discussed, it is difficult to understand that PR that has no more objections can't be merged. Specification is not perfect, we will continue.
* eP: ...
* SC: In my [last review](https://github.com/solid/specification/pull/711#pullrequestreview-2735459686) approving, I laid it out. If you want to give courtesy to the group we can do 2 weeks etc. If we want to go 10 from today we can do that. When that point comes we can just merge it. We haven't been hurring with merging it. Let me know the decision and I can merge it, with some additional changes (like the changelog).
* JW: We give it a 10 days, next CG meeting is still available for conversations. If no objections or technical changes are raised.
* eP: ...
* SC: It is complex. The point of CG is to be the melting point for those technical/ethical conversations. If there are things that should be looked for they should be carried out here. I don't agree with Hardrian's earlier comment, decision processes or communication in non-W3C groups or other open source communities is 100% irrelevant here. We operate under the W3C framework. If ODI is govering the project and assists groups/parties in a ways that information can make it's way to CG, that's great. We can only make sound technical decisions based on open input. We can't operate random decisions bases on argument between specific implementers. If there is technical information they can provide it to CG.
* JW: I want to clarify ODI's role and the docs also clarify it. OID doesn't want to claim authority over any of CG work. We want to help support community, raise funds, support open-source work. Work on github/solid except the CG drafts. Give visibility to Solid, support use cases like what Practicioners are working on. We want to be able to provide support to bridge communications. ODI is not coming to control the entire Solid Project. We should understood what authority ODI actually has, it doesn't control or own specifications.