diff --git a/meetings/2026-01-14.md b/meetings/2026-01-14.md new file mode 100644 index 00000000..47fed0c3 --- /dev/null +++ b/meetings/2026-01-14.md @@ -0,0 +1,138 @@ +# W3C Solid Community Group: Weekly + +* Date: 2026-01-14T14:00:00Z +* Call: https://meet.jit.si/solid-cg +* Repository: https://github.com/solid/specification + +## Chair + + * Theo [@thhck](https://github.com/thhck) + +## Present + + * Christoph Braun - [uvdsl](https://github.com/uvdsl) + * [Erich Bremer](https://ebremer.com) + * [Melvin Carvalho](https://melvin.me/#me) + * Alain Bourgeois + * elf Pavlik + * Tom Byrd + * [Christopher Mühl](https://toph.so/profile#me) + * [Michal](https://id.mrkvon.org) + * Precious Oritsedere + * [Ted Thibodeau Jr](https://www.linkedin.com/in/macted/) (he/him) (OpenLinkSw.com) // GitHub:[@TallTed](https://github.com/TallTed) // Mastodon:[@TallTed](https://mastodon.social/@TallTed) + + +## Regrets + + +## Scribes + * CB + +--- + +## 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. + +--- + +## Introductions + +## Actions Review + +* eP: ✅ request update of roles in gh:w3c-cg/solid https://hackmd.io/@solid/cg-weekly/edit +* JW: ✅ create issue/discussion to establish a CG roadmap + +## Topics + +### CG Specification Lifecycle - feedback request (2 min) +https://github.com/w3c/cg-program/blob/main/proposals/spec-lifecycle.md + +eP: [...] council work on how CG items go to standardisation tracks, at the link there is documentation and slides. Next CG program meeting will be in February. This is just to give everyone a heads up to get familiar with it for those who are interested in the process. + +### Update on FedCM (5 min) +https://github.com/w3c-fedid/idp-registration + +* thhck: A update on the FedCM specification +* ...: FedCM is a new specification which has been proposed by Google, which makes the browser act as a middleware in the OIDC flow. One FedCM feature called `idp-registration` could improve Solid UX The interesting fact of this feature for Solid is that if you click a sign in button, the browser actually provides a list of Identity Providers (IDPs) where the user has accounts. I think it would be a great feature to have on Solid. Right now, the FedCM WG are working on the Candidate Release, and are not sure to include the identity provider registration. It has been tough to bring in more people who also want this features, so if anyone knows more people who might want such a feature, please let me know. +* eP: Do you have components so we could deploy it quickly? +* thhck: My component is ... in Pivot. It does not work in solidcommunity.net but it could work with some chrome flag enabled. I could look into that. +* eP: I think this would be a good idea. The main request from the FedCM WG was to show that the feature is actually used somewhere. (Aaron deployed it on IndieWeb?) +* ...: So then you could have a showcase and reach out to developers to adapt their apps to integrate it. Then we could reach out to the WG again. +* CG: What is the difference between FedCM flow and Solid-OIDC flow? That is, how much / what do I need to change on https://github.com/uvdsl/solid-oidc-client-browser? +* thhck: Most of the work is on server-side, I have a client that uses the Inrupt authn, it should not be that hard. +* eP: Basically, you provide PKCE to the browser fedcm api and you get back the authorization code. I would like to propose to join the practitioners, and maybe we could do some FedCM hacking in the coding session. So we could have a demo, and someone can follow up and document it. Just to get it working. +* thhck: I believe it is nice to work on FedCM for Solid and it is within our CG's scope but we need to reach outside of Solid to convince FedCM WG to keep the feature. Maybe we need other communities like Mastodon, matrix ... to get to advocates for the feature. +* AB: I prefer you speak of Pivot and solidcommunity.net, just to be clear on where it works. +* ...: I think there are other discussions to have better a logging (?) / log-in (?) system in Solid, I know Melvin is doing some work there. I would be interested on the current status there? + +### 2026 CG Roadmap (10 min) +https://github.com/w3c-cg/solid/issues/54#issuecomment-3723521386 + +* CB: we capture work item as github issue in the above link, feel free to add item, look at current issues if your interest is reflected, add your own, deadline is the 19 january. +* eP: please reference already existing issue, use cases and related work. +...: We should not only work on specifications, but also in implementations, test suits maybe etc. +...: My request would be that you also try to quantify how much work you can put into it (no punishment for not making it to the intended extend but just to get a feeling how much people would work on it) +* AB: Before we go to LWS, I have tried to read the PR, but I did not manage to understand that. +...: I believe it should be more accessible - the work seems to be geared towards specialists. +...: I believe I don't understand where we are with that PR and what the difference is with Solid. +...: But this accessibility issue applies not only to LWS but is also in general. + + +### Initial CRUD with proposed metadata handling (30+ min) +https://github.com/w3c/lws-protocol/pull/37 +* EB: So, I have been working on CRUD operations (Aaron and Jesse worked on authentication and authorization). +* ...: If you visit the PR link, there is another link in the description called Preview and Diff where you can access an HTML version. +* ...: So main difference is that we define abstract operations, what can be done on the system, before we present the REST binding, i.e., how to do it with HTTP. (And if somebody wants to implement the general operations with something else, they can). +* ...: So, main section is the Logical Resource Organisations. +* ...: Slash Semantics is no longer required - you can still do it, but it is not required. +* ...: The spec is RDF-optional. You dont need to use RDF with this specification (forget about it) but you can use it. +* ...: Link sets: Idea is that you can use your http linking to move into a file or json file. LWS will define the JSON and the shape will be defined using a JSON-LD shape and there is a context but it is not required to have that context in there. +* ...: There is a new content type `application/linkset+json` +* ...: And there will be meta data on resources and containers +* ...: ETAGS are currently listed as required - but this may change. +* ...: You can also just provide links in the link header, and not bother with the linkset file. +* ...: and for the linkset file, the spec defines it as json but it does not restrict that you can use turtle or something else. +* ...: there will be some core metadata that is server-managed +* ...: and you can add your own metadata as much as you want. +* ...: Hierarchies: There will only be one root. +* ...: If you want to move resources between containers, then you PATCH the linkset of the parent container +* ...: There is another PR for storage metadata / storage description +* ...: The spec currently says PUT - the spec will probably recommend PATCH to do actions on linksets but that does not exclude using PUT. +* ....: when you delete something, you will be able to indicate depth +* ....: of course, metadata is updated in that case. +* MC: Are you looking for implementors? I could probably build something. +* EB: Probably? +* MC: If I wanted to do that, who should I contact? +* EB: Let me find that out. +* eP: A client cannot control the URIs on the client-side, it seems? +* ...: I am curious about patching the linksets - do you have an example for moving a resource between contains? +* EB: IF you are familiar with JSON-merge-patch, I can write that example. +* eP: What is the impact on the authorization system? +* EB: There has some discussion, but yes this should be covered. +* [discussion on CRUD semantics - too fast paced to scribe] +* Michal: Reacting to the matter of authorization, I think it is not who can move the resource but rather what happens to the authorization of the resource? Does it adopt the authorization from the container as well? +* ...: Will the specification be RDF-agnostic? +* EB: Yes, RDF-optional. If an implementor does not care about RDF, then they do not bother with RDF. +* Michal: Does LWS provide content-negotiation for RDF resources on an LWS? +* EB: An implementation may choose to do that. +* MC: One observation: Normally, I'd use PUT to create, but the spec says POST. +* EB: The specification will recommend POST but it will not forbid PUT. + + +## Actions +* eP to propose in tomorrow's practitioners meeting to work on FedCM in a coding session + +