# W3C Solid Community Group: W3C TPAC 2024

* Date: 2024-09-27T16:00:00Z
* Call: Instructions are restricted to W3C users. You need to [log in](https://auth.w3.org/?url=https%3A%2F%2Fwww.w3.org%2Fevents%2Fmeetings%2F6c6bbdef-5999-43f1-a75e-9cfcf8fc8379%2F) to see them.
* Chat: TPAC Zoom chat
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* [Sarven Capadisli](https://csarven.ca/#i)
* Laurens Debackere (Digitaal Vlaanderen)
* [Pierre-Antoine Champin](https://champin.net/#pa)
* [Anatoly Scherbakov](https://yeti.sh)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* [Rahul Gupta](https://cxres.pages.dev/profile#i)
* Wonsuk Lee (ETRI)
* Hadrian Zbarcea
* [Jesse Wright](https://www.cs.ox.ac.uk/people/jesse.wright/) (University of Oxford)
* Sehwan Jeon
* Youngmin Ji
* Hiroshi Ota
---

## 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
* Sarven Capadisli

---

## Topics

### Overview

* VB: This meeting is intended to be an information session about the CG.
* VB: Meeting runs until 17:30 UTC (19:30 CET / 10:30 PDT). 10 minute break at 16:50 UTC (18:50 CET / 09:50 PDT).
* VB: Open agenda after the break. Proposals welcome at the bottom of the agenda.

### Introductions

* VB: Web dev, involved in Solid some time, am one of the co-chairs.
* PAC: INRIA and W3C. Involved in the CG sometime, and LWS charter, staff contact.
* Max: Alibaba Group and Alibaba Cloud, attending as an observer
* HK: Brazil Network info center. here as observer
* Sam Goto : Google, also here as observer
* WL(Wonsuk Lee): I am working for ETRI in South Korea. Started in project related to Solid. Here to contribute.
* LD: One of the co-chairs of LWS. Here representing gov of flanders.
* SJ: SEAK. Attending as an observer
* RG: From India. Been part of Solid CG since 2020. Been contributing to Solid Protocol and particularly done work on Notifications.
* eP: Originally from Europe. lvingin in Mexio. Participated in Social WG and now in Solid CG, FedID CG. Also rejoined the Social CG.
* JW: Formerly at Inrupt. Now at U. of Oxford. Making decentralised agents that represent legal entities using SOlid-ish technologies.
* AS: My name's Anatoly Scherbakov, involved with JSON-LD working group
* SC: Similar history as eP, chaired this group for 4 years, worked on editing and authoring a bunch of the specs. I try to implement the specs to help me understand if it's working as intended. Looking forward to participating in LWS.
* HZ: With Inrupt as solutions arhitect. Also co-chair of Solid CG.
* JK: WebContacts Guidelines. Cognitive Accessibility TaskForce. Longtime W3C member.
* Hooman:
* YJ: From Korea. Working with ??? Tech. I want to know the Solid solution so here.
* HO(Hiroshi Ota): Just started in this community.

### Solid CG Charter
URL: https://www.w3.org/community/solid/charter/

#### CG Work Items
URL: https://solidproject.org/TR/

* VB: Noting Out of Scope section in the CG's charter: "Community Group’s Work Items that have transitioned to a deliverable of an active Working Group." The Solid CG will coordinate with LWS WG and pause work on such items, and may continue as needed after the WG which is [chartered until 8 September 2026](https://www.w3.org/2024/09/linked-web-storage-wg-charter.html). Such work would typically include further incubation of applicable works; documenting erratas, new CG report versions.
* PAC: What the LWS charter says is that the primary input documents for working deliverables, Solid Protocol. The CG should probably refrain from making changes this one now. In custody of the WG so to speak.
* PAC: The other inputs are depends on the WG. Depends on the dependencies of the Protocol. At the momment it is still flexible. I suppose the CG could still work on those. In fact, the WG charter says it depends on the maturity of the works. IMO, the CG should refrain on the Protocl at the moment. And we can synch on regular basis. If CG wants to transfer other groups they can and of course if WG agrees.
* RG: When working on the new specification, are you going ot work on scratch or build on the current protocol. Because you're doing the Use Case from scratch. When new UCs emerge, it is not clear to me if you build on Solid Spec or start fresh.
* PAC: My understanding is that this will be the WG's definition.
* LD: See how input and output documents. There is the first meeting in two weeks time. It'd be premature to say that today.
* eP: For the CG-WG coordination. I posted FedID transition proposal: https://github.com/w3c-fedid/Administration/blob/main/proposals-CG-WG.md . In LWS there are tentative deliverables. We could try to adapt this process.
* SC: I want to add to PAC's point. Regarding the protocol it's a clear document, an input document to be continued with LWS. Why any of these odcumnets make it to WG is because there is significant incubation, not only ??? but implementation experience. In the past CG has been trying to behave like a WG would do. Makes the transition easier. If you look at the charters, there's emphasis on that at some poitn to get to a rec there needs to be open and interoprable implementations to show that it's not just a document. If the CG can focus more on showing that these things are real, they're used, there's good adoption, thatwill help us strengthen the argument that the work should continue in the WG or elsewhere. I'd like to separate the concerns of not only polishing documents but carrying implementations and test suites forward. If we can make the case that we have a good track record with implementations it'd help push those forward.
* eP: re RG's points, I think it'd be good to extract the storage part and the N3 patch parts from the specs, and x,y,z, referenced. My suggestion would be to extrcating them to balance them. In the CG we have some issues on adjusting naming, e.g., resource server, and so on. So, before publishing FPWD, it'd be good to adjust them, and storage extracted into dedicated spec.
* LD: LWS Chair hat off: One of the htings we probably have to take into account is that we had two iterations of this charter, and some objectsion, e.g., solutions oriented vs. problem oriented. So, hesitant I'm hesitant to just refine those documents. That'd might be a difficult position.

### LWS WG
URL: https://www.w3.org/groups/wg/lws/

* VB: There is a [Call for Participation: Linked Web Storage Working Group Charter Approved; Join the LWS WG](https://lists.w3.org/Archives/Public/public-lws-wg/2024Sep/0000.html).
* LD: We're probably have our first meeting in two weeks. There is a doodle out now in the public-lws mailing list. I'd suggest folks to register for that meeting. We've two IEs; from SC and DZ. First meeting is probably just an intro meeting. Looking forward to getting started.
* SC: Thanks for reviewing the request. Not sure how familiar PAC are with other activities happening in W3C regarding transitions, being more open with community involvement. There's a CG council, and there's been some activity in the past that came to my attention, trying to facilitate the continuation of the contributors. Not necessarily significant/any contributors. The idea is how can W3C improve that for the wider community. If people have been investing their time working CGs incubating the specs, how can they continue to get involved as a non-member. One of the venues is as an invited expert, but some of that rests on whether there's any asurances that they will be involved, what the criteria might be to get involve, involvement from the chairs, W3C team contacts, to look out for the contributors for the original specifications, test suites. Moving forward, looking out for contributors to the WG to be invited as an IE, and anyone who wishes to be an IE. There's issues and PRs for this against the charter drafts. Wondering if current LWS chairs are aware of those activities and initiatives and whetehr you are reaching iout to individuals to see if they'd like to join, what kind of criteria you're thinking of.
* PAC: There is a tension in the W3C on the way we work. Priorities is perhaps not the best word. Taking W3C members viws into acccount and also "web for all", and also as a non-profit org, is to take everyone's position into account. I can't say on top of all the discussions happening, with AC and W3C team and all. I'll try to follow-up on all this. I speak for myself: we've been discussing with the chairs on that. Appreciate the fact that this goes beyond the members, inlcuding outside membership. teh IE program is not always best way to deal with that. our critera for accepting IE applications is - as you mentioned significant into input documents, but let me emphasise again that, the WG in W3C, operate largely in the open. My personal experience, before more Univ at the time at w3C as member. First it was with subscribing to github / mailing list. I wasn't an IE but still felt part of it. Participation in the WG can happen in different ways. I htink also the chairs are on the same page on this: we want tight collaboration between the WG and the Solid CG. We want all voices. I appreciate the doc produced by FedCM.
* LD: Support what PAC said. Ways of getting involved, as member, IE, or participating in discusisons or elsewhere. The spirit of openness is of course what we want.
* SC: Keeping it in sync with W3C activities is good as long as it's aligned.

### Solid CG Updates and Demos at TPAC 2024
URL: https://www.w3.org/2024/09/TPAC/group-updates.html#solid

* VB: Thanks to eP, RG, SC for putting together the demos.
* eP: I don't know how many people saw them. If you have any questions if anything is unclear, comment on the video, Matrix, github discussion, questions, ect. Please engage.
* VB: eP published 3 parts. RG has on PREP. And SC ok dokieli.
* RG: Just +1 to what eP said.
* SC: If people have questions a good place is dokieli github or mailing lists, chats. I'm happy to share more details on the screencast in opther meetings or special topic meetings. The screencast is intended to be short, no audio. If you want to get the whole picture you can watch in a loop, but you may miss some of the context.

### Break
* VB: 10 minute break.

### LWS Kick-off meeting survey
URL: https://lists.w3.org/Archives/Public/public-lws-wg/2024Sep/0002.html

* SC: re https://evento.renater.fr/survey/linked-web-storage-kick-off-meeting-q9yhbg9p , would the organizers consider removing the option that overlaps with the Solid CG weekly (Wednesday, 16:00 CET / 14:00 UTC, if I'm not mistaken) so to avoid that possibility? Not a big deal either way.
* PAC: Hesitant to remove since there are no many slots available. We will take it into account when we make a decision.

### Use cases input from participants

* eP: What problems participants would like to solve with Solid?
* eP: When there are different proposals to evaluate against the use cases. I'm not sure if there was anything submitted to the WG re use cases. How do we imagine organising those UCs, later when we evaluate the requirements, we can use those UCs. Some UCs are domain-specific. But requirements could be more generic. How would the WG imagine organising those UCs. As I imagine the UCs are left there. Whenever a proposal is evaluated it is checked against the UCs.
* SC: Wednesday there was a [breaking silos meeting](https://docs.google.com/document/d/1sFZ0BozoLA3U7iROtu10tR7S05_OEOprS8Um9NZqZYw/edit), use cases from LWS, could PAC/others link to those meeting minutes? Are they published? That could be a response to the first question that eP had about which problems participants would like to solve. That's just a fraction of things. We have a long list of user stories issues and a repo but to my knowledge it is not properly comprehensive, there's some categories of use cases that are taken for granted: we assume they are covered by the requirements we have but we don't have anything more concrete, as eP suggested a proper matrix, something as to if use cases as evaluated, whether they're in scope, etc.
* HZ: One of hte big issues was in that call was about pod portability. It is very hard to move data from one location to another. If links are given, they may be broken. I'm not sure if that's something we should do in the WG or the CG.
* eP: There was a meeting about portability is Social Web meeting. And there would be different proposal. One for custom domain names, anothr for different resolution mechanisms, e.g., that isn't based on dns. A matrix that requires 'those' and 'that' requirement. Also to see priorities. For me it is important, for every proposal, we can evaluate those UCs.
* RG: What eP seems to ask is for architectural decision records in parallel with UCs and specifications. Perhaps something think in the WG.
* SC: CG have some issues on this. There's an ocean of issues on portability as HZ pointed out. One on privisioning a data storage. Some of that had some question marks. There's a proposal made by ??? submitted to CG but we did not do a good job evaluating that, having to do with redirects and deleting. Some of that can be evaluated in the CG still. There's work that already had been done and if it seems mature we can handover to WG anytime. In the CG we have plenty of threads/considerations put into our radar and we need to revisit instead of assuming it's not there.
* SC: I find this portability topic comes up a lot but an important distinction is what web architecture says about moving resources around, it's very clear about redirects. Another topic about moving data around. AFAIK those are separate things: moving URIs around than having a copy of your data in a new storage. The URI aspect is covered under webarch, copying/archiving your storage could be exporting a dump of your storage and having amechanism on the new storage to take that and extract. You have HTTP copy. Copying the data is different from saying this resource identified by this URI is moved to another location. The harder parts of the problem is coming up with URI persistance policies and enforcing. What kind of assurances will there be that they can continue toc use that when moved to another storage? Some of that is the policy work and not so much the architectural decision on how portocols and interfaces speak to each other. If we can find persistance policies that'd be the answer to the problem. The copying the data seems more complex technially but it's a lot simpler than handling the persistance issues.
* eP: what I'd like to get out is a strategy for UCs. For me the UCs are real-world, as opposed to the solutions. Working with the Food Network, open source software. It'd be good to connect with existing communities with user bases. Easy to experiment with. Wha thtye do but also using Solid. We should be hte last peopel to come pu with UCs. Get UCs from facing the problems. We used the solid forum, which is open source also. social web also wants to to do threads. We can showcase how this UC can overlap with ??? If we get a UC, we extract requirements, and some may be out of scope. Since some of the rquirements may be outside of hte scope, ??? then some will be for the WG and others left for the CG. Real challenge is to get the UCs from out there.
* RG: To answer HZ's UC quickly using SC's answer. Goign got flip SC's answer. I think this is not a problem for just Solid or LWS. Maybe for Web platform, the reality is 1B people in a country like India will not be abl to own a domain name. Portability is not always going ot work, and I don't tihnk we are in a place to answer it.

### FedCM & Solid

* LD: I see lots of opportunity integrating Solid with FedCM.
* eP: I think it is important to IdP registration part. Theo from Solid CG did a demo with Solid server and FedCM. Will continue on some work with NLnet to focus on FedCM into Solid server as IdP.
* LD: It'd be interesting to have a joint meeting.
* SG: Excited about Solid and to see it succeed. FedCM is happy to support. The next step is to be ??? stable, and build more exciting things with it. People want to be IdPs and RPs behind flags ??? We have prototype in Chrome. We're happy ot remove flag-var. The extension that the Solid needs, it is merged into Chrome so the user need sto turn it on settings. It helps us to control the deployment until we're confident about the utility of the API.
* eP: Allows the user to compare ??? and the user can choose the IdP. For Solid, we need this IdP registration.
* SG: No strict deadline, but at some point if no one uses it you should expect us to remove it. It has been in Chrome for more than 6 months, if it doesn't get used in somewhere between 1-10 years it will at some point get removed.
* eP: There's at least one Solid IdP using it. Few demo apps. Would that be enough or best way to communicate that for adoption in Solid.
* SG: Curious about the demo apps. Bigger and more is better than less and small. Feel and small is better than none (TM). I'm excited about Solid and IdP registration API. If enough people want it, the more people want it it'd be easier to make the case.
* eP: If LWS's authorization system, at least ??? would that help the FedCM's or only about current uses.
* SG: We're looking for real-world use as opposed to references and specs. But it doesn't hurt. The way in which the browser can be helpful to users.
* RG: SG, how is Solid perceived at Google, I mean broadly.
* SG: I can't speak on behalf of Google. Only a couple of promotions away from CEO. So, only Sam. Have worked years on SW. Have empathy. In Chrome, there are different levers. The work this group does, it is good for the web, in the same way the social web group is. Just personal views. You'll find a lot of empathy in Chrome for these things.

### AP with Solid or LWS or Storage or Whatever

* SC: There's some initiative on Social Web circles to have Solid storages as activity stream collections, following contacts, sending messages. There's old issues for NSS. We have Activity Pods and other work trying to merge both works. Fold behind those works seem to be confused as to where those gaps in specs should be addressed: Solid specs, implementations, Social web? We should revisit some of these with Social Web folks. Solid CG could revisit.
* PAC: Had a long and interesting topics on those with EP. There is the Social Web Maintenance WG charters.. The channels are open and agree with SC.