diff --git a/meetings/2026-01-21.md b/meetings/2026-01-21.md new file mode 100644 index 00000000..3b36e8a0 --- /dev/null +++ b/meetings/2026-01-21.md @@ -0,0 +1,146 @@ +# W3C Solid Community Group: Weekly + +* Date: 2026-01-21T14:00:00Z +* Call: https://meet.jit.si/solid-cg +* Repository: https://github.com/solid/specification + +## Chair + +* Christoph Braun - [uvdsl](https://github.com/uvdsl) + +## Present + +* Christoph Braun - [uvdsl](https://github.com/uvdsl) +* Ben Peachey (without microphone) [Potherca](https://github.com/Potherca) +* [Christopher Mühl](https://toph.so/profile#me) +* Alain Bourgeois +* [Melvin Carvalho](https://melvin.me/#me) +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) +* [Erich Bremer](https://ebremer.com) +* [Matthias Evering](https://solidweb.me/testpro/) +* Precious Oritsedere +* Rui Zhao +* [Michal](https://id.mrkvon.org) + +## Regrets + +None. + +## Scribes + +* Ben + +--- + +## 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 + +* Introductions + * Oli Bage (ODI) previous worked at a company that sponsored the ODI. https://edmcouncil.org/frameworks/cdmc/ + * Paul Worrall, been working with Linked Data since 2012. Worked with Inrupt. Back with Solid from an AI viewpoint. + + +## Actions Review + +* ✅ eP to propose in tomorrow's practitioners meeting to work on FedCM in a coding session + + + +## Topics + +### 2026 ODI Roadmap + +* JW: Thoughts around solid +* OB: Three big areas + 1. Having a roadmap that can be trusted + 2. Getting the standards to a specific level, mostly dictated by participants + 3. Persona based adoption - How would specific users (represented by a persona) priorities featues? + - Consumers, Researchers, Corporates, Software Developers + - Bringing best practices to the community group +* EP: Agrees persona based approach seems sensible, depending on availability of participants +* OB: The might be capacity to help with this available from the ODI. + - Hopes to have a path towards 1.0 by SoSy26 + - Positioning alongside the AI area might help adoption, specifically because there is more financing available in that area +* CB: Question: WG often work feature / use-case driven. There are personas behind the usecase, but they are not leading, per se. +* JW: Concern about Solid Spec v1.0 not having been explicitly presented to the workgroup. + - Take specific specs, and mark those as stable. More as a marketing campagne, to broadcast readyness of use (of the spec) for external parties +* EP: There is no guarantee of stability, which leads to a concern if v1.0 is communicated as stable. Elf feels supportive but hesitant. +* JW: The timeline is to have a first draft in April, extending the charter in December for the LWS group. + - May have a path to external funding for a reference implementation for "What is Solid 1.0" + - Various of the target specs are documents that are already quite stable. Documents that are more in motion would likely not be included. +* CB: It would be better to have v1.0 be a mark of technical stability rather than an marketing approach + - Spec writing efforts (at a minimum polishing things up) will still be needed, regardless of what there is now +* OB: Different sub-specs are at different levels of maturity. Having a clear line in the sand, for external parties, is the majority of the v1 goal. When other specs become more mature, v1.1 and v1.2 versions might follow. +* [Question on th echat]: Does this follow semantic versioning, e.g. 1=> for breaking changes? + - [Answer]: CB: it should. +* EP: As long as the communication is clear, that Solid is a spec, not an actual W3C standard. Details about how long things will last before backwards breakage occurs is also important. +* OB: Being a standard is more of a feature to adoption for specific external parties. It is not equally important to all organisations. +* JW: Walked briefly through the ODI roadmap, explictly highlighting bariers to adoption: + - Additions / Decisions regarding client implementations + - Best practices for client implemantors (client to client specs) + - Would like to prioritise suggested items with the group + - How to structure containers and best practices for container access + - Recommendations for content in public or private resources + - Promote a single Access Controll spec (WAC or ACL?) And get more consensus surrounding Notifications +* EP: Request to timebox the Roadmap walkthrough during this meeting +* EP: Proposes to have longer, specific meetings for specific items. + - Has concerns regarding open open ecosystem, a walled garden might be more realistic. Specifically from a perspective of stability and which requirements hould be part of v1 +* M: Will a similar discussion be held with the Practitioners Group? +* JW: Would appreciate contributions from the Practitioners Group, specifically regardin implementation and capacity. +* M: Ask specifically to share the parts of the Roadmap relevant for Practitioners Group with the Practitioners, invite to Practitioners meeting +* JW: [Answering a question regarding WAC vs. ACL] Would prefer not to let his personal preference lead the direction. Part is dependant on current server implementations. The data to allow making a data-driven decision is missing +* EP: Requests to move the focus back from details to the roadmap in general +* CB: Agrees with this sentiment. + +--- + +From the chat: + +* RZ: Was UI mentioned? Both about sample/entry app UIs (e.g. SolidOS), or branding or a common theme suggestion for Solid Apps? +* [Answer] Not specifically. It is on the roadmap - and trying to support getting SolidOS updgraded before SoSy, just separate work to Solid 1.0 + +--- + +### 2026 CG Roadmap +https://github.com/w3c-cg/solid/issues/54 + +* CB: Point to the Community Group (CG) roadmap (see link). There is overlap with the ODI roadmap. Consolidation is needed. Defining clear deliverables of what should materialise from work put into specific items. Request for comments from the meeting. +* EP: Implementation should drive the work on the spec. What are people implementing or wanting to implement? Could that be prioritised higher? If parties are currently implementing things (ODI, others) lets prioritise that (seconded by meeting participants) +* JW: Points to Oli as good help with setting priorities, and ask people to contact them in this regard. +* JW: [in answer to request for specific points] Marking things that are high-prio, add available resources/capacity +* CB: A tighter structure is good for the more corporate approach to keep an overview, but might work less well for the organic distribution of work items. Request if items can be marked when the ODI want to take a lead on specific items, to get insights into where overlap is with Community Group efforts +* EP: Request to plan a break-out meeting to detail workitems and priorities. Raises concern about vertical vs. horizontal task division. Creating test suites should also be a priority. What is the status of the current test harnass? +* JW: The idea is to help people with deadlines prioritise. +* CB: Communicating deadlines would help +* MC: Is deep into implementation. Client standards would be helpful. Is there any plan for that? A place where this can be discussed? Somewhere, anywhere? +* EP: For a common area using something Solid based would be nice? +* CB: Regarding "a place" GitHub discussion / Issues is a good place to start. +* EP: Suggestion to hold a follow up for more details. + +The topics of both roadmaps are to be carried over to next week's meeting. +Next week's meeting will be scheduled for an hour with an additional hour for targeted discussion for those who are interested. + + + +## Actions + +None.