# W3C Solid Community Group: Weekly

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

## Present
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* Aaron Coburn (Inrupt)
* Wouter Termont
* Laurens Debackere (Flemish Government)
* [Rahul Gupta](https://cxres.pages.dev/profile#i)
* Oz Olivo (Inrupt)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* Hadrian (Inrupt)
* Henry Story
---

## 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
* Wouter

### Introductions
* name: text

---

## Topics

### W3C TPAC
URL: https://www.w3.org/2023/09/TPAC/

* [Solid CG meeting](https://www.w3.org/events/meetings/3d93d256-f017-48c6-a509-9bd089a714e3/) on 2023-09-11, 5PM CET
* [Breakout sessions proposals](https://github.com/w3c/tpac2023-breakouts/)
* VB: Anyone can propose ideas for breakout sessions.
* VB: Anyone attending?
* LDB: In person.
* VB: Online
* WT: In person.

### Special Topic Meetings
URL: https://github.com/solid/specification/discussions/555
* VB: We have a few planned.
* VB: Next one is 2023-09-06: Alternatives to HATEOAS?
* eP: Can we have one on restructuring the repo's? Given the new structure of the meetings, and the upcoming WG, revising the panels would be good.
* eP: Can we do one next week?
* WT: I can join.
* VB: I can join too. I'll ping Sarven after the meeting.

ACTION: VB pings Sarven

### Solid Ecosystem Monitor
URL: https://virginiabalseiro.github.io/solid-ecosystem-monitor/
* VB: Something Sarven and I started, based on data gathering of GC meetings, script that gathers meeting data from minutes. Feedback is welcome.
* VB: One suggestion by eP was to put the processed data somewhere (in a pod) for others to also use. Putting it on a pod would require a solid pod that can use client credentials (CSS).
* eP: It's really amazing. I want to ask about the name: is there at sone point the aim of focussing on the broader ecosystem (e.g. providers).
* VB: We indeed want to have insights on many different things, even if that sounds really ambitious. The idea is to have al kinds of data and all kinds of (mini)apps for different things.
* eP: Important to see how much is under CG and how much under Project. But we can have that discussion later.
* eP: We can maybe check in DNS registration of providers (to see guarantee/stability towards the future). We could also monitor downtime etc. I like the ambitious approach.
* VB: That's really cool.
* VB: Regarding the CG/Project division: I think it is a CG initiative, but we should move the repo from my personal GitHub account. Can do that next week during Special Topic Meeting.

### WIP Implementation Feedback
* SC: Please share any implementation feedback or interest to implement. Links to products/projects and demos welcome.
* VB: Anyone with feedback/demo's?
* eP: For the [notifications client](https://github.com/o-development/solid-notification-client) in TypeScript, we are about to release? It's very basic but we have WebSockets and WebHooks, and over the next few weeks I want to work up towards a version 1.0 by the end of the year.
* eP: We currently do not have a fallbacks (you use either one), we can look into that when we have support for ....
* eP: It's a collaboration between me, Jackson and Wout. Currently we focus on a more generalised approach for different channel types.

#### Braid
URL: https://github.com/braid-org/braid-spec
* VB: We had this as a subtopic, but Michael (who was supposed to give a demo) is not here, so we skip it to next week. Rahul, can you ping him?
* RG: Yes, I'll do that.

ACTION: Rahul ping Michael.

### Chat Client-Client spec new work item
URL: https://github.com/solid/specification/issues/553

* SC: Let's scope this discussion to moving this work forward.
* SC: If a longer discussion is needed before accepting it as a work item, we can have a Special Topic Meeting.
* VB: What we want to do today is discuss whether we want to take this on as a work item or if we need to provide a special meeting to discuss ffurther. Any objections to having it as a work item?
* WT: When we talked about it last time I was the only one who objected. It seems that it's a go and we can start working on it. Sarven asked for a bit of clarification that it's the spec under solid/chat, but I think that's the case. Sarven aslo asked Tim to clarify the change in license. Tim changed from W3C like all our other specs to Solid Project, so some clarity is needed.
* eP: I just want to address concers of Wouter, as I have done in the issue. We suggested that two people push/bear the effort, and I think Tim and Hadrian would be those.
* HZ: I did offer but Tim has not replied yet.
* eP: I think we should accept, and as we work on it we should decide what are the expectations. For exampple Jackson and someone else are working on implementations. Do we simply work on that, or also look at other domains, and then try to generalise things, and agree that we can end up with something quite different than where we started. If we don't reach consensus, we can always have rival propositions, but we should not get to attached to our proposals.
* HZZ: We should indeed start by defining our scope, that is something to be clarified, but I'm not sure yet if I can interpret Tim correctly.
* eP: What I am saying is that we should pick a few other domains, and work on that at the same time, so that we can see generalisations, instead of working on them sequentially.
* H: I agree with that too.
* VB: To summarize: there are no objections to taking this on, but we want to have a separate meeting for broader allignment.
* WT: Can we also add that to the list of special meetings?

ACTION: VB to add topic of client-client specs alignment to special meetings

### Solid WG Charter
URL: https://github.com/solid/solid-wg-charter/

* SC: PRs are assigned to PAC (for merging). SC can merge if PAC is PR author (but no big deal).
* VB: All three approved by many people, just double checking that PAC can indeed merge those.

#### Clarify process for proposal adoption.
URL: https://github.com/solid/solid-wg-charter/pull/48

* SC: PR open under a week. 8 approvals.
* SC: Any objections to merge?
* VB: No objections.

ACTION: PAC to merge.

#### Add (again) 'new' in the out-of-scope section
URL: https://github.com/solid/solid-wg-charter/pull/49

* SC: PR open under a week. 5 approvals.
* SC: Any objections to merge?
* VB: No objections.

ACTION: PAC to merge.

#### Remove reference to Director
URL: https://github.com/solid/solid-wg-charter/pull/50

* SC: PR open under a week. 4 approvals.
* SC: Any objections to merge?
* VB: No objections.

ACTION: PAC to merge.

### Solid CG Charter
URL: https://github.com/solid/process/pull/323

* SC: Effective 2023-09-01.
* VB: We decided that date, but there is one topic that is still open (licensing).
* VB: Aside from licensing, any comments?
* eP: I just wanted to share a link to the repo for CG charters. Some of the things we have been discussing are not Solid specific, so if we have anything to discuss, we could also do that there in a broader context (e.g. boilerplate that is helpful for other CGs as well).
* https://github.com/w3c/cg-charter/

### MIT License and/or W3C CLA and FSA
URL: https://github.com/solid/process/issues/327

* SC: Still interested in feedback from RW to iron out a few things for us.
* VB: I think that we have reached a solution that was pretty good. But I know Sarven wanted to hear back from W3C legal. So the question is: do we want to wait on Rigo or reach out to anyone else?
* RG: In my memory Rigo has said he is back by the end of August, so we could maybe wait for a couple of weeks.
* eP: Remind to what PAC said once: if at once we want to revisit the charter, the rules are not so strict as for WGs. So if in a month we can also just update the charter.
* WT: I agree. I proposed to Sarven that we can indeed merge the charter as agreed upon and and the rules to make an ammendment wait feedback on licensing and ammend if needed. At least we'll have a charter that's in effect and we can always update.
* VB: I think I agree to move ahead and revisit licensing if needed after talking to Rigo. I am not sure what's the best course of action.
* eP: I think if we finalise except the licensing part, I think we can easily move to broader Solid projects that are not part of the CG. Once we have this one clarified, we can also focus on the other parts.https://github.com/solid/process/issues/325
* VB: There seems to be general agreement on merging and revisiting. We can also wait on Sarven to be around.
* WT: We can note the general agreement here and comunicate to Sarven and then probably merge it. If he has a very strong opinion we can come back to it next week, with the issue that the effective date will be passed.
* VB: Okay, let's sort it out async, and if not move the date.

ACTION: WT mention this in PR

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

* SC: Is there any sense or preference to update all specs at the same time or have them go through as soon as possible?
* WT: We already metnioned last week. It's about updating all specs with mentions to HTTP with references to latest ones. We asked for people to review PRs. We got some approval. Main issue Sarven still wantd to raise was it would be good to have more implementors look at the protocol PR. Question is, do we already merge the PRs for other specs with new references or do we wait for those PRs until Protocol is ready to merge? Notifications protocol refers to a different version as the Solid protocol becauise the other updates specs do not use the reference on the normative section.
* RG: Do you want to do this is steps? First do a word substitution, then do the corrections in a separate PR, or do it all together?
* WT: Currently in the PR it is all together: updated references and changed the sentences that were ambiguous because of it / slight change in meaning. The result of the PR will never be inconsistent.
* eP: I understand it might be useful to have separate commits, but why separate PR?
* RG: There was a comment from Sarven about an issue I opened.
* eP: I think WT addressed this.
* WT: No. My/general conclusion was we would keep that as a separate issue because it is not linked or inspired by the change in references as such. More of a separate thing we came across while doing that. Rahul, we can tackle that in a PR immediately after merging this one.
* RG: Fine with me. Just wanted clarification.

#### Feat: update HTTP refs in protocol
URL: https://github.com/solid/specification/pull/561

* SC: Seems okay to merge (with potential minor tweaks) but I'd suggest to gather more feedback.
* VB: This is what needs more reviews. We'll leave it open for a little longer.

### 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-
* WT: We touched upon this already. Because of an issue with product classes on protocol I looked at specs and compared different definitions used in different specs, put them togehte ri na discussion on the specification repo. Question is, if definitions/terms are used throughout multiple specs, it'd be best to have a single definition in the Protocol and the discussion is there to set a single definition of those terms. Please go and give feedback.
* eP: Thanks WT for all the great work. Great overview of all the specs in one place. I posted a little diagram that shows current dependencies between specs. While we thing about defintiions we need to talk about dependencies. We probably don't want to have circular dependencies. We should think about dependency graph. Coming back to special topic meetings. I am available to have another special meeting on this.
* WT: Good point. Both proposal to meet for a special topic meeting, and my poitn was not to put all definitions in the protocol,m but have one place where each term isdefined and not having them be defined in multiple places. If a resource server has a definition in a spec and authorization server has one in another spec. I agree with insights from dependency diagram.
* AC: What WT/eP describes about dependencies is important. Specs are being incubated. If things are experimental we want to have a path to define a name but not pollute a formal definition. If we have a more informal vocabulary describing things that are not fully mature, we can then have a process for them to transition into something more formal.
* eP: +1
* WT: Agree. Informal document for conventions/things we assume to vaguely mean something not formally defined could be helpful. I could continue that once we discuss further in a meeting.
* VB: Pavlik, do we want a special topic on dependencies AND this topic, or separate ones?
* eP: We should discuss together.
* VB: So we create one after the meeting of next week, which would be 2023-09-12.

ACTION: VB to propose in schedule.

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

* WT: Issue created to address concerns with chat spec proposal. People can read as my reasons to object. Conclusion of discussion was that we kind of agreed on doin those in parallel and eP said to start multiple concrete specs to see some generalizations.
* VB: We can reuse for special topic in client-client specs.

### [AuthN & AuthZ] Server side clients (apps) - Solid OIDC
URL: https://github.com/solid/specification/issues/504#issuecomment-1687212176
* eP: The issue overlaps a bit with #517. I don't know if we should do another special meeting on this.
* eP: *explains history of issue*
* eP: Main point: while clients can easily authenticate itself, we need to make sure it is authorized by the user. (End-user to app delegation.) It is not clear how to separate that, and which parts are authentication and which authorization.
* HS: I put a little example forward with a bank. I will put forward a way you can do that with WAC/HTTPSig/Says-Logic, that can model how agents can speak for other agents.
* VB: We are out of time, so needs a special topic meeting.
* eP: Yes, I will be available, just a question of prioritization. Just want to say the case Henry is putting forward is a special/distinct one, not the general group I want to address.
* HS: Can you work that into my banking case?
* eP: We can discuss that. ... I'll answer in the issue.

ACTION: VB to find time for a special topic meeting

### Solid Demos