# W3C Solid Community Group: Weekly

* Date: 2023-11-15T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://matrix.to/#/#solid_specification:gitter.im
* Repository: https://github.com/solid/specification
* Status: Draft

## Present

* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* Aaron Coburn (Inrupt)
* Hadrian Zbarcea (Inrupt)
* [Pierre Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* Laurens Debackere
* [Rahul Gupta](https://cxres.pages.dev/profile#i)

---

## 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
* Aaron Coburn

### Introductions
*

---

## Topics

### WIP Implementation Feedback

* eP: I was trying to implement [Conditional Requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests) and got stuck on `PATCH`. Each representation has it's own `ETag` but patch uses a different content type than `GET` and `PUT`.
* AC: From my perspective, ETag with conneg ends up being very complicated. There doesn't seem to be a clear answer. One can use Last Modified but that is only with a second precision. There is a lot to conditional requests and ETag that I tripped over and over again while implementing. Solid could address it better.
* PA: agree that ETags can be complicated. The Solid spec should be more clear about how to deal with them. It would be good to be in touch with IETF, as they are sensitive to specs overwriting other specs
* ...: the use of ETags is mostly about not overwriting data, but this is less of an issue with PATCH, as it appends rather then overwrites. With PUT, this would more important
* eP: if the PATCH is appending, this is less of an issue, also for change if there is a delete and add, the delete would fail if something has been changed meanwhile.
* RG: seconds PA's point about IETF. There is a sense that the Solid spec needs to be tightened up w.r.t ETags. They might be amenable to doing a formal review, if Solid were to approach them for that.
* eP: would that be just an email to a mailing list? what is the process?
* RG: there is a formal review process, but we need more information about how that process actually works and how to initiate it
* eP: the Last-Modified solution could also be sufficient, provided that the updates are less frequent than 1 per second. Retries, for example.
* RG: another possible solution, there is another spec called [BRAID](https://braid.org/) that has the ability to identify resource versions
* eP: there was discussion about having a demo on this in the past. Would that be possible for the future? If there are multiple people who would be willing to demo this, it could be really valuable.
* RG: will reach out to the main contributors to the spec

### Special Topic Meetings
URL: https://github.com/solid/specification/discussions/555

* eP: [14 Nov discussion](https://github.com/solid/specification/issues/592) about Access Grants & ACLs
* ...: issues have been raised about privacy of WebID. Would it be possible to use a pseudonym (non-correlatable) id?
* ...: discussed ACP and Access Grants / Data Grants. Where there is an access grant, ACP delegates to the AG. With that, is the full ACP needed?
* AC: Very briefly, full ACP is not needed if we end up delegating to Data Grants. The system doesn't need to be all that complicated.
* eP: Currently in the solid spec, the clients MUST conform to WAC/ACP, which is a high bar. The regular applications only need to understand about data grants
* ...: the access mgmt app is the only app that needs to understand the access policies/rules
* ...: then only the authorization agent has to understand the complexity of access control
* ...: perhaps we should reevaluate the role of WAC/ACP. Two main points:
* ...: 1. can be beneficial if access mgmt is done in only one place
* ...: 2. most apps can avoid interacting with access mgmt
* ...: by making this simpler, we can make this more secure
* AC: I agree, it is a high bar to assume that any app will be able to interact with access management system. Also anything what a regular app does can have a profound impacts. Anything what can keep regular apps away from interacting with access policies can be beneficial.
* eP: What are the best next steps for this? Wait for working group? start discussing now?
* PAC: I don't think we should wait for the WG. The main reason being that if WG is not chartered to work on that topic it will not pick it up. Given the number of depencencies, including the access control, especially the insufficient maturity level of those specifications. It is worthwhile to have this conversation before the working group starts. We should be clear what to include in the charter.
* eP: I would propose that we coordinate a special topic meeting to discuss this further
* ...: should we write something down first and then have the meeting?
* AC: If you plan a meeting I will arrange to attend it. Outlining some of the specific details would be helpful to focus the conversation.

ACTION: eP will expand on the [related issue](https://github.com/solid/specification/discussions/555) and will propose a date

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

* PA: We received a [review](https://github.com/w3c/strategy/issues/377) from the TAG, which echo some remarks from the AC review.
* ...: I don't know why we didn't get this review earlier, before sending it out to AC.
* ...: Now we are in a strang situation, where what we need to do now is go to the council and _not_ try to resolve existing issues
* ...: Instead, we should start over with the charter and then go back to the AC with the new charter
* ...: New idea for the charter: current charter is focused on one part of Solid (client-server protocol), but Solid is much larger than this, including social aspects (client specs, etc). Those social aspects were brought forward in the AC review: trying to solve a very large problem
* ...: The idea -- reducing the scope to just client to server protocol, leaving aside all the ambitions of building a decentralized web. That's the long term goal
* ...: What about LDP 2.0: adding access control and authentication
* ...: making this a successor of LDP would make this less about this being a special way to solve very large problems
* ...: This also would address the criticism that we are extending something existing rather than specifying something particular from Inrupt
* eP: This seems like a pragmatic approach to consider. There has been movement to make Solid _not_ a direct successor of LDP
* ...: A good step might be to document that prior work and how Solid differs from LDP
* ...: Then would it be reasonable to call it LDP 2.0
* HZ: this proposal would make solid completely different as it takes away the operational aspect of Solid
* PA: the goal is not to reduce Solid to reduce it to LDP 2.0, but rather to deliver one building block that can be used to build Solid, which would address some of the issues from the AC reviewers
* HZ: I'm looking at it from the point of view of adoption. Companies are expected to make investement in this new way of building apps. The way the content is deliveered, just looking at LDP, this will take much longer. The companies will less likely invest in adoption if we limit the scope this way.
* PA: I also wanted to respond to Solid not being strictly based on LDP -- that is something that I had missed, and so we would need to address that. There is a tension between bringing Solid as a whole to the W3C as a WG. That seems unlikely at present. Some of the concerns need to be addressed, and one way would be to reduce our ambitions to bring this to a standard track.
* AC: It is a very interesting idea, I need to think about it a little bit more. On the high level what I'm hearing is to make the decision, weather we are trying to specify Solid as a whole vs. specify something that would sit underneeth Solid. We can call it LDP 2.0 or something else. If we can build solid on top of that, others could try building something else on top of that. This would provide us a possibility to build solid in a meanigful way. Historically solid comes from LDP, it doesn't have a strict requirement. If LDP would be more clear on some points, and more flexible on other points we could build solid on top of that. If we were to consider something that would be LDP like I would have some ideas where we would like that to go. I like the idea of specifying somehing that solid sits on top of. This way the Solid could be very thin adding only what is missing in that base.
* PA: This is something that has crossed my mind: people could build solid and non-solid things on top of this protocol. "We are solving a problem that is important to the Solid community, but which can also be used elsewhere". The CG could then continue to incubate client-to-client standards. Anchoring the new working group on something existing, such as LDP, would give more standing to this proposal and to continue on the existing path of existing standards. This is a pragmatic tactic. If Solid doesn't need everything on LDP, there may be parts of LDP 1.0 that could be marked deprecated or archaic; or there could be different compliance levels or profiles. Implementations might not be required to implement everything because of the different compliance levels.
* eP: By rethinking our approach, this may be best for Solid. In yesterday's special topic meeting, we discussed how Solid needs to be able to evolve (e.g. 2.0, 3.0...). Several years ago, we need a path for introducing and sunsetting features. There are different ways to keep things explicit and also allow it to evolve. (reactive negotiation, modularity). LDP 2.0 could be a modularization of LDP 1.0. It will be important that, as we think about Solid versions, that we anticipate future versions and have a strategy for this.
* eP: How do we best follow up on this? Another special topic meeting? If we have two-hour meetings, they can be very productive.
* PA: The special topic slot isn't super convenient, but can try to make an exception for those discussions
* eP: We can also improve the scheduling of these meetings. We should also ensure that when the topic is selected, we take folks' availability into account

### Solid CG Chair Election Procedure
URL: https://github.com/solid/specification/discussions/582

* eP: Everyone can follow this on the mailing list. Each affiliation selects a representative. There are only two orgs that have selected a representative. Watch for an email today on this topic. I will suggest adding a week to this process.
* ...: this process is new, and we are innovating, so we are learning as we go
* ...: we may need to amend the process and charter, but it is also interesting to see what is possible
* ...: the process isn't perfect, but with constructive feedback, we can make things better