|
| 1 | +# W3C Solid Community Group: Weekly |
| 2 | + |
| 3 | +* Date: 2026-03-25T14:00:00Z |
| 4 | +* Call: https://meet.jit.si/solid-cg |
| 5 | +* Repository: https://github.com/solid/specification |
| 6 | + |
| 7 | +## Chair |
| 8 | + |
| 9 | +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) |
| 10 | + |
| 11 | +## Present |
| 12 | + |
| 13 | +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) |
| 14 | +* [Roberto S.K. Breitman] (the ODI) |
| 15 | +* <a href="https://csarven.ca/#i" rel="schema:attendee">Sarven Capadisli</a> |
| 16 | +* [Luke Dary](https://w3c.social/@lukedary) |
| 17 | +* Jeff Zucker |
| 18 | +* [Precious Oritsedere](preciouse.oritsedere@theodi.org) |
| 19 | +* [Rui Zhao](https://me.ryey.icu) |
| 20 | +* Alain Bourgeois |
| 21 | +* Theo - thhck |
| 22 | +* Michal |
| 23 | + |
| 24 | + |
| 25 | +## Regrets |
| 26 | + |
| 27 | +* Christoph |
| 28 | + |
| 29 | +--- |
| 30 | + |
| 31 | +## Scribe |
| 32 | + |
| 33 | +* Jesse Wright |
| 34 | + |
| 35 | +### Meeting Guidelines |
| 36 | + |
| 37 | +* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). |
| 38 | +* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). |
| 39 | +* 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. |
| 40 | +* Join queue to talk. |
| 41 | +* 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. |
| 42 | + |
| 43 | +### Participation and Code of Conduct |
| 44 | +* [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/) |
| 45 | +* [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/) |
| 46 | +* 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. |
| 47 | +* If this is your first time, welcome! Please introduce yourself. |
| 48 | + |
| 49 | +--- |
| 50 | + |
| 51 | +## Introductions |
| 52 | + |
| 53 | +* |
| 54 | + |
| 55 | +## Announcements |
| 56 | + |
| 57 | + |
| 58 | +## Topics |
| 59 | + |
| 60 | + |
| 61 | +### Action review |
| 62 | + |
| 63 | +- Deferred: ( report next week, CB not here..) |
| 64 | + - WAC PR: [Add condition to authorization evaluation](https://github.com/solid/web-access-control-spec/pull/134) |
| 65 | + - SC: Ok with moving this to next week. |
| 66 | + - WebID or WebID-Profile |
| 67 | + |
| 68 | + |
| 69 | +- JW: ✅ list of Solid Server on a spreadsheet to see who implement WAC vs ACP https://lists.w3.org/Archives/Public/public-solid/2026Mar/0019.html |
| 70 | + |
| 71 | + - eP: Any other actions |
| 72 | + - JW: Is there anyone we haven't captured |
| 73 | + - eP: Manas |
| 74 | + - JW: I will contact damoo |
| 75 | + |
| 76 | +- JW: will try a draft a on Solid-WebID and .. by next week so ppl have time to review. To be covered as part of the topics. |
| 77 | +- Theo: ✅ cancel April 29th meeting: done through w3c calendar, hope everyone got the notification! |
| 78 | +- Theo: setup IA scribing meeting: will do after Sosy — tracked in https://github.com/w3c-cg/solid/issues/77 |
| 79 | + |
| 80 | +### CG mailing list |
| 81 | + |
| 82 | +* eP: Not all CG participants can join meetings and follow minutes, for example https://matrix.to/#/!NoAshgRzHhPJsdpPkf:gitter.im/$UeX1kHldszLW7HMjgGyMnJDcpwSIgHcntM2S12l3fm4?via=gitter.im&via=matrix.org&via=matrix.jones.dk |
| 83 | +* eP: Do we need to be sending out more information over the mailing list |
| 84 | +* VB: Some things are hard to follow, not sure it would be useful to have these things in the minutes. Mailing list is easier to keep an eye on. |
| 85 | +* eP: Yes, a good example would be the Solid26 |
| 86 | +* JW: If there are key topics to communicate, whever brought the topic has the responsibility to send out communication in next 3 days. So we should have taken an action. |
| 87 | + |
| 88 | +### CG feedback to ODI - AC meeting on 23rd |
| 89 | + |
| 90 | +* eP: I will look at bullet points below before the meeting |
| 91 | +* eP: there was mention of https://github.com/solid/shapes |
| 92 | +* eP: there's also https://github.com/solid/object |
| 93 | + |
| 94 | +* eP: There was an AC meeting on Monday |
| 95 | +* SC: Does |
| 96 | +https://github.com/solid/odi-governance/blob/main/README.md#advisory-committee contain an up-to-date list of members? Based on the table, ~4 people attended? Who was in the meeting? Are there minutes? |
| 97 | +* JW: No, most members are listed in https://theodi.org/news-and-events/news/the-odi-announces-new-odi-solid-advisory-committee/ |
| 98 | +* eP: The shapes repo was also announced in the AC. It would be good to have that announced in the CG and raised. |
| 99 | +* JW: Someone has been working to design shape repo in recent weeks. It is based on NLnet grant proposal submitted by ....., the goal is to provide space for people to contribute shapes they are using. It could provide space to work on consensus. It has been an exercise that is used in SolidOS. Not to say that SolidOS is a source of truth. Now it is a time we would like to put out for feedback. |
| 100 | +* eP: We could have an issue with a checklist of feedback to collect. I would also ask that there is provenance of where the data was coming from. |
| 101 | +* JW: What are you looking for in the checklist in the PR? |
| 102 | +* eP: What you plan to do before there is further feedback. |
| 103 | +* JW: Yes, we would expect to do that in the future. There are smaller iterative steps we are taking first: getting CI validation on shapes, mapping the shape to an object, publishing the object. |
| 104 | + |
| 105 | +### solid26.org |
| 106 | +https://github.com/solid/solid26 |
| 107 | + |
| 108 | +* eP: We had some friction on solid/specification matrix and need to coordinate it better. |
| 109 | +* JW: both the google doc that went out by email and the original version contained inacurate content. I take acountability. I have modified the md source to more accurately reflect what solid26 is and the goals. |
| 110 | +* https://github.com/solid/solid26/blob/main/content.md |
| 111 | +* JW: ODI is aiming for marketing campaign and bringing more engagement. It will join CG in iterating on specs. As a spec, we were looking to create a primer doc with CG which reflects subset of docs in the TR page. [iterating details]. If we don't have specific modules complete, we just don't include them. People in commercial space need something stable. We will iterate on the feedback and improve for Solid 27. |
| 112 | +* SC: It's not that complicated an exercise. If CG is snapshotting, those are the specs that CG can provide (e.g., CG-DRAFT, CG-FINAL), about as "mature" as it gets. In cases where there are multiple options, we can gather some data behind it. I worry that there is a difference between primer or document recommending a snapshot of something that has a promise of interop. Going from having something, Solid WebID Profile has been around as long as I can remember. There is some data that Jeff has provided. Dropping that and picking up something else is premature. |
| 113 | + |
| 114 | +### Solid 2026 best practise documents |
| 115 | +https://github.com/orgs/solid/projects/18/views/1 |
| 116 | + |
| 117 | + |
| 118 | +#### WebID or WebID-Profile |
| 119 | + |
| 120 | +* JZ: Comment from Jesse about profile not being implemented differs from what my crawler shows. https://jeff-zucker.github.io/solid-load-profile/ has the data showing that Solid WebID Profile is used. |
| 121 | +* JW: To the best of my knowledge, it is not consistently implemented across servers. |
| 122 | +* JZ: WebID Profile spec is primarily aimed at clients rather than servers, and nothing in it forbids WebID Documents from being hosted on non-Solid servers. |
| 123 | +* eP: WebId profile lets you perform write operations, thus making the assumption that a WebID is hosted on a Solid resource server -- which is not a valid assumption for many Solid servers. Not allowing HTTP PUT or PATCH to protected triples. |
| 124 | +* VB: Can we use existing spec documents for this work, rather than throwing away years of work and starting from scratch once again, creating a new document which duplicates work? Each implementation has their own decision making processes; this work was carried out in the CG over years, had plenty of discussions and what made it in there was a result of that consensus. If servers did not implement is a separate issue. They were all taken into account and participated during the discussions. |
| 125 | +* SC: We have had quite a bit of discussion on this topic in the Solid WebID group which is minuted. Whether the spec has any server requirements is irrelevant to the point. What we are describing is how would a WebID profile exist within the specifications that are issued from this group. This specification is defining how the read/write operations would be performed if they are on a Solid server. Describing how WebID is handled elsewhere (e.g., when it is managed by 3rd parties) is out of scope. When 3rd parties control your WebID is a separate topic, which is ironic considering the Solid vision. That said, if there are issues — then we can re-shuffle requirements into a separate document. If people don't like `oidc:issuer`, then it can go somewhere else like preferences. |
| 126 | +* eP: My view is that the safe baseline is the old WebID draft from WebID CG. When it comes to what WebID profile brings in; it is about how it is used, how other specifications interact with it. I know the worry that we are pushing Inrupt's vision where their WebID is external, I am using CSS and my setup also hosts WebID's externally using small custom Hono server backed by Oxigraph. |
| 127 | +* JZ: The spec says, if on Solid server, this is what you do. Agree with SC, we as in Solid what we can make a determination on what's not on Solid. Not within the scope of what Solid can address. |
| 128 | +* SC: If there are bugs in the specifications, they should follow the typical CG process for addressing them (see CG contribution guidelines below). When I look at the WAC vs ACP spreadsheet, vast majority of the applications align with the open source servers. That's the interop we can point at. There are servers that these applications do not interact with and so it doesn't make sense to optimise for the edge closed-source servers that are not even part of this conversation. If anything, they can play along with the ecosystem that we have (based on data). Also, the CG Contributing Guidelines details Work Items: https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#work-items |
| 129 | +* eP: I propose we include minimum, which is the plain WebID spec. Then the topic for conversation is whether to include `pim:storage`. |
| 130 | + |
| 131 | +## Actions |
| 132 | + |
| 133 | +## Decisions |
| 134 | + |
0 commit comments