# W3C Solid Community Group: Weekly

* Date: 2023-03-08T14: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)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* elf Pavlik
* April Daly
* michal/mrkvon
* [Matthias Evering](https://solidweb.me/testpro/)
* Tim Berners-Lee

---

## 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
* Michal: First time here. Interested in app development over Solid. Interested in Solid for the last two years or so. Looking into ??? with Solid. Want to make Solid work for application developers and interested in the social aspects of it. Possibility of having social network where don't need to buld from scratch. Potential of privacy and ??? building on top of each other. I don't tend to speak up much in groups, but will do if I feel it's important.

---

## Topics

### Implementation Feedback
* SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
* eP: Currently working on the flow and app redirects for sharing resources for dedicated authz agent. Many users will prefer that only their fully trusted authz agent to manage all access policies. Working on redirect flow between domain specific app and authz app. If someone is interested please contact me and I can share my progress. Would like to demo but not there yet.
* TBL: Because we moved to Matrix, I have been working on pouttingcode that will take Solid archive of Gitter to Matrix. Got that basically working. Needed to upgrade the UI to handle threads because Solid chat does not have and Matrix does. Currently working on likes, reactions, etc. Shapes we have for Solid chat have become a bit complicated to handle threads. Example: [solid/specification chat archive](https://timbl.com/timbl/Public/Archive/solid/specification/index.ttl#this). The UX needs a lot more work.
* SC: If you'd like to share a link that would be great. I noticed it is working faster.
* TBL: Maybe CSS is faster. If you leave a session for 24 hrs on CSS you need to refresh. That's an issue.
* ME: The people at https://pod-chat.com/ have published a tool on the forum. Checked it out and it's working well.

### Add TR/2022/notifications-protocol-20221231
URL: https://github.com/solid/specification/pull/491

* SC: Feedback? Questions? Objections?
* SC: This and the folowing topic: would be nice if we could merge. Releases have been requested for a while. Kjetil approved the PR for the protocol. We have some editorial suggestions which have been factored in.
* SC: We should look into Notifications protocol first, because if we merge it we can merge protocol later (as it rfers to ??? version of the notifications protocol).
* SC: Since these PRs have been open for 2 months, I will ask if there are any objections to merging them in in that order: notifications protocol, then Solid protocol.

PROPOSAL: Merge TR/2022/notifications-protocol-20221231 ?

* eP: +1 to merging. (PR has been open for over 2 months now)
* SC: +1
* SC: I take that as no objections.

ACTION: SC to verify there are no pending changes (should be editorial is any).

### Add TR/2022/protocol-20221231
URL: https://github.com/solid/specification/pull/492

* SC: Feedback? Questions? Objections?
* SC: Any objections?
* SC: this is version 0.10 of the Solid Protocol.
* PAC: Don't have any objections. Could you summarize the most significant changes?
* SC: There's a changelog: https://htmlpreview.github.io/?https://github.com/solid/specification/blob/dbefa0d6bf82baaf1bd5305c38845ac6bc491afa/protocol.html#change-log
* SC: since the release in 2021/20/17, there's new sections on constraints and problem details, updates to definitions, new requirements on storage description, advice on privacy principles, clarification on conformance, class of products for example, added requirement for ACPs, update on security and privacy self-questionnaire. Quite a bit of editorial changes. This is about a year's worth of updates. Long overdue.
* PAC: I see the term Pod has been removed, is that recent? I saw a question on the forum a week ago.
* SC: General use of the term hasn't been defined on any of the specs. It is used outside technical specs, but for specs it is not specific enough. Pod itself is not a simple enough unit.
* TBL: We have the word storage. We haven't used it because we don't want to say you can't use the word unless you're referring to ??? it is easy to keep using Pod in practical terms. In technical documentation you might say "save to pod, have one or more pods, etc".
* SC: It is still a term that is used but not on the specs.
* eP: For a long time I have been supporting using "storage" and leave "pod" as a more undefined marketing term. Often pod is a bundle of many features bundled together, but there is not a technical definition that is "pod". Varies depending on how people use the term. For server side components we have Storage (Resource Server), OIDC Provider, SAI Authorization Agent. Notifications have Resource Server, Subscription Server and Notifications Sender which can be implemented and deployed more together or separate.
* SC: See also for further detailing classes of products for the conformance model: https://github.com/solid/specification/issues/480
* SC: Do continue to use "pod" if not in specifications.
* SC: Coming back to the proposal, +1s or objections?

PROPOSAL: Merge TR/2022/protocol-20221231 ?

* eP: +1 to merging. (PR has been open for over 2 months now)
* SC: +1
* SC: I take that as no objections.

ACTION: SC to see if there are any last minute updates not touching conformance.

* eP: Are there any prior discussions about reorganizing the spec, extracting ??? into mini-specs, or taking the storage ??? because it looks like Solid ecosystem is composed by different specs, and some parts might be replaced but storage seems stable.
* SC: We may have touched on editors group. There's quite a bit of material that could be its own spec, but there hasn't been any proposal or initiative to actually separate until we have more material that could go into the protocol, no need to split out at the moment. Once those issues are a bit more mature we can come back to that questions.
* PAC: As you may remember, there's currently a project to create a working group that will take over custody of some of the spec. The charter was discussed earlier: https://github.com/solid/solid-wg-charter . Currently only mentions ??? but also mentions it might be split into smaller parts. This will be a topic of discussion of the WG, and anyone here is welcome to apply to become a member of the WG, and if you're not still welcome to join.
* SC: Depending on how it unfolds, it could be carried into the ??? community group. I need to create an issue to see if work needs to advance and Solid can reuse.
* eP: Normative references are quite a lot. If this were to go through PR, does it require that all normative references are ???
* PAC: Need to check the process.
* TBL: Having been frustrated by things at ??? stuck because can only advance when they can be pointed to normative references ??? need to take advantage of stability when the thing you're depending on is still a PR not a recommendation, if there are changes they'll be small. The idea is that there's enough flexibility so it can be implemented.
* eP: ??? it would mean solid-oidc would not be picked up as working item and won't make it to TR.
* TBL: Who's actually advancing the spec in this case? separate oidc group or external?
* eP: just Solid CG.
* TBL: it should be on the recommendation track.
* eP: ???
* SC: Applies to WAC, Notifications Protocol etc.
* TBL: quite often things break because authn changes. things like WAC are very stable so i worry about stability specifically in solid-oidc.
* PAC: One question for TBL: if this CG were to publish a report as a final report that gets kinda "frozen", would this be enough for a normative reference or soes it need a more official source?
* TBL: CG is mainly doing client-to-client specs. Profile specs, type indexes, things the server shouldn't need to know about so no dependencies on Solid protocol.
* PAC: I mean on process level.
* TBL: We need to put that to [W3C TAG](https://www.w3.org/2001/tag/) because that might trigger the formation of another WG. The idea is that CG is less formal, should have a TR face and when something ends up in TR ???
* SC: The CG is not mainly doing client-to-client, we have a number of specs there, authz, notifications. The description of the CG includes server-side parts. ??? original question was accurate. Some of the specs that will advance to the working group if and when it happens, the description of the ??? does not change. The group needs to still incubate that work and it's not just client. Unless WG picks up all specs related to server.
* TBL: Maybe that will be more logical because you need one group of people that deeply understand.
* SC: This is what I meant with classes of products: we say server, but the server is within the context of the spec, for example, in WAC we mean an authz server and so on. This is why precision is helpful. If we look at notifications protocol, as an example, we detail the subscription client interops with ??? and ???. At the moment we only have client and server as two products but I expect that to change.

### Shapes repository
URL: https://github.com/solid/specification/issues/506

* SC: Proposed by VB.
* VB: I have created this issue to follow up on last week's [shape reuse](https://github.com/solid/specification/blob/main/meetings/2023-03-01.md#shapes-reuse) topic. Please add comments.

---

### AuthN and AuthZ Server side clients (apps)
URL: https://github.com/solid/specification/issues/504

* SC:

### Auxiliary Resources with own Access Controls
URL: https://github.com/solid/specification/issues/501

* SC: About time we have a closer look at this for a future milestone?

### Resource state changes and differences
* SC: We can revisit the state of below issues (topics) and look at next steps.

#### Standardizing state changes in resources (history, undo, sync)
URL: https://github.com/solid/specification/issues/161

#### Evaluate existing RDF delta/diff formats
URL: https://github.com/solid/notifications/issues/157

* SC: Move work to solid/specification?