9 |
10 |
--------------------------------------------------------------------------------
/meetings/2020-11-19.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-11-19
4 | * Call: https://meet.zrh.init7.net/solid-specification
5 |
6 | ## Present
7 |
8 | * Tim Berners-Lee
9 | * Sarven Capadisli
10 | * Justin Bingham
11 |
12 |
13 | ## Scribes
14 |
15 | * Justin Bingham
16 | * Sarven Capadisli
17 |
18 | ## Agenda
19 |
20 | - Update spec document to Solid Protocol
21 | - Solid-OIDC
22 | - WAC / Access Control Policies / Authorization Framework
23 | - WebID[+Authentication] (Solid CG / Web Platform Incubator CG)
24 |
25 | ## Minutes
26 |
27 | * Solid Ecosystem - update aligned with solidproject.org
28 | * Where to publish spec..
29 | * having a stable vesion of WAC is important.
30 | * look into clients supporting
31 | * capabilities/posession goes into research column
32 |
33 | ## Action
34 | * update Solid Ecosystem - Sarven
35 | * publish at github for now
36 | * update WAC - Sarven (MUST for Solid ecosystem)
37 | * Ping Wendy, JeffJ, RalphS re WebID on strategy
38 |
--------------------------------------------------------------------------------
/meetings/2020-04-27.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-04-27
4 | * Time: 13:00 CET (see your local time)
5 | * Duration: 1 hour
6 | * Call in Details: https://whereby.com/solid-project
7 | * Moderator: Sarven Capadisli
8 |
9 | ## Present
10 |
11 | * Justin Bingham
12 | * Sarven Capadisli
13 | * Eric Prud'hommeaux
14 |
15 | ## Scribes
16 |
17 | * Sarven Capadisli
18 |
19 | ## Organizing the Specification Work
20 |
21 | * Variability in Specs: https://github.com/solid/specification/issues/138
22 | * Review initial outline (in master branch)
23 | * Look at best way to provide status of work on various spec sections
24 | * Use "topic based organization"
25 |
26 | ## Resource Metadata
27 |
28 | * Relating to https://github.com/solid/specification/pull/156
29 | * Determine appropriate way to refer to section as a whole
30 | * Metadata considered too broad of a term
31 | * Consider renaming to Auxillary Resources
32 | * Move specific metadata types into their own sections
33 |
--------------------------------------------------------------------------------
/meetings/2020-11-06.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-11-06
4 | * Call: https://meet.zrh.init7.net/solid-specification
5 |
6 | ## Present
7 |
8 | * Justin Bingham
9 | * Sarven Capadisli
10 | * Tim Berners-Lee
11 |
12 | ## Scribes
13 |
14 | * Sarven Capadisli
15 |
16 | ## Agenda
17 | * Update spec document to Solid Protocol
18 | * WAC / Access Control Policies / Authorization Framework
19 | * Solid-OIDC
20 | * WebID[+Authentication](Solid CG / Web Platform Incubator CG)
21 |
22 | ## Minutes
23 | * Solid Ecosystem - update aligned with solidproject.org
24 | * Having a stable vesion of WAC is important, ACP becomes MAY when documented
25 | * look into clients supporting
26 | * capabilities/posession goes into research column
27 |
28 | ## Action
29 | * Update Solid Ecosystem document - Sarven
30 | * Keep publishing spec at github for now
31 | * Update WAC document - Sarven (MUST for Solid ecosystem)
32 | * ACP can be MAY when spec draft is ready
33 | * Ping Wendy, JeffJ, RalphS re WebID on strategy
--------------------------------------------------------------------------------
/LICENSE.md:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright 2019 - 2024 W3C Solid Community Group
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
6 |
7 | The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
8 |
9 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
10 |
--------------------------------------------------------------------------------
/meetings/2020-04-03.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-04-03
4 | * Time: 14:00 CET
5 | * Duration: 1 hour
6 | * Call https://whereby.com/solid-project
7 |
8 | ## Present
9 |
10 | * Justin Bingham
11 | * Sarven Capadisli
12 |
13 | ## Scribes
14 |
15 | * Justin Bingham
16 | * Sarven Capadisli
17 |
18 |
19 | ## Topics
20 |
21 | * Recording Editorial Summary - Record summary on W3CG wiki. Mention on the Solid Gitter chat. Mention on CG Mailing List.
22 | * Discussion on Weekly Community Group Meetings - Propose monthlies more like Solid World session yesterday which seemed really successful. Emphasis on having agenda items.
23 | * Specification Working Sessions
24 | * Announce first time slot via W3C Solid CG mailing list - Wednesday (April 8th) - 9:30 – 11 EST / 2:30 – 4PM UK / * 3:30 – 5PM CEST, with Rough Agenda. New agenda items are welcome.
25 | * Publishing minutes afterward
26 | * Will use gotomeeting web-conference for audio/video
27 | * Will use solid/specification gitter for chat
28 | * Agenda
29 | * Status Update on Work in Progress
30 | * Pull Request for Rough Consensus Items
31 | * Pull Request for Auxiliary Resources
32 |
--------------------------------------------------------------------------------
/meetings/2020-06-12.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-06-12
4 | * Time: 14:00 CEST / 08:00 EST
5 | * Duration: 1 hour
6 | * Call: https://meet.zrh.init7.net/solid-specification
7 |
8 | ## Present
9 |
10 | * Sarven Capadisli
11 | * Justin Bingham
12 |
13 |
14 | ## Scribes
15 |
16 | * Sarven Capadisli
17 | * Justin Bingham
18 |
19 |
20 |
21 | ## Minutes
22 |
23 | ### Issues with information organization
24 | * Site should be citeable and referenceable by others writing about solid, and those references should help ensure solid is discussed accurately.
25 |
26 | ### Panel work in flight
27 | * Authorization Panel Resurrected
28 | * Use Cases and Requirements
29 | * Interoperable Ecosystem Proposal
30 |
31 | ### Need to be able to find out what access a given agent has
32 | * Ability for an agent to query the access that they have on a given resource without control access.
33 |
34 | ### Documenting Minutes
35 | * List panel meetings in the wiki
36 | * Create space per panel into the wiki
37 | * Recommending to have active panel members sign up to w3c community group
38 | * Justin to submit pull request to solid/process
39 |
40 | ### Solid World
41 | * Sarven to present an editorial update
42 | * Get inputs from editorial team ahead of that for sharing
--------------------------------------------------------------------------------
/meetings/2020-05-29.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | Date: 2020-05-29
4 |
5 | Time: 14:00 CEST / 08:00 EST
6 | Duration: 1 hour
7 | Call in Details: https://meet.zrh.init7.net/solid-specification
8 | Agenda/Summary:
9 |
10 | ## Present
11 | * Sarven Capadisli
12 | * Justin Bingham
13 | * Matthias Evering
14 |
15 | ## Scribes
16 |
17 | * Sarven Capadisli
18 | * Justin Bingham
19 |
20 |
21 |
22 | ## Minutes
23 |
24 | * Justin - https://github.com/solid/process/issues/202 - Planning to suggest action items for rough consensus in the issue this weekend - Will then create process change following that
25 |
26 | * Justin - Work in progress on the interoperability panel to address https://github.com/solid/data-interoperability-panel/blob/ecosystem-proposal/problems-and-goals.md. Progressing in the interoperability panel on https://github.com/solid/data-interoperability-panel/blob/ecosystem-proposal/proposals/ecosystem.bs branch. Application registration will start being reviewed by panel next week.
27 |
28 | * Justin - Work progressing on shapetrees at https://github.com/shapetrees. Helps to inform shape validation and shape tree validation proposals that'll be made to the core spec.
29 |
30 | * Sarven - Discussion around https://github.com/solid/specification/pull/160#issuecomment-635932724
31 | * Much more detail provided in the comment
32 | * Functional requirements and conformance criteria added in the comment
--------------------------------------------------------------------------------
/meetings/2021-07-20.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-07-20
4 |
5 | ## Present
6 |
7 | - Tim Berners-Lee
8 | - Justin Bingham
9 | - Ruben Verborgh
10 |
11 | ## Scribes
12 | - Justin Bingham
13 |
14 | ## Minutes
15 |
16 | ```
17 | justinwb
18 | justinwb says:
19 | https://github.com/solid/process/issues/258
20 | 13:20
21 | me says:
22 | https://github.com/linkeddata/rdflib.js/blob/main/src/update-manager.ts#L605
23 | 13:27
24 | justinwb
25 | justinwb says:
26 | https://github.com/solid/specification/blob/feature/notification-protocol-data-flows/notification-protocol-data-flows.md
27 | justinwb says:fyi - just started taking some notes when ruben joined -
28 | https://hackmd.io/tR-N3JgTR1qtNytyrO_oQQ
29 | 13:45
30 | ```
31 |
32 | TBL: Secure websockets is top priority
33 |
34 | JB: Need to get implementors together to look at options and possible drafts. We have one draft that has been shared but not proposed. Likely needs a fair bit of work.
35 |
36 | RV: Need to ensure that we have a good draft, clean up any possible shortcuts / workarounds.
37 |
38 | JB: In a place where we need notifications / websockets urgently, but also need a good spec / design. What's best way to avoid ending up with inadequate solution?
39 |
40 | RV: Need to get versioning in for websocket
41 |
42 | JB: Purpose of proposing resurrecting notification panel, was essentially to use that as a vehicle to get the right people together to work on an implementation and advance a draft document together.
43 |
44 | TBL: OK +1 / RV +1
45 |
46 | RV: Would like to be involved Initial discussions on protocol would
47 |
48 | JB: Action Item: I will coordinate the session (as part of or as a precursor to getting the panel going)
49 |
--------------------------------------------------------------------------------
/meetings/2020-11-30.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-11-30
4 | * Call: https://meet.jit.si/solid-specification
5 |
6 | ## Present
7 | - Ruben Verborgh
8 | - Justin Bingham
9 | - Sarven Capadisli
10 | - Tim Berners-Lee
11 | - Olivia Larkin
12 |
13 | ## Scribes
14 |
15 | * Sarven Capadisli
16 | * Justin Bingham
17 |
18 | ## Agenda
19 |
20 | - Structure of ecosystem document and related specifications
21 | - Solid Protocol, Solid-OIDC, WAC, ACP, Shape Trees, etc.
22 | - ACP Update - Functional Requirements / Spec / Primer
23 | - WebID / DID - Proposal from Dmitri - https://github.com/solid/identity-panel/issues/1
24 |
25 |
26 | ## Minutes
27 |
28 | ### Structure of ecosystem document and related specifications
29 |
30 | TIMBL: Core protocol should include authentication, authorization, identity - Solid Protocol is client/server protocol
31 | - Also doesn't include account management
32 |
33 | JB: Propose to rename current ecosystem document to solid protocol since that it was it encapsulates [AGREED]
34 |
35 | JB: Where should documents be published to?
36 |
37 | TIMBL: Propose to publish to solidproject.org under /TR
38 | - JB - Will take the action
39 | - https://solidproject.org/TR/ecosystem
40 | - https://solidproject.org/TR/protocol
41 |
42 | * https://www.w3.org/DesignIssues/CloudStorage
43 | * https://invisibleup.com/articles/33/ - on the need to build your own web site
44 | * https://csarven.ca/linked-research-decentralised-web#activities
45 | * https://solid.github.io/specification/
46 |
47 | Scratch
48 | * https://solidproject.org/specs/{id} or https://solidproject.org/TR/{id}
49 | * https://www.w3.org/TR/sparql11-overview/ is good example of overview (like Ecosystem) + individual specs
50 |
51 |
--------------------------------------------------------------------------------
/meetings/2021-04-06.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-04-06
4 | * Call: https://meet.jit.si/solid-specification
5 |
6 | ## Present
7 | * Justin Bingham
8 | * Sarven Capadisli
9 | * Kjetil Kjernsmo
10 | * Dmitri Zagidulin
11 |
12 | ## Scribes
13 |
14 | * Sarven Capadisli
15 | * Justin Bingham
16 |
17 | ## Agenda
18 |
19 | * Announcements
20 | * Pull Requests
21 | * Issues
22 | * Topic Items
23 | * Protocol Feature list
24 |
25 | ## Minutes
26 |
27 | ### Access Modes
28 |
29 | JB: Believe that access modes should be more exact. For example, write is overloaded (allows for creating, deleting, updating), as opposed to create, delete, update permissions.
30 |
31 | KK: Believe in principle of least privilege
32 |
33 | SC: Be careful to decouple operations from access modes in protocol discussions. Possible to have any mode in WAC/ACL if needed. Not all authorization requirements entail "access modes" (in the ACL sense). Possible to use capability based security model.
34 |
35 | JB: Main use case I want to make sure is that we're able to rigidly control create resource vs. affecting non-managed triples in container graph
36 |
37 | SC: Possible in WAC/ACL.
38 |
39 |
40 | ### Auxiliary Resources
41 |
42 | KK: Question about the use / pattern of auxiliary resources
43 |
44 | SC: Discussion about the pattern of having auxiliary resources tied to lifecycle .. has_odrl eg. https://github.com/w3c/odrl/issues/12 (and side discussion with Tim on resusing describedby for ODRL for the time being.)
45 |
46 | JB: What's the pattern / ground rules for overloading describedby vs. adding a new aux resource type
47 |
48 | TBL: Try to avoid adding new auxiliary resource types as much as possible vs. storing in describedby - generally try to add new ones
49 |
50 |
51 |
52 |
--------------------------------------------------------------------------------
/meetings/2021-07-27.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-07-27
4 |
5 | ## Present
6 | * Ruben Verborgh
7 | * Kjetil Kjernsmo
8 | * Tim Berners-Lee
9 | * Justin Bingham
10 | * Sarven Capadisli
11 |
12 | ## Scribes
13 | * Kjetil Kjernsmo
14 | * Justin Bingham
15 | * Sarven Capadisli
16 |
17 | ## Agenda
18 |
19 | * https://github.com/solid/specification/milestone/4
20 | * Secure Websockets eg. https://github.com/solid/specification/issues?q=is%3Aissue+is%3Aopen+websocket
21 | * https://github.com/solid/specification/blob/feature/notification-protocol-data-flows/notification-protocol-data-flows.md
22 | * https://github.com/solid/specification/issues/142
23 | * https://github.com/solid/specification/pull/284
24 | * https://github.com/solid/specification/issues/267
25 |
26 | ## Minutes
27 |
28 | SC: Focus on milestone/4 + secure websocket only. notification-protocol-data-flows can be taken up in notifications-panel (if/when)
29 |
30 | SC, KK, TBL, RV: Okay to close https://github.com/solid/specification/issues/142
31 | SC: Close 142 as it is not testable. Agree on variability, document any best practices.
32 | TBL: discussion on web architecture.. need not be taken up in Solid CG
33 |
34 | SC: Anything outstanding before merging https://github.com/solid/specification/pull/284 ? KK, TBL, RV: Ok to merge.
35 |
36 | SC, KK, TBL: Reached rough consensus on https://github.com/solid/specification/issues/267 .. update existing Note to include 'on the same-origin' (as originally implied).
37 |
38 | ## Actions
39 | * Find any documentation on secure websockets. Done: notification-protocol-data-flows is the only one hinting at wss and query
40 | * Create issue specifically for secure websockets. Done: https://github.com/solid/specification/issues/289
41 | * Close https://github.com/solid/specification/issues/142 . Done.
42 | * Ruben to follow up on Secure Websockets
--------------------------------------------------------------------------------
/meetings/2021-07-06.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-07-06
4 |
5 | ## Present
6 | * Justin Bingham
7 | * Sarven Capadisli
8 |
9 | ## Scribes
10 | * Justin Bingham
11 |
12 | ## Agenda
13 |
14 | * **Action Items from Last Week**
15 | - **TBD** - Determine github repo/location for meeting minutes (all editors)
16 | - **DONE** - Update columns in solid/specification to reflect editorial phases (from latest process) (KK)
17 | - **DONE** - Tag monthly items with a "current month" milestone (KK)
18 | - **DONE** - Move items for this month into that milestone (KK)
19 | - **IN-PROGRESS** - Identify reference issue for notification protocol / secure websockets to be tracked
20 | - *JB: https://github.com/solid/specification/issues/49 seems wide enough to cover notification protocol + websockets*
21 | - **IN-PROGRESS** - Review proposed websocket doc (all editors)
22 | * **Prioritized Items**
23 | * Notification Protocol / Secure Websockets - See: https://github.com/solid/specification/blob/feature/notification-protocol-data-flows/notification-protocol-data-flows.md
24 | * Ownership
25 | * Server-managed metadata
26 | * SPARQL-Update
27 |
28 | ## Minutes
29 |
30 | ### Notifications Protocol / Secure Websockets
31 |
32 | SC: Where should the notification protocol / secure websocket work be conducted? Where to move the proposal document? Resurrect the notification panel?
33 |
34 | JB: Ideally should be iterating on the document together with implementors / implementation.
35 |
36 | Action Item: Pick a place for the work to live (e.g. solid/notifications-panel)
37 |
38 | (Agreement from JB / SC to gaugue interest in participating in these efforts)
39 |
40 | See: https://github.com/solid/process/issues/258
41 |
42 | Action Item: Organize a meeting of interested parties to figure out how to advance the effort forward.
43 |
--------------------------------------------------------------------------------
/solid.svg:
--------------------------------------------------------------------------------
1 |
10 |
--------------------------------------------------------------------------------
/meetings/2025-07-09.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-07-09T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Chair
9 | * Hadrian Zbarcea
10 |
11 | ## Present
12 |
13 | * Hadrian
14 | * elf Pavlik
15 | * [TallTed // Ted Thibodeau Jr](https://github.com/TallTed) (he/him) [mastodon:@TallTed](https://mastodon.social/@TallTed) (OpenLinkSw.com)
16 | * Tom Byrd
17 | * Erich Bremer
18 | * Marc Haddle
19 | * Rui Zhao
20 |
21 |
22 | ## Regrets
23 |
24 |
25 | ## Scribes
26 | * N/A
27 |
28 | ---
29 |
30 | ## Announcements
31 |
32 | ### Meeting Guidelines
33 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
34 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
35 | * 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.
36 | * Join queue to talk.
37 | * 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.
38 |
39 | ### Participation and Code of Conduct
40 | * [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/)
41 | * [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/)
42 | * 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.
43 | * If this is your first time, welcome! please introduce yourself.
44 |
45 | ---
46 |
47 | ## Review Action items
48 |
49 | ## Topics
50 |
51 | * open conversation
52 |
53 | ## Actions
54 |
55 |
--------------------------------------------------------------------------------
/meetings/2020-05-22.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-05-22
4 | * Time: 12:00 Zulu / UTC, 14:00 CEST, 08:00 EST
5 | * Duration: 1 hour
6 | * Call: https://meet.zrh.init7.net/solid-specification
7 |
8 | ## Present
9 |
10 | * Sarven Capadisli
11 | * Justin Bingham
12 |
13 |
14 | ## Scribes
15 |
16 | * Sarven Capadisli
17 | * Justin Bingham
18 |
19 |
20 |
21 | ## Minutes
22 | * Solid Process
23 | * Justin - Wasn't a negative response to issues raised with panels in https://github.com/solid/process/issues/202, so will proceed to a pull request. Will submit pull on process to propose that panels have a bit more structure (i.e. chairs)
24 |
25 | ## Community Engagement
26 |
27 | * Justin - Based on feedback, it seems that solidproject.org should provide a better perspective on what solid actually is, what is happening in solid, and how to engage in the work that's proceeding. Coming across too much like a marketing site, not tactical enough.
28 | * Sarven - Forum shouldn't be a replacement for anything, should be in addition to. Need to figure out the proper licensing.
29 | * Justin - Also a lot of feedback about it being hard to navigate all of the github repositories to know which to follow, which issues to chime in on, etc.
30 | * Sarven - Can we get people in the community to help provide and/or summarize updates for sharing (i.e. in the forum). Can we get volunteers? Can we get people to also help raise issues back to us from an editorial standpoint?
31 | * Justin - We need to raise an issue about any shortcomings on solidproject.org that keep people from understanding what's happening and how to participate.
32 |
33 | ## Heuristics Pull Request
34 | * Sarven - Heuristics Pull Request - WIP: https://github.com/solid/specification/pull/160
35 | Spotted some issues/unclarity. Will propose an update.
36 |
37 | ## Use Cases
38 |
39 | * Justin - Sharing elf Pavlik's pull at https://github.com/solid/data-interoperability-panel/pull/41
40 | * Sarven - Consider approach for this as solid-wide
41 | * Justin - Propose putting this document in solid/specification (still as an individual document)
42 | * Justin - Should also go through the editorial process
43 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Solid Specifications
2 |
3 | This repository contains the source code for the work on [Solid Technical Reports](https://solidproject.org/TR/) (TR) of the [W3C Solid Community Group](https://www.w3.org/community/solid/) (CG) to fulfill the requirements of the [Solid Project](https://solidproject.org/).
4 |
5 | The CG operates under a [Charter](https://www.w3.org/community/solid/charter/).
6 |
7 | The Technical Reports (TRs) encompass specifications, use cases and requirements, best practices and guidelines, primers, and notes about the Solid ecosystem. The CG's Work Items are linked from the TR homepage.
8 |
9 | The Solid Protocol is accessible from the following URLs:
10 | * Latest version: https://solidproject.org/TR/protocol
11 | * Persistent version 0.11.0: https://solidproject.org/TR/2024/protocol-20240512
12 | * Editor's draft: https://solidproject.org/ED/protocol
13 |
14 | ## Participation
15 |
16 | All contributors to [Work Items](https://solidproject.org/TR/#work-items) must be substantive members of the Solid CG. Joining the CG is easy; if you'd like to contribute, you can [join here](https://www.w3.org/community/solid/join). Guests are welcome but do not have voting rights.
17 |
18 | Feel free to join the [Solid specification chat](https://matrix.to/#/#solid_specification:gitter.im).
19 |
20 | Meetings are held on Wednesdays at 14:00 UTC via [this link](https://meet.jit.si/solid-cg). The meeting notes (sometimes rough summaries, sometimes detailed minutes, sometimes transcription) are [published](https://github.com/solid/specification/tree/main/meetings/). You can also find the event as well as information on Special Topic Meetings in the [W3C calendar](https://www.w3.org/events/meetings/0caa6ba5-5523-4e16-b514-aeec098e4d72).
21 |
22 | ## Contributing
23 |
24 | For detailed instructions on getting started with our project, refer to the [contributing guide](https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md).
25 |
26 | ## Code of Conduct
27 |
28 | All work and communication within the Solid CG are governed by the [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md) and the [Positive Work Environment at W3C: Code of Conduct](https://www.w3.org/policies/code-of-conduct/).
29 |
--------------------------------------------------------------------------------
/wac.timemap.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Web Access Control TimeMap
6 |
7 |
8 |
9 |
10 |
11 |
35 |
36 |
37 |
38 |
39 |
--------------------------------------------------------------------------------
/meetings/2025-07-30.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-07-30:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Chair
9 |
10 | ## Present
11 |
12 | * elf Pavlik
13 | * Erich Bremer
14 | * Ted Thibodeau Jr (he/him) (OpenLinkSw.com) // GitHub:[@TallTed](https://github.com/TallTed) // Mastodon:[@TallTed](https://mastodon.social/@TallTed)
15 | * Mahdi Baghbani
16 | * Marc Haddle
17 | * [Michal](https://id.mrkvon.org)
18 | * [Matthias Evering](https://solidweb.me/testpro/)
19 | * Jesse Wright
20 | * [Rui Zhao](https://me.ryey.icu)
21 |
22 |
23 | ## Regrets
24 |
25 |
26 | ## Scribes
27 |
28 | *
29 |
30 | ---
31 |
32 | ## Announcements
33 |
34 |
35 | ### Meeting Guidelines
36 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
37 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
38 | * 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.
39 | * Join queue to talk.
40 | * 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.
41 |
42 | ### Participation and Code of Conduct
43 | * [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/)
44 | * [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/)
45 | * 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.
46 | * If this is your first time, welcome! please introduce yourself.
47 |
48 | ---
49 |
50 | ## Introductions
51 |
52 | * Mahdi: I have been working with Michiel. I could test with test suite. I also worked on extensions for NextCloud. Open Cloud Mesh - proposal for IETF WG
53 |
54 | ## Review Action items
55 |
56 | ## Topics
57 |
58 | ## Actions
59 |
60 |
--------------------------------------------------------------------------------
/meetings/2021-06-01.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-06-01
4 |
5 | ## Present
6 |
7 | * Justin Bingham
8 | * Tim Berners-Lee
9 | * Sarven Capadisli
10 |
11 | ## Scribes
12 |
13 | - Justin Bingham
14 |
15 | ## Agenda
16 |
17 | - Pull Requests
18 | - [Add notion of owner and requirements](https://github.com/solid/specification/pull/264)
19 | - Topics
20 | - Inrupt Process for Contribution
21 | - Projected [solid spec features](https://docs.google.com/spreadsheets/d/1OyNfITZgptXD-U1DmWeW5sEW3joO9yqziriV1WRR4C8/edit?usp=sharing)
22 | - Updating solidproject.org/specification in line with [solid spec features](https://docs.google.com/spreadsheets/d/1OyNfITZgptXD-U1DmWeW5sEW3joO9yqziriV1WRR4C8/edit?usp=sharing)
23 |
24 | ## Minutes
25 |
26 | - Input: Inrupt has had a internal process to help the internal spec team speed up.
27 |
28 | - JB: +1 on more specific milestones.
29 |
30 | - TIMBL: Make each roadmap task richer
31 |
32 | - SC: Have aimed to work within the W3C process from the start. Issues are tagged appropriately. Data and process is there eg. https://github.com/solid/specification/projects/1 , https://github.com/solid/specification/milestones
33 |
34 | - SC: Need to have projected dates updated on the TR report page since the following didn't pan out:
35 | - https://gitter.im/solid/specification?at=5ff451e022f12e449b311e1f
36 | - https://gitter.im/solid/authentication-panel?at=5ff451ebacd1e516f8d4bf1e
37 | - https://gitter.im/solid/data-interoperability-panel?at=5ff451eec746c6431cf7f166
38 | - https://gitter.im/solid/authorization-panel?at=5ff451f1aa6bb528c390d53b
39 |
40 | JB: Propose using the solid spec features for milestones and identity delta - prioritize what to resolve between then and now. Use requirement tickets for features that might need additional context.
41 |
42 | Action: SC to follow-up with editors/panels etc.. on rough/hard expected dates.
43 |
44 | TIMBL: Prefer versioned specifications
45 |
46 | Action: Justin to setup weekly recurring meeting / session to work on advancing project coordination
47 |
48 | Consensus to resolve https://github.com/solid/specification/issues/8
49 | "Consensus from Editor's Meeting 2021-06-01 with present from @timbl @justinwb, @csarven and @kjetilk:
50 |
51 | The Editors prefer a versioned specification approach to allow implementers to code against a stable version."
52 |
53 | +1 JB
54 |
--------------------------------------------------------------------------------
/meetings/2021-06-22.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-06-22
4 | * Call: https://meet.jit.si/solid-specification
5 |
6 |
7 | ## Present
8 |
9 | - Tim Berners-Lee
10 | - Justin Bingham
11 | - Kjetil Kjernsmo
12 | - Sarven Capadisli
13 |
14 | ## Scribes
15 |
16 | * Sarven Capadisli
17 | * Justin Bingham
18 |
19 | ## Agenda
20 |
21 |
22 |
23 |
24 | ## Minutes
25 |
26 | KK: Do we have a gitter chat for this group only
27 | - JB +1
28 | - SC: No. No need. Keep the process open by reusing https://gitter.im/solid/specification -- can help to get more people engaged.
29 |
30 | JB: Propose prioritization at a feature / capability level, so that related issues can be tagged
31 | - Timbl +1
32 | - KK: As currently constituted it can be hard to pinpoint the specific work to be done
33 |
34 | KK: Hoping to deliver an editor's draft in next two weeks
35 | - SC: KK referring to specifically Protocol (~WD), WAC (~WD), Solid OIDC (~FPWD). None are set as CG's goal besides "expected completion" set in https://solidproject.org/TR/ (which did not have wide consensus apparently.)
36 |
37 | SC: In these meetings the focus should be community group, with input from implementors
38 |
39 | SC: Solid-OIDC could be a FPWD (roughly)
40 |
41 | SC: WAC needs to be PR'd against the specification repo as a working draft. Should identify implementations, and ideally show test reports, if possible (can be taken into consideration at PR).
42 |
43 | TBL: Protocol is behind, and needs to be prioritized to get done / complete.
44 | - SC: Sure. Realistic in ~3 weeks? Who is working on what?
45 |
46 | JB: What is the delta on protocol to FPWD?
47 |
48 | JB: What is the bar to reference something (like secure websockets) from the protocol draft? (private implementation, open implementation, design draft? specification draft?)
49 |
50 | Timbl: Secure Websockets is top priority (regression + security issue).
51 |
52 | SC: Things mentioned from the "Solid spec features" are those that could be referenced from the protocol spec with a relatively low-bar.
53 |
54 | Timbl: At-Risk means all-hands on deck (ship is leaking - patch the leak)
55 |
56 | JB: Proposed action items:
57 | - Get implemetors of secure websocket to brief sub-group of editors with walkthrough of secure websocket design (JB))
58 | - Figure out of the issues tagged at FPWD are the delta of issues to be resolved for the protocol (KK)
59 |
60 | KK: Need to incorporate the Kanban board into this cycle
61 |
62 |
63 |
--------------------------------------------------------------------------------
/meetings/2021-06-29.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-06-29
4 |
5 | ## Present
6 |
7 | - Justin Bingham
8 | - Kjetil Kjernsmo
9 | - Ruben Verborgh
10 | - Tim Berners-Lee
11 |
12 | ## Scribes
13 |
14 | * Sarven Capadisli
15 | * Justin Bingham
16 |
17 | ## Minutes
18 |
19 | JB: Where to store these minutes? Propose using same github workflow as panels. +1 KK
20 |
21 | Action Item: Pick which repo to store minutes in GH
22 |
23 | KK: Have open PRs, but also need to do some more issue prioritization
24 |
25 | JB: Also need to provide more guidance on copyright / contributors.
26 |
27 | KK: Items to triage
28 | * SPARQL-Update
29 | * Ownership
30 | * Secure Websockets
31 | * Server-managed metadata
32 |
33 |
34 | ### Secure Websockets
35 |
36 | JB: Noting that we have had progress with Secure Websockets, see branch submitted at https://github.com/solid/specification/tree/feature/notification-protocol-data-flows,
37 | https://github.com/solid/specification/pull/271
38 |
39 | JB: Protocol / Pattern that can be implemented by different channel types (e.g. websocket, sse)
40 |
41 | KK: Lets put into the assessment phase for now. +1 JB
42 |
43 | KK: Need to have issues to more thoroughly prioritize / review. +1 JB
44 |
45 | TIMBL: Public implementation available?
46 |
47 | KK: Is there an issue we can use as the main point for this?
48 |
49 | JB: There are a number of relevant issues at: https://github.com/solid/specification/issues?q=is%3Aissue+is%3Aopen+websocket+label%3A%22topic%3A+events+and+notifications%22. Probably best to make a new one, and then reference.
50 |
51 | JB: Will take action to create issue in solid/specification to track
52 |
53 | KK: Should we make a new project board, or only have a milestone?
54 |
55 | JB: Current project board columns are close to the editorial phases (what about updating to match)?
56 | +1 KK, +1 JB, +1 TIMBL
57 |
58 | KK: Should we then have a milestone for the current month?
59 | +1 JB (also prioritize cards to the top)
60 |
61 | Action Items:
62 | - Determine github repo/location for meeting minutes (all editors)
63 | - Update columns in solid/specification to reflect editorial phases (from latest process) (KK)
64 | - Tag monthly items with a "current month" milestone (KK)
65 | - Move items for this month into that milestone (KK)
66 | - Identify and/or create reference issue for secure websocket to be tracked (JB)
67 | - Review proposed websocket doc (all editors)
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
--------------------------------------------------------------------------------
/meetings/2021-01-04.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-09-04
4 | * Call: https://meet.jit.si/solid-specification
5 |
6 | ## Present
7 |
8 | - Justin Bingham
9 | - Sarven Capadisli
10 | - Ruben Verborgh
11 | - Dmitri Zagidulin
12 | - Tim Berners-Lee
13 |
14 | ## Scribes
15 |
16 | - Justin Bingham
17 |
18 | ## Agenda
19 |
20 | - Recap of activity since last session
21 | - SC: Justin, can we make solidproject.org/TR/ available soon? Otherwise, I'll have apply for Admin ;)
22 | - https://solid.github.io/specification/protocol
23 | - Goals and milestones for 2021
24 | - https://solid.github.io/specification/#work-items - proposed (Sarven)
25 | - Editors of sub-specs (e.g. Solid-OIDC)
26 | - Solid Process/vocab management: https://github.com/solid/process/pull/247 (Tim to review)
27 | - SC: Tim, please review soonish? :) I have a follow-up PR for solid/vocab
28 | - Check/reminder about the websockets spec
29 | - Question if it makes sense to resurrect https://github.com/solid/identity-panel/issues/1 in the /specification repo
30 | - SC: Dmitri, quick feedback: can we get some uptake (implementation) in the community before raising its profile
31 | - DZ: Yep, sounds good. I think my main question is - is there any interest or objection within this team.
32 | - SC: No objection.. but need to understand how it fits with Solid-OIDC etc.. did-web
33 | - CORS proxy (Tim brought this up)
34 |
35 | ## Minutes
36 |
37 | - JB: Action item: Delete and resend meeting series with jitsi link
38 | - SC: update protocol:
39 | - abstract (why, what's core)
40 | - add conformance (exit) criteria
41 | - add current state of websocket req
42 | - TBL: Websocket is part of the spec
43 | - SC: Prefer not to refer back to prior documents
44 | - JB: Can we mention or point to the in-flight websocket work in the meantime and mention that it is happening but not ready
45 | - TBL: Provide more detail on patching (generally), and on the details of patching via websocket (add as goal)
46 | - TBL: Reasonable to put in a placeholder for ACP / Authorization Use Cases as additional work in progress
47 | - SC: Concerned about pointing to ACP ahead of use cases and requirements
48 | - JB: Propose linking to authorization requirements / use cases at a minimum
49 | - SC: wait until agreed solution is available before including in Protocol
50 | - JB: Action Item to get specs under solidproject.org/TR
51 | - JB: Can we use something like solid:pod instead of pim:storage? Timbl - reasonable question
52 | - SC: create internationalization issue for solid/terms, pim/space..
53 |
--------------------------------------------------------------------------------
/meetings/2025-07-16.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-07-16T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Chair
9 | * elf Pavlik
10 |
11 | ## Present
12 |
13 | * Hadrian Zbarcea
14 | * [Matthias Evering](https://solidweb.me/testpro/)
15 | * Marc Haddle
16 | * Erich Bremer
17 | * Jesse Wright
18 | * Rui Zhao (constantly losing connection due to issues on my side)
19 |
20 | ## Regrets
21 |
22 |
23 | ## Scribes
24 |
25 | * teamwork
26 |
27 | ---
28 |
29 | ## Announcements
30 |
31 | ME: can share paypal subscription experiment (adoption) offering teamid.live (https://www.serverproject.de/solid/main.php)
32 |
33 | ### Meeting Guidelines
34 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
35 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
36 | * 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.
37 | * Join queue to talk.
38 | * 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.
39 |
40 | ### Participation and Code of Conduct
41 | * [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/)
42 | * [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/)
43 | * 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.
44 | * If this is your first time, welcome! please introduce yourself.
45 |
46 | ---
47 |
48 | ## Review Action items
49 |
50 | ## Topics
51 |
52 |
53 | ## Actions
54 |
55 | * eP: reach out to community to find interest in applying for a grant to maintain the test suite
56 | * HZ: reach out to Laurin, Graphmetrix and community to find interest for a local-first/also-local archiving format
57 | * eP: start pad to gather ideas on ongoing relation with NLnet
58 | * test suite and implementations
59 | * deployment, maybe nix based scripts
60 | * working with existing successfull OS - discourse, ofn, gitlab ...
61 |
--------------------------------------------------------------------------------
/meetings/2020-04-08.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-04-08
4 | * Duration: 90 minutes
5 | * Purpose: Meeting on Solid specifications; status, editorial
6 | * Call: https://global.gotomeeting.com/join/433028037
7 | * Chat: https://gitter.im/solid/specification
8 |
9 | ## Present
10 |
11 | * Sarven Capadisli
12 | * Justin Bingham
13 | * Ruben Verborgh
14 | * Tim Berners-Lee
15 | * Eric Prud'hommeaux
16 |
17 | ## Scribes
18 |
19 | * Sarven Capadisli
20 |
21 |
22 | ## Agenda
23 |
24 | * Status update on work in progress eg. https://github.com/solid/specification/projects/1
25 | * Some rough consensus items: https://github.com/solid/specification/pull/157
26 | * Auxiliary Resources: https://github.com/solid/specification/pull/156
27 | * Straw poll for WebSocket support (authn/z, format..)
28 |
29 | ## Minutes
30 |
31 | * JB: where are we going with ~FPWD? who is roughly doing what? how should we approach delivering ~FPWD?
32 | * JB: ''going through https://solid.github.io/specification/ (based on master branch as of 2020-04-08)''
33 | * TBL: Make sure to keep server-client and client/app specific sections separate
34 | * RV: Agreed; that was the intention of the current sectioning
35 | * SC: There won't be a section on LDP, only borrow some requirements.
36 | * RV: Problem already might be shapes, given that there is now discussion about server-side validation as well
37 | * JB: Shall we split the document completely in two documents? (client–server , client–client)
38 | * SC: server-server was discussed in the past (not ruled out but not focused to date)
39 | * TBL: Refer to Client-Server as Solid Protocol
40 | * RV: I'm all for splitting, with the following caveats:
41 | * there might also be server–server interactions
42 | * split between server–client and client–client might evolve, as some client–client features start exhibiting server-side behavior as well (Justin +1)
43 | * JB: priority is getting Solid Protocol out
44 | * SC : Can we focus on requirements agreed on for the FPWD? Omit sections without discussion, implementations..
45 | * TBL: Propose to separate out client/server (protocol) and client/client. Maintain ecosystem document pointing to them.
46 | * SC: naming, and paths.... solid/ /TR/... Issue:
47 | * TBL: Provisional decision - keep on github.io for now and then move to solidproject.org/specs
48 | * SC: Can we live without Bikeshed (and just worship the goodness of plain HTML?)
49 | * JB: Propose several more sessions over the coming weeks focused on cementing key elements for Solid Protocol
50 | * SC: WebSocket something something..
51 | * JB: Let's include websockets / notifications on next agenda
52 |
--------------------------------------------------------------------------------
/meetings/2021-08-10.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-08-10
4 |
5 | ## Present
6 |
7 | - Justin Bingham
8 | - Sarven Capadisli
9 | - Ruben Verborgh
10 | - Kjetil Kjernsmo
11 |
12 | ## Scribes
13 | - Justin Bingham
14 | - Kjetil Kjernsmo
15 |
16 | ## Agenda
17 |
18 | - Notifications Update
19 | - Solid Editor's Role in addressing old technology
20 | - [Current Month Milestone](https://github.com/solid/specification/milestone/4)
21 |
22 | ## Minutes
23 |
24 | ### Notifications Updates
25 |
26 | JB: Making progress in getting implementers brought together to put together an action plan to deliver spec + supporting implementations as part of panel initiative.
27 |
28 | RV: Had a task to gather more information on what inrupt shared. Have got that material. Not a lot of information just yet.
29 | - Missing: proper req engineering (doc with some key requirements)
30 | - Questions: why is every message a json-ld blob? those kind of questions have to be answered
31 | - Versioning is missing as well. If versioning is defined then it makes it more possible to implement a draft and then upgrade.
32 | - Need some more reasons about why it works.
33 | - Not in spec ready format yet
34 |
35 | SC:
36 |
37 | ### Solid Editor's Role in addressing old technology
38 |
39 | KK: Was meeting on addressing how we ensure older and/or legacy items don't hinder solid's forward progress. Is a role for implementers to voice opinion on what is/isn't sustainable, and for editors to provide more insight on what should/shouldn't be supported.
40 |
41 | SC: Need to be sure to cite and/or record issues / minutes.
42 |
43 | JB: Current spec document is pretty explicit that Solid-OIDC (linked to latest draft) is what is required for the compliant protocol. Not so much a spec problem, as much as how we communicate to the community what is / isn't compliant.
44 |
45 | SC: Since starting point for the new spec has been Solid-OIDC, it may not be appropriate in the document to say "don't use WebID-OIDC" because it never existed in the document. Have to look at other mediums for awareness / communication.
46 | - Ensure that any test-suite is marking WebID-OIDC as deprecated
47 | - Ensure that community members know that WebID-OIDC shouldn't be part of solutions / approaches
48 |
49 | JB: What are mediums that we can use to provide some of these "editorial advisements"? Should we be using the community group mailing list? Forum? Blog posts on solidproject.org?
50 |
51 | ### Action Items
52 |
53 | - Ruben to do another follow-up on Inrupt's shared notifications proposal
54 | - Justin to continue working on notification panel initiation / participant support
55 |
--------------------------------------------------------------------------------
/meetings/2021-05-04.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-05-04
4 |
5 | ## Present
6 |
7 | - Sarven Capadisli
8 | - Tim Berners-Lee
9 | - Justin Bingham
10 | - Ruben Verborgh
11 | - Kjetil Kjernsmo
12 |
13 | ## Scribes
14 |
15 | - Kjetil Kjernsmo
16 | - Justin Bingham
17 |
18 | ## Agenda
19 |
20 | - Specification Features / Versioning - See [minutes from last session](https://hackmd.io/-0FgJSKtQMqiPuZczbVs4A)
21 | - Open issue: https://github.com/solid/specification/issues/8
22 |
23 | ## Minutes
24 |
25 | ### WAC / ACP
26 |
27 | JB: ACP draft is getting close, we need to make sure that we have a plan for how to incorporate into spec
28 |
29 | TBL: Is there a core (minimum) plus extensions
30 |
31 | JB: definitely a core, can't speak to extensions yet. likely would be in additional matchers (like time based)
32 |
33 | ### WAC / Ownership
34 |
35 | TBL: Every server has to keep track of the owner of the pod in an implementation defined way. Owner is first set at pod provisioning time. Owner should get implicit control access on everything in the pod.
36 |
37 | RV: Will implement in CSS: https://github.com/solid/community-server/issues/720
38 |
39 | SC: If the server keeps track of who the owner is, it bypasses the ACL fully.
40 |
41 | SC: Different than how a client can find the owner (acl:owner). When a client wants to find the owner of a pim:Storage, it looks for the acl:owner Link relation at the root (/) of the pod
42 |
43 | SC: Should we have a solid:owner property for protocol wide?
44 | * +1 JB, +1 RV, +1 TBL, +1 SC, +1 KK
45 | * acl:owner subPropertyOf solid:owner?
46 | * Sarven to eventually PR to solid/vocab
47 | * acl:owner rdfs:comment "The person or other agent which owns this.\n For example, the owner of a file in a filesystem.\n There is a sense of right to control. Typically defaults to the agent who craeted\n something but can be changed."
48 |
49 |
50 | JB: Do we have the same issue on the resource level where someone is provisioned a slice of a pod (e.g. like their home directory in a single pod). Should we have solid:resourceOwner?
51 |
52 | SC: dcterms:creator type of property for initial creator.. provenance record
53 |
54 | JB: +1 that owner and creator should be separate. A bot might provision some resources and be the creator, but the agent it is provisioned for would be the owner.
55 |
56 | JB: Implementation seem to disagree about whether describedBy should be used only for containers / binaries or for all resources.
57 |
58 | SC: Need to firmly work out lifecycle of auxiliary resources (e.g. should they always be removed on primary resource delete).
59 |
60 | SC/TBL: WAC-Allow
61 |
--------------------------------------------------------------------------------
/meetings/2023-02-22.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2023-02-22T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://gitter.im/solid/specification
6 | * Repository: https://github.com/solid/specification
7 | * Status: Published
8 |
9 | ## Present
10 | * [Sarven Capadisli](https://csarven.ca/#i)
11 | * [Virginia Balseiro](https://virginiabalseiro.com/#me)
12 | * [Ted Thibodeau](https://github.com/TallTed/) (he/him) (OpenLinkSw.com)
13 |
14 | ---
15 |
16 | ## Announcements
17 |
18 | ### Meeting Guidelines
19 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
20 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/solid/specification/blob/main/meetings/README.md).
21 | * 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.
22 | * Join queue to talk.
23 | * 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.
24 |
25 |
26 | ### Participation and Code of Conduct
27 | * [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/)
28 | * [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/)
29 | * 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.
30 | * If this is your first time, welcome! please introduce yourself.
31 |
32 |
33 | ### Scribes
34 | * Sarven Capadisli
35 |
36 | ### Introductions
37 | * name: text
38 |
39 | ---
40 |
41 |
42 | ## Topics
43 |
44 | * SC: Lacking quorum, we had a wide ranging conversation that included a number of Solid-related and Solid-tangential topics. Much food for thought, but not easily captured for minutes.
45 | * SC: Only the topic on milestone 0.11.0 was taken up from the original agenda while acknowledging open PRs related to milestone 0.10.0.
46 |
47 | ### Add TR/2022/notifications-protocol-20221231
48 | URL: https://github.com/solid/specification/pull/491
49 |
50 | ### Add TR/2022/protocol-20221231
51 | URL: https://github.com/solid/specification/pull/492
52 |
53 |
54 | ### Milestone 0.11.0
55 | URL: https://github.com/solid/specification/milestone/7
56 |
57 | * SC: Tentative due date: 2023-04-30.
58 |
--------------------------------------------------------------------------------
/2022/acp-main-20220518.css:
--------------------------------------------------------------------------------
1 | :root {
2 | --lightest-yellow: hsl(47, 100%, 97%);
3 | --lighter-yellow: hsl(47, 100%, 87%);
4 | --light-yellow: hsl(47, 100%, 77%);
5 | --light-green: #b6fdad;
6 | --light-red: #ffdede;
7 | }
8 |
9 | h1 {
10 | font-size: 220%;
11 | font-weight: bold;
12 | margin: 0 0 .1em;
13 | }
14 |
15 | header {
16 | border-bottom: 1px solid;
17 | }
18 |
19 | header li {
20 | margin: 0;
21 | }
22 |
23 | dl dd {
24 | margin: 0 0 .5em 2em;
25 | }
26 |
27 | dd ul {
28 | padding: 0;
29 | }
30 |
31 | dd li {
32 | list-style: none;
33 | }
34 |
35 | table {
36 | border-collapse: collapse;
37 | border-color: #000000;
38 | }
39 |
40 | td,
41 | th {
42 | border-width: 1px;
43 | border-style: solid;
44 | padding: 0.4em 0.6em;
45 | }
46 |
47 | .bibref::before {
48 | content: "[";
49 | }
50 |
51 | .bibref::after {
52 | content: "]";
53 | }
54 |
55 | .heading {
56 | position: relative;
57 | }
58 |
59 | .self-link {
60 | border: none;
61 | font-size: 83%;
62 | height: 2em;
63 | left: calc(-1 * (3.5rem - 26px));
64 | opacity: .5;
65 | position: absolute;
66 | text-align: center;
67 | top: 0;
68 | transition: opacity .2s;
69 | width: calc(3.5rem - 26px);
70 | }
71 |
72 | .self-link:hover {
73 | opacity: 1;
74 | }
75 |
76 | .self-link::before {
77 | content: "§";
78 | }
79 |
80 | .rfc2119 {
81 | text-transform: lowercase;
82 | font-style: normal;
83 | color: #900;
84 | }
85 |
86 | .example,
87 | .pseudocode {
88 | border: 1px solid #999;
89 | margin-left: 0;
90 | margin-top: 1.5em;
91 | padding: 2em;
92 | }
93 |
94 | .example::before, .pseudocode::before {
95 | background: white;
96 | border: 1px solid #bbb;
97 | color: #666;
98 | display: block;
99 | font-family: sans-serif;
100 | margin: -2em 0 1em -2em;
101 | padding: 0.2em 2em;
102 | text-transform: none;
103 | width: 14em;
104 | }
105 |
106 | .pseudocode::before {
107 | content: "Example JavaScript code";
108 | }
109 |
110 | .example-context-graph {
111 | background-color: var(--lightest-yellow);
112 | }
113 |
114 | .example-context-graph::before {
115 | content: "Example context graph";
116 | }
117 |
118 | .example-authorization-graph {
119 | background-color: var(--lighter-yellow);
120 | }
121 |
122 | .example-authorization-graph::before {
123 | content: "Example authorization graph";
124 | }
125 |
126 | .example-access-grant-graph {
127 | background-color: var(--light-yellow);
128 | }
129 |
130 | .example-access-grant-graph::before {
131 | content: "Example access grant graph";
132 | }
133 |
134 | .example-well-known::before {
135 | content: "Example well known configuration";
136 | }
137 |
--------------------------------------------------------------------------------
/meetings/2021-04-22.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-04-22
4 |
5 | ## Present
6 |
7 | * Justin Bingham
8 | * Tim Berners-Lee
9 | * Ruben Verborgh
10 |
11 | ## Scribes
12 |
13 | * Justin Bingham
14 |
15 | ## Minutes
16 |
17 | JB: Goal for this session?
18 |
19 | TBL: Ensure functionality at each level is well understood and specified. The spreadsheet should provide clear history of features and what's available in past versions, current, coming soon.
20 |
21 | JB: What's the scheme for versioning?
22 |
23 | TBL: Important to make snapshots of the spec, and not have it be a totally living document. Don't have to do it very often, but it needs to happen at key times.
24 |
25 | RV: How to avoid not becoming too messy? How do we deal with it from an implementer perspective? How to advertise what's implemented? What are consequences of indicating issues / risks with past versions.
26 |
27 | TBL: Should be able to go to .well-known and get the version.
28 |
29 | RV: If servers advertise their version, it could help with understanding feature support levels, etc.
30 |
31 | TBL: Client software could actually identify whether something is insecure.
32 |
33 | RV: Need a versioning spec / process.
34 |
35 | JB: +1 on server advertising version for interop.
36 |
37 | JB: What is our version now?
38 |
39 | TBL: Not using SemVer for pre-1.0
40 |
41 | RV: Could even be date-based - to avoid version numbering
42 |
43 | TBL: E.G. Solid 2020
44 |
45 | RV: Benefits of Semver? E.G. Taking advantage of built-in semantics for programmatic scenarios
46 |
47 | JB: Paper on RDF / SemVer - https://www.researchgate.net/publication/228716298_Semversion_A_versioning_system_for_RDF_and_ontologies
48 |
49 | *[TB waves]*
50 |
51 | JB: with shapes you need best pracxtices about back compat with shapes.
52 |
53 | TB: Propose in the
54 |
55 | JB: Does the spreadsheet provide a good representative list at this point?
56 |
57 | RV: High level yes - but needs some more detail. Especially with version estimates. Also should try to get expectation of when (for things that are changing / getting added). What is the minimum version that should be provided by a server to be minimum solid? What about versioning the whole ecosystem?
58 |
59 | KK: Coming back up to speed - don't have full context - but need more about conditional requests and caching and that should be addressed.
60 |
61 | TBL: Past solid we didn't use ETags
62 |
63 | KK: Use RFC references and point to those
64 |
65 | KK: Should we include VC?
66 |
67 | JB: May not require server support for certain use cases (like signing / verifiable data)
68 |
69 | TBL: Use cases for authn/authz probably will
70 |
71 | TBL: Lots of things that aren't on here (i.e. Conneg) - maybe should do another round (at least offline)
72 |
--------------------------------------------------------------------------------
/meetings/2025-10-22.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-10-22T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Repository: https://github.com/solid/specification
6 |
7 | ## Chair
8 |
9 | * Hadrian
10 |
11 | ## Present
12 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
13 | * Tom Byrd
14 | * Theo
15 | * TimBL
16 | * Erich Bremer
17 |
18 | ## Regrets
19 |
20 | * Ted Thibodeau (conflicting W3C groups meetings)
21 |
22 | ## Scribes
23 |
24 |
25 | ---
26 |
27 | ## Announcements
28 |
29 | ### Meeting Guidelines
30 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
31 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
32 | * 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.
33 | * Join queue to talk.
34 | * 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.
35 |
36 | ### Participation and Code of Conduct
37 | * [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/)
38 | * [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/)
39 | * 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.
40 | * If this is your first time, welcome! please introduce yourself.
41 |
42 | ---
43 |
44 |
45 | ## Introductions
46 |
47 |
48 | ## Review Action items
49 |
50 | eP: ✅ reach out to Ruben about the name changes, then change the [11 issue names](https://github.com/solid/specification/issues?q=is%3Aissue%20state%3Aopen%20%5BUse%20of%20copyrighted%20material%20without%20permission%20or%20consent%5D) back.
51 |
52 | ## Topics
53 |
54 | ### Pull Requests
55 |
56 | ### Tracking obstacles
57 |
58 | ### Mallory (update)
59 |
60 | https://github.com/solid/solidcommunity.net/issues/85#issuecomment-3416118521
61 |
62 | * eP: I'm preparing another simple demo, this time focused on exploiting case of someone hosting their WebID document inside of their solid storage
63 | * eP: first demo - https://cuckoo.mallory.monster/
64 | * eP: second demo - https://rimraf.mallory.monster/
65 | * EB: solid did link?
66 | * eP: https://github.com/solid/did-method-solid
67 |
68 | ## Actions
69 |
70 | * HZ: to organize session about DIDs in Solid
71 |
--------------------------------------------------------------------------------
/meetings/2025-10-08.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-10-08: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 | * Tom Byrd
13 | * [Luke Dary](https://w3c.social/@lukedary)
14 | * [Michal](https://id.mrkvon.org) (late)
15 |
16 | ## Regrets
17 |
18 |
19 | ## Scribes
20 |
21 |
22 | ---
23 |
24 | ## Announcements
25 |
26 | ### Meeting Guidelines
27 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
28 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
29 | * 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.
30 | * Join queue to talk.
31 | * 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.
32 |
33 | ### Participation and Code of Conduct
34 | * [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/)
35 | * [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/)
36 | * 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.
37 | * If this is your first time, welcome! please introduce yourself.
38 |
39 | ---
40 |
41 |
42 | ## Introductions
43 |
44 |
45 | ## Review Action items
46 |
47 |
48 | ## Topics
49 |
50 | ### Pull Requests
51 |
52 | ### Tracking obstacles
53 |
54 | ### Demo: mallory toolkit
55 |
56 | https://elf-pavlik.github.io/mallory/rimraf/
57 |
58 | * eP: Very early seed of a toolkit to prototype malicious Solid apps and demonstrate well known vulnerabilities. Link after the demo
59 | * eP: MdJ demo of ACP app permissioning https://youtu.be/5Q1nUmGdaXE
60 |
61 | 
62 |
63 | * LD: Auth screen can communicate risks better. Server responding to that request should protect user. It should take a negative look at what could be bad about it. If you don't want them to do that, create another pod.
64 | * eP: Next week I can show https://sai.js.org auth screen. A very early wireframe is also available in https://solid.github.io/data-interoperability-panel/primer/authorization-agent.html#gathering-authorizations
65 |
66 | ## Actions
67 |
68 |
--------------------------------------------------------------------------------
/meetings/2023-02-08.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2023-02-08T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://gitter.im/solid/specification
6 | * Repository: https://github.com/solid/specification
7 | * Status: Published
8 |
9 | ## Present
10 | * [Virginia Balseiro](https://virginiabalseiro.com/#me)
11 | * [Matthias Evering](https://solidweb.me/testpro/)
12 | * [Arthur Joppart](https://github.com/belgiannoise)
13 | * elf Pavlik
14 | * [Henry Story](https://bblfish.net/)
15 | * Brian Dowtin (North Carolina A&T State University)
16 |
17 | ---
18 |
19 | ## Announcements
20 |
21 | ### Meeting Guidelines
22 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
23 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/solid/specification/blob/main/meetings/README.md).
24 | * 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.
25 | * Join queue to talk.
26 | * 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.
27 |
28 |
29 | ### Participation and Code of Conduct
30 | * [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/)
31 | * [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/)
32 | * 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.
33 | * If this is your first time, welcome! please introduce yourself.
34 |
35 |
36 | ### Scribes
37 | * elf Pavlik
38 |
39 | ### Introductions
40 | * Brian: Second time joining. PhD candidate at ???. Working with a group who does network reasearch using WebID.
41 |
42 | ---
43 |
44 |
45 | ## Topics
46 |
47 | * SC: Plethora of items to contribute to, e.g., see project board or open PRs or any open issue. Once again, we are not short on ideas/considerations.
48 |
49 | ### Project Board
50 | URL: https://github.com/orgs/solid/projects/15
51 |
52 |
53 | ### PRs
54 | URL: https://github.com/solid/specification/pulls
55 |
56 |
57 | ### WIP Implementation Feedback
58 | * SC: This is a running topic in notifications-panel that we can try here.
59 | * SC: We'll allocate some time for implementation feedback. Links to servers/applications and demos welcome.
60 |
61 |
62 | ---
63 |
64 | ### Topic Proposal
65 | URL:
66 |
67 | * Proposed by [name]
68 |
--------------------------------------------------------------------------------
/meetings/2025-07-02.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-07-02T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Chair
9 | * Michiel de Jong
10 |
11 | ## Present
12 |
13 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
14 | * Tom Byrd
15 | * Hadrian Zbarcea
16 | * Marc Haddle
17 | * Ted Thibodeau Jr (he/him) // [GitHub:@TallTed](https://github.com/TallTed) // [mastodon:@TallTed](https://mastodon.social/@TallTed) (OpenLinkSw.com)
18 | * elfPavlik
19 | * Rui Zhao
20 |
21 | ## Regrets
22 |
23 |
24 | ## Scribes
25 |
26 |
27 | ---
28 |
29 | ## Announcements
30 |
31 | ### Meeting Guidelines
32 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
33 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
34 | * 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.
35 | * Join queue to talk.
36 | * 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.
37 |
38 | ### Participation and Code of Conduct
39 | * [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/)
40 | * [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/)
41 | * 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.
42 | * If this is your first time, welcome! please introduce yourself.
43 |
44 | ---
45 |
46 | ## Review Action items
47 |
48 | ## Topics
49 |
50 | ### initial drafts of principles and framework for proposals
51 |
52 | https://github.com/w3c-cg/solid/pull/22
53 |
54 | * MdJ: any objections?
55 | * ...: hearing none, merging.
56 |
57 |
58 | ### feat: URL client id for client credentials
59 |
60 | https://github.com/CommunitySolidServer/CommunitySolidServer/pull/2041
61 | https://www.rfc-editor.org/rfc/rfc7521.html
62 | https://github.com/solidcouch/solid-identity
63 |
64 | We had a free-form discussion, mostly between Pavlik, Michiel and Rui, about https://communitysolidserver.github.io/CommunitySolidServer/7.x/usage/client-credentials/#generating-a-token
65 |
66 | Tom mentoined he would like to add this topic to the agenda for a future CG call and Rui said he would like that too.
67 |
68 | ## Actions
69 |
--------------------------------------------------------------------------------
/meetings/2025-06-04.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-06-04T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Present
9 |
10 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
11 | * Jeff Zucker
12 | * Jesse Wright
13 | * Marc
14 | * [Erich Bremer](https://ebremer.com)
15 |
16 | ## Regrets
17 | ---
18 |
19 | ## Announcements
20 |
21 | ### Meeting Guidelines
22 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
23 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
24 | * 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.
25 | * Join queue to talk.
26 | * 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.
27 |
28 | ### Participation and Code of Conduct
29 | * [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/)
30 | * [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/)
31 | * 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.
32 | * If this is your first time, welcome! please introduce yourself.
33 |
34 | ### Scribes
35 | * failed test of https://fireflies.ai/
36 |
37 | ---
38 |
39 | ## Topics
40 |
41 | ### Update for Solid World
42 | https://theodi.org/news-and-events/events/solid-world-june-2025/
43 |
44 | * eP: I will give ~3min upate from CG
45 |
46 | ### Test Suites
47 | https://github.com/solid-contrib/specification-tests
48 |
49 | * eP: I'm working on adding tests for SAI and have a couple of questions about status of this work item
50 |
51 | ### Consistent actors and scenarios across use cases, snippets and test suite
52 | https://github.com/w3c/lws-ucs/issues/158
53 |
54 | * eP: Coordinating with LWS WG
55 |
56 | ### Solid Catalog - shapes for specs and software implementing it
57 | https://github.com/solid/catalog/issues/18
58 | https://github.com/solid/catalog/pull/19
59 |
60 | * eP: Feedback is welcome
61 |
62 |
63 | ### [JW] Providing Lightweight infrastructure for publishing Vocabs
64 | (contined from last week)
65 |
66 | ### [JW] Vocabs, Ontologies and Shapes (background for above discussions)
67 | (contined from last week)
68 |
69 | ### [JW] Schema alignment best practises
70 |
--------------------------------------------------------------------------------
/meetings/2020-05-15.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-05-15
4 | * Duration: 90 minutes
5 | * Purpose: Meeting on Solid specifications; status, editorial
6 | * Call: https://meet.zrh.init7.net/solid-specification
7 | * Chat: https://gitter.im/solid/specification
8 |
9 | ## Present
10 |
11 | * Justin Bingham
12 | * Sarven Capadisli
13 | * Ruben Verborgh
14 | * Dmitri Zagidulin
15 | * Tim Berners-Lee
16 |
17 | ## Scribes
18 | * Sarven Capadisli
19 |
20 |
21 | ## Agenda
22 |
23 | ### Status update on work in progress
24 | * PRs..
25 | * License (https://github.com/solid/specification/pull/89) (using MIT license, licensor W3C Solid CG)
26 | * WebID-TLS https://github.com/solid/specification/pull/140 (postponned to spec restructuring)
27 | * Effective request URI for POST https://github.com/solid/specification/pull/160 (near merge)
28 | ### Server managed metadata
29 | ## Panels and contribution
30 |
31 | ## Minutes
32 |
33 | * JB: Auxiliary resource received approval, merged into the editor’s draft - https://github.com/solid/specification/pull/156
34 |
35 | * SC: Resource access submission related to containment, shared slash, and URI persistence went through - https://github.com/solid/specification/pull/157
36 |
37 | * SC: Heuristic to determine resource type on post - https://github.com/solid/specification/pull/160
38 | * TBL: Issues with Slug
39 | * DZ: We should focus more on creating resource with PUT
40 | * TBL: Phase using Slug out
41 | * SC: Agree we shouldn't have to rely on Slug
42 | Related to issue: https://github.com/solid/specification/issues/128#issuecomment-573033297
43 | * TBL: Propose that we should favor deterministic language, as opposed to making support for Slug behavior confusing to clients
44 |
45 | * SC: Revision currently in the works is in line with editorial feedback
46 |
47 | * SC: License (https://github.com/solid/specification/pull/89) (using MIT license, licensor W3C Solid CG)
48 | * TBL: MIT License is important - check with W3C for specifics
49 |
50 | * JB - Server Managed metadata - Proposal for basic information, extended information
51 | * TBL: Basic provenance, Extended history may be flagged for future work. Consider an overlap with git.
52 | * DZ: Third type - Access logs - who viewed/accessed - TIMBL +1, JB +1
53 | * JB: We'll make use cases in interop panel and propose text
54 | * SC: Put a condition on this - don't bundle all discovery into one server managed resource. Look at PROV-O. JB +1
55 |
56 | ## Panels and Contribution
57 | * TBL: Panels should be moving through things crisply and get them better defined. Chair could move things along. Chair represents the group, and is responsible for process, focus, action items.
58 | * RV: Initial mistake was to launch too many of them. Too much parallelization
59 | * RV: Important issue - text not evolving enough. Positive change is that we're seeing more text getting generated.
60 | * TBL: Reason is for us to make a more quality spec.
61 |
--------------------------------------------------------------------------------
/meetings/2025-11-12.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-11-12T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Repository: https://github.com/solid/specification
6 |
7 | ## Chair
8 |
9 | * Hadrian/elf Pavlik
10 |
11 | ## Present
12 |
13 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
14 | * [Luke Dary](https://w3c.social/@lukedary)
15 | * [Melvin Carvalho](https://melvincarvalho.com/#me)
16 | * Alain Bourgeois
17 | * John Kirkwood
18 | * Marc Haddle
19 | * Rui Zhao
20 |
21 | ## Regrets
22 |
23 | ## Scribes
24 |
25 |
26 | ---
27 |
28 | ## Announcements
29 |
30 | ### Meeting Guidelines
31 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
32 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
33 | * 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.
34 | * Join queue to talk.
35 | * 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.
36 |
37 | ### Participation and Code of Conduct
38 | * [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/)
39 | * [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/)
40 | * 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.
41 | * If this is your first time, welcome! please introduce yourself.
42 |
43 | ---
44 |
45 |
46 | ## Introductions
47 |
48 | ## Review Action items
49 | * eP: ✅ send out the call for nominations for the chair elections
50 |
51 | ## Topics
52 |
53 | ### Pull Requests
54 |
55 | ### Tracking obstacles
56 |
57 | ### Solid World - CG upadte
58 |
59 | * eP: we need to confirm who will share the update and prepare 1-2 slides
60 |
61 | ### CG chair election
62 | https://lists.w3.org/Archives/Public/public-solid/2025Nov/0000.html
63 |
64 | ### Changing repo for CG meeting minutes
65 | https://github.com/w3c-cg/solid/issues/25
66 |
67 | ### Alain: update to NSS and Rdflib
68 | - working on adding webid scope and claim => solid-oidc compliant now. Can be tested on https://solid-contrib.github.io/solid-oidc-tests/ with NSS test server https://pivot-test.solidproject.org:8443 (I know the server name is not nice)
69 | - rdflib issue on dot included in terms : waiting for review https://github.com/linkeddata/rdflib.js/pull/718
70 | * MC: I'm an owner of linkeddata github group so I can help with changing access if needed.
71 |
72 | ## Actions
73 |
--------------------------------------------------------------------------------
/meetings/2022-02-02.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2022-02-02T14:00:00Z
4 | * Call: https://meet.jit.si/solid-specification
5 | * Chat: https://gitter.im/solid/specification
6 | * Repository: https://github.com/solid/specification
7 |
8 |
9 | ## Present
10 | * [Sarven Capadisli](https://csarven.ca/#i)
11 | * Justin Bingham
12 | * Kjetil Kjernsmo
13 | * Tim Berners-Lee
14 |
15 |
16 | ---
17 |
18 | ## Announcements
19 |
20 | ### Meeting Recordings and Transcripts
21 | * 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.
22 | * Join queue to talk.
23 |
24 |
25 | ### Participation and Code of Conduct
26 | * [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/)
27 | * [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/)
28 | * 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.
29 | * If this is your first time, welcome! please introduce yourself.
30 |
31 |
32 | ### Scribes
33 | * Sarven Capadisli
34 |
35 |
36 | ### Introductions
37 | * name: text
38 |
39 | ---
40 |
41 | ## Topics
42 |
43 |
44 | ### Restriction to only respond to authorized with Allow et al
45 | URL: https://github.com/solid/specification/pull/353
46 |
47 | * SC: Minor: rebase PR.. just need to call if we're okay with Allow not touching authz. AFAIK, KK and I have the same view on this.
48 | * KK: Distinction b/w Allow, WAC-Allow and Accept-* headers. My interpretation of HTTP is to not have Allow header touching authorization. TO make sure not to jump through hoops for an expensive operation.
49 | * KK: Aaron's concern was exposing various Accept-* headers.
50 | * JB: You can discover information about a resource that you shouldn't know. If you're not authenticated, what can you learn. That seems to be what Aaron and Emelia are concerned about. First can you know a resource exists or not. Brute forcing.. what can you learn. If something exists, what else can you learn about it. Conctainer or not. RDF or not. If we can directly answer those questions and A and E's satistfaction, the enumeration is reasonable then we are good.
51 | * SC: Allow does not entail resource exists.
52 | * JB: If true, security concern is not valid. Is this the right type of response expected by client eg. I'm not authorized give 4xx.
53 | * KK: Aaron's comment was to hide if something is an RDF document. Initially it was about not having authnz requirement for that section.. then I changed the patch to authnz only for Accept-* but not Allow. After that he hasn't returned with concerns.
54 | * KK: If we skip the Allow header then you can still guess and get a 405. Infer the same knowledge but with a great cost.
55 |
56 |
--------------------------------------------------------------------------------
/meetings/2025-02-19.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-02-19T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Present
9 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
10 | * [Matthias Evering](https://solidweb.me/testpro/)
11 | * [Pierre-Antoine Champin](https://champin.net/#pa)
12 | * [Areeba Aziz](https://areeba.ca/)
13 | * [Rahul Gupta](https://cxres.pages.dev/profile#i)
14 |
15 | ### Meeting Guidelines
16 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
17 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
18 | * 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.
19 | * Join queue to talk.
20 | * 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.
21 |
22 | ### Participation and Code of Conduct
23 | * [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/).
24 | * [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/)
25 | * 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.
26 | * If this is your first time, welcome! please introduce yourself.
27 |
28 |
29 | ### Scribes
30 |
31 | *
32 |
33 | ## Topics
34 |
35 | ### Announcements
36 |
37 | #### Scheduled STM about shape repo(s)
38 |
39 | https://www.w3.org/events/meetings/c2263a25-3633-4a6a-8a39-4cd38a29de33/
40 | https://forum.solidproject.org/t/solid-stm-about-shape-repo-s/8819
41 |
42 | #### Possible STM about app launcher explorations
43 |
44 | https://www.youtube.com/watch?v=5Q1nUmGdaXE
45 | https://github.com/activitypods/activitypods/pull/265
46 | https://github.com/solid/data-interoperability-panel/issues/324
47 | https://github.com/solid/specification/discussions/603#discussioncomment-7842808
48 |
49 | #### Solid World
50 |
51 | https://www.w3.org/events/meetings/2390f6e9-1e3c-4dab-89ab-512fca81fc80/
52 | https://www.eventbrite.co.uk/e/solid-world-february-2025-tickets-1224731427669
53 |
54 | * eP: What we should include in the update from CG? Also roadmap topic is relevant
55 |
56 |
57 | ### Setting a roadmap and deliverables for the CG
58 |
59 | * eP: Would like to consider overlap with https://github.com/solid/roadmap
60 |
61 | ### Issues renamed to *[Use of copyrighted material without permission or consent]*
62 |
63 | * eP: Just bringing it up to think how we can avoid such situations in the future
64 |
65 |
66 | ------
67 |
68 | Participants decided to end meeting after 20 min
69 |
--------------------------------------------------------------------------------
/meetings/2022-05-25.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2022-05-25T13:00:00Z
4 | * Call: https://meet.jit.si/solid-specification
5 | * Chat: https://gitter.im/solid/specification
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Present
9 | * [Sarven Capadisli](https://csarven.ca/#i)
10 | * Justin Bingham
11 | * Kjetil Kjernsmo
12 |
13 |
14 | ---
15 |
16 | ## Announcements
17 |
18 | ### Meeting Recordings and Transcripts
19 | * 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.
20 | * Join queue to talk.
21 |
22 |
23 | ### Participation and Code of Conduct
24 | * [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/)
25 | * [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/)
26 | * 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.
27 | * If this is your first time, welcome! please introduce yourself.
28 |
29 |
30 | ### Scribes
31 | * Sarven Capadisli
32 |
33 |
34 | ### Introductions
35 | * name: text
36 |
37 | ---
38 |
39 | ## Topics
40 |
41 |
42 | ### Access Control Policy authorization mechanism, version 0.9
43 | URL: https://github.com/solid/specification/pull/408
44 |
45 | * KK: My concern isn't so much with the proposal, but that the acceptance of it into TR may make the ecosystem diverge in an unhealthy way, so we might want to think about if we can make WAC and ACP converge into one thing.
46 | * SC: The ask is to publish a TR about an authorization data model.
47 | * JB: I think it is appropriate to merge now as it is well-formed work undertaken by the panel for the last year that provides useful value. There is another conversation to be had after this about the relationship between the protocol and ACP/WAC but that isn't the subject or substance of this PR.
48 | * KK: We should be explicit by what it means to be advanced to `/TR/`
49 | * JB: Yeah, and what it means to be a draft, etc
50 |
51 |
52 | ### Test Suite Panel Charter
53 | * SC: Charter development in progress as per https://github.com/solid/test-suite-panel/pull/4
54 | * SC: Specific issues: https://github.com/solid/test-suite-panel/issues/5 , https://github.com/solid/test-suite-panel/issues/6 , https://github.com/solid/test-suite-panel/issues/7
55 | * SC: Any feedback on https://github.com/solid/test-suite-panel/issues/5#issuecomment-1129987799 ?
56 |
57 |
58 | ### Requirement levels for Notifications
59 | * SC: Continuation of https://github.com/solid/specification/blob/main/meetings/2022-05-18.md#change-reference-to-solid-notifications-protocol
60 |
61 |
62 | ### What does it mean to be in `/TR`?
63 |
64 |
65 | ### Milestone/Roadmap/Prioritisation
66 | * SC: Continuation of https://github.com/solid/specification/blob/main/meetings/2022-05-18.md#milestone--roadmap--prioritisation
67 |
--------------------------------------------------------------------------------
/meetings/2021-06-15.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-06-15
4 |
5 | ## Present
6 |
7 | - Justin Bingham
8 | - Kjetil Kjernsmo
9 | - Ruben Verborgh
10 | - Sarven Capadisli
11 |
12 | ## Scribes
13 |
14 | - Justin Bingham
15 | - Kjetil Kjernsmo
16 |
17 | ## Agenda
18 |
19 | - Document Review / Discussion
20 | - Milestone / Priorities
21 | - W3C Versions
22 |
23 | ## Minutes
24 |
25 | ### Document Review / Discussion
26 |
27 | KK: Propose to submit a PR for the editorial document to solid/process. Should also link to this from the main README. (main process readme needs cleanup but that can be done separately)
28 |
29 | RV: Doc is reasonable
30 |
31 | JB: Believe my feedback has been captured. Believe we can start working this way now. Focus on measurable progress.
32 |
33 | +1 JB, +1 RV
34 |
35 | ### Milestones
36 |
37 | JB: Proposing that we establish milestones with target features at a level of (e.g. Ownership, ACP, Websockets).
38 |
39 | KK: Do milestones have to be tied to a version?
40 |
41 | JB: No strong preference - might be easier if they aren't tightly coupled to specific version.
42 |
43 | KK: Need to determine how W3C document versions are related
44 |
45 | ### Implementation Requirements
46 |
47 | KK: When should an implementation be required?
48 |
49 | JB: Can be contextual. Certain contexts it is always needed, some may be able to agree in advance.
50 |
51 | RV: Should establish a gate / line for point where it is required.
52 |
53 | SC: In certain cases a giant ask for implementation before spec might exclude contribution. So if you set the bar too high than participants with a lot of resources can dictate too much which goes into the spec.
54 |
55 | SC: https://www.w3.org/TR/ldn/#exit-criteria
56 | Must be one version of the spec that is stable enough to have implementation requirements (in LDN example), with two independent implementations that meet the criteria.
57 |
58 | KK: Agree this is something we need. Need to determine priority.
59 |
60 | SC: What are the requirements (implementation+) for panel specifications to be included in solid/specification and published under TR/.
61 |
62 | JB: +1 on implementations from panel submissions
63 |
64 | ### Versioning Scheme
65 |
66 |
67 |
68 | ### Monthly Cycle
69 |
70 | JB: When does the monthly cycle start? Proposing that we pick a date to start it, and jump in.
71 |
72 | A few questions:
73 | - where do we post questions about how to operate in this cycle
74 | - where do minutes get posted
75 | - how do we operate the weeklies (scribe, q+s)
76 | - what's the focus of the first cycle
77 |
78 | JB: Propose to start monthly cycle next Tuesday. Agree to have items to start next monthly cycle by then? KK +1
79 |
80 | SC: Propose we stick to something memorable (e.g. last/first tuesday of the month, last day of the month)
81 |
82 | JB: Third tuesday of the month? +1 KK
83 |
84 | KK: Might require adjustments in certain points of the year.
85 |
86 | JB: Would seem reasonable that we could agree on adjustments needed from time to time.
87 |
88 | SC: How to keep meetings / monthly cycles focused and not get diverted?
89 |
90 | JB: Suggest we have focused agendas in weeklies and especially in the monthlies.
91 |
92 | KK: Use the solid/specification repo / board to track todo items and issues pertaining to this
93 |
94 | +1 SC, +1 JB
95 |
--------------------------------------------------------------------------------
/meetings/2020-09-04.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-09-04
4 |
5 | ## Present
6 |
7 | - Justin Bingham
8 | - Ruben Verborgh
9 | - Sarven Capadisli
10 | - Tim Berners-Lee
11 |
12 | ## Scribes
13 |
14 | - Justin Bingham
15 |
16 | ## Agenda
17 |
18 | - Review current status
19 | - What's been done
20 | - What's in flight
21 | - What's left to do
22 | - Path to Draft Spec
23 | - PR Reviews
24 | - https://github.com/solid/specification/pull/185
25 | - https://github.com/solid/specification/pull/190
26 | - https://github.com/solid/specification/pull/196
27 | - Issue Reviews
28 | - https://github.com/solid/specification/issues/116
29 | - https://github.com/solid/specification/issues/14
30 |
31 | ## Minutes
32 |
33 | TBL: Access Control and Authorization is the most urgent at the moment. Has been a lot of rapid discussions about access control.
34 |
35 | JB: Noting that authorization panel has documented use cases that reflect some of the urgent needs that have also been raised around wac inheritance (https://solid.github.io/authorization-panel/wac-ucr/)
36 |
37 | SC: Attempting to transition from rough consensus to requirements. Looking to reorganize the outline. Still need to focus the spec on the core interactions (i.e. Solid Protocol https://solid.github.io/specification/ ). Want to restructure this to a point that captures the core Solid Protocol. Need to figure out what release of the spec should cover optional integrations. Clients and apps will be a separate spec.
38 |
39 | SC: Should WebID spec be updated? Should we clean up the current WebID spec? Authentication panel has dependencies on WebID and contents of profile document.
40 |
41 | SC: Do we consider one draft spec for solid ecosystem as a whole, then as we go forward we update it? We could point to loosely coupled specs (i.e. Authentication, Authorization) even though they are in-progress. Do all related spec drafts need to be in place for FPWD?
42 |
43 | TBL: Normal to have a high-level spec that involves other specs. Two scenarios (you control all specs, specs that you depend on you don't control)
44 | - Main spec relies on interface between the specs
45 | - Reasonable to have modular specs
46 | - Valuable to roll out the overall spec often (high-level spec plus dependents - core protocol, wac, authn)
47 |
48 | SC: Can we have a draft review of the "ecosystem" spec
49 |
50 | TBL: Clarity on what the ecosystem spec is. Ecosystem includes everything across solid, more of a vision document. Primary spec is the "Solid Protocol". Solid Ecosystem includes the "Solid Protocol" specification
51 |
52 | ### Specify container listing mechanism - https://github.com/solid/specification/issues/116
53 |
54 | SC: WAC is resource based access control. Question was raised about whether a use should see resources they don't have read access to in the containment listing. Currently we allow them to see a list if they have read on the collection.
55 |
56 | TBL: Current approach is simple, works for caching. Shouldn't overcomplicate.
57 |
58 | SC: Minimal design works out well - can do extensions for additional filtering without worry about core wac.
59 |
60 | ### Discuss returning 404 for privacy reasons - https://github.com/solid/specification/issues/14
61 |
62 | https://github.com/solid/specification/issues/14#issuecomment-683480525
63 | https://github.com/solid/specification/issues/116#issuecomment-674409281
64 |
65 |
66 |
--------------------------------------------------------------------------------
/meetings/2021-09-22.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-09-22T13:00:00Z
4 | * Call: https://meet.jit.si/solid-specification
5 | * Chat: https://gitter.im/solid/editors-group
6 | * Repository: https://github.com/solid/specification
7 |
8 |
9 | ## Present
10 | * [Sarven Capadisli](https://csarven.ca/#i)
11 | * Dmitri Zagidulin
12 | * Kjetil Kjernsmo
13 | * Justin Bingham
14 |
15 | ---
16 |
17 | ## Announcements
18 |
19 | ### Meeting Recordings and Transcripts
20 | * 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.
21 | * Use panel chat and repository. Queue in call to talk.
22 |
23 |
24 | ### Participation and Code of Conduct
25 | * [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/)
26 | * [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
27 | * If this is your first time, welcome! please introduce yourself.
28 |
29 |
30 | ### Scribes
31 | * Sarven Capadisli
32 |
33 | ### Introductions
34 | * name: text
35 |
36 | ---
37 |
38 | ## Topics
39 |
40 | ### Setup ad-hoc sessions based on at work issues
41 |
42 | KK: Propose when someone is the assignee of a given issue, they should try to schedule some ad-hoc live sessions when needed to work through a given issue (JB +1)
43 |
44 | ### Consider regular session between specification editors and implementors
45 |
46 | JB: Have a request from some implementors to consider live sessions between editors and implementors
47 |
48 | DZ: Like the idea +1
49 |
50 | KK: +1
51 |
52 | SC: Like the idea of engaging more with people. Need to be clear on who "some implementors". Suggest to reach out ot solid/app-development chat and related channels.
53 |
54 | JB: Can take the lead on setting it up since I raised it. Will make a github issue, and propose a summary of what it is / isn't, and share back with editor group for review/adjustment before posting to various channels.
55 |
56 | ### Solid Demos
57 | URL: https://gitter.im/solid/app-development?at=610bd4cb8fc359158c5484ef
58 |
59 | SC: Setup a monthly demos session where people can share / show-off what they're working on. Relax the community a bit to share things they're hacking on. JB +1
60 |
61 | JB: Great idea - would attend / participate
62 |
63 | KK: Engage Marrelle to coordinate
64 |
65 | SC: Engage Women of Solid as well
66 |
67 | ### Milestone: Current Month
68 | URL: https://github.com/solid/specification/milestone/4
69 |
70 | KK: Should set a monthly milestone and close it at end of timebox, and move things along
71 |
72 | JB: +1
73 | DZ: +1
74 | SC: +1
75 |
76 | ### Nominated
77 | URL: https://github.com/solid/specification/issues?q=is%3Aopen+is%3Aissue+label%3A%22status%3A+Nominated%22
78 |
79 | ### Clarify the notion and mechanisms for server-managed information
80 | URL: https://github.com/solid/specification/issues/177
81 |
82 | ### Specify container description
83 | URL: https://github.com/solid/specification/issues/227
84 |
85 | ### Editors Team to move/copy notifications related issues to the notifications-panel
86 | URL: https://github.com/solid/notifications-panel/issues/4
87 |
88 |
89 |
90 | ### Topic
91 |
92 | * name: text
93 | *
94 |
95 | PROPOSAL: text
96 | * name: +1,0,-1
97 | *
98 |
99 | ACTION: text
100 |
--------------------------------------------------------------------------------
/meetings/2021-09-14.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-09-14
4 |
5 | ## Present
6 |
7 | - Justin Bingham
8 | - Kjetil Kjernsmo
9 | - Dmitri Zagidulin
10 | - Sarven Capadisli
11 |
12 | ## Scribes
13 | - Justin Bingham
14 | - Sarven Capadisli
15 |
16 | ## Agenda
17 |
18 | * Moving Web Sockets to Notifications panel?
19 | * Process [Current Month Milestone](https://github.com/solid/specification/milestone/4)
20 | * Set up next month milestone, start nomination
21 | * Solid CG meeting at TPAC confirmed: https://www.w3.org/wiki/TPAC/2021/GroupMeetings#CG_Group_Meetings_details
22 |
23 | ## Minutes
24 |
25 | ### Moving Web Sockets to Notifications panel?
26 |
27 | * Sarven: Provides account of the charter review and status on the Notification Panel. Charter has been merged.
28 | * Editor's Meeting resolved to move the WebSocket issue to the Notification Panel.
29 |
30 |
31 | ### Specify Container Description https://github.com/solid/specification/issues/227
32 |
33 | KK: Have a separate auxiliary resource that includes minimal subset of server-managed metadata
34 |
35 | DZ: Don't make it too complicated. Specify a minimal set and make it accessible based on access.
36 |
37 | KK: If there is a link from the container to the auxiliary resource then you would have to get both if there's more data to get.
38 |
39 | SC: Need to allow the container to be editable by the client for client-supplied metadata. Additionally there's server managed metadata about the contained resources. There has been issue with the server having to check client access to each resource when listing them (to present additional metadata with the listing). Option is to have the server manage server-managed metadata in another auxiliary resource.
40 |
41 | DZ: Are there any issues with timestamps, creator being maintained by the server? (no issues raised)
42 |
43 | SC: Is there a benefit to splitting the server-managed data into another resource? considering that the server has to do the same work to materialise the metadata about contained resources depending on user's access.
44 |
45 | DZ: Simplifies the access control rules
46 |
47 | SC: Generally agree that it's easier to manage, but we have a way to already do that.
48 |
49 | JB: Agree with benefit to access control. Also have found need to filter out server managed triples when dealing with container graphs, and possibility for performance penalties when the containment triples are always included in reading / writing.
50 |
51 | KK: current behaviour is container resource has compound state
52 |
53 | SC: don't diverge from curent practice and self-describing resource practice.
54 |
55 | Consensus: Keep the compound state of container resources.
56 |
57 | SC: https://github.com/solid/specification/issues/227#authoritative-resource-metadata-options
58 |
59 | DZ:
60 |
61 | - ...
62 | - Specify minimum metadata in listing
63 | - ...
64 | - Give access to the richer metadata selectively
65 |
66 | SC: https://github.com/solid/specification/issues/227#user-content-server-managed-information-exposure - re don't expose more than 401/403.
67 |
68 | KK: It is important for query optimization. There's a difference between data and metadata.
69 |
70 | KK: Further consensus was not reached, we need to move these issues to the next milestone.
71 |
72 | ### Next month milestone
73 |
74 | KK: We need to start nomination of issues for the next monthly milestone. When should that start?
75 |
76 | KK: [Nomination](https://github.com/solid/process/blob/main/solid-editors-tr-process.md#nomination)
77 |
78 | SC: CG members can comment on issues eg: "I nominate this issue to be included in next Editor's meeting because x,y,z. #nextmilestone"
79 |
80 | ## Action Items
81 | * Sarven: to get confirmation from the notifications-panel to move relevant events/notifications issues to its repository.
82 |
83 | * Kjetil to create a "Nominated" label on the repo
84 |
--------------------------------------------------------------------------------
/meetings/README.md:
--------------------------------------------------------------------------------
1 |
2 | Document Status
3 |
9 |
10 |
11 | ---
12 |
13 | # W3C Solid Community Group Meeting Guidelines
14 |
15 | To reach consensus where no consensus has been reached before.
16 |
17 | It is recommended that meetings adopt the guidelines in this document as well as the [W3C Process](https://www.w3.org/Consortium/Process/) where applicable.
18 |
19 | The [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md) and [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/) must be followed by all meeting participants.
20 |
21 | ## Meeting Recordings and Transcripts
22 |
23 | 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.
24 |
25 | There is a [minutes template](https://github.com/solid/specification/blob/main/meetings/template.md) (Markdown) that can be used.
26 |
27 | ## Roles in Meetings
28 |
29 | Below are some common roles and their descriptions as useful guidelines. It is not a complete or strict list of duties.
30 |
31 | ### Participants
32 |
33 | * Includes everyone present in the meeting.
34 | * Participants may switch roles provided that it is clear to the other participants and there are no conflicts of interest.
35 | * Participants other than the moderator should add themselves to the queue to talk, remove themselves, or allow others to go ahead.
36 | * State name to scribe. Be concise. Stay within topic.
37 | * Should consider it their responsibility to help the scribe by offering to type summary into the chat; correct the log or improve fields marked by scribes during meeting; offer to fill in when scribe needs to speak.
38 | * Makes recommendations to improve meeting minutes, e.g., PRs.
39 | * Can recommend meeting topics before or during the meeting.
40 | * Participants should first attempt to use chats and repositories to work out concerns about the minutes or group decisions before meetings. Specific responses, e.g., clarifications or objections to previous group decisions can be proposed as topics to the meeting agenda.
41 | * Only Solid Community Group members may vote or raise objections during the meeting.
42 |
43 | ### Guests
44 |
45 | * Anyone can join a public meeting as a guest whether invited by someone or not.
46 | * Guests cannot vote or raise objections in discussions.
47 |
48 | ### Moderator
49 |
50 | * Defines and announces meeting agenda prior to the meeting.
51 | * Runs the meeting agenda; announcements, topics.
52 | * Generally stays neutral in discussion but can participate in discussions if announces in advance their "hat" at that time.
53 | * Acknowledge the attendance of participants and awareness of roles, and who is missing and the implications for the meeting.
54 | * Facilitate reaching consensus.
55 | * Asks participants to approve prior meeting minutes. If no objections, notes approval to scribe.
56 | * Ensures minutes are taken and posted in due time.
57 |
58 | ### Scribes
59 |
60 | * Transcribes the meeting *as is*: captures discussions, records actions and decisions.
61 | * Stops transcribing on speaker's request.
62 | * Requests assistance to improve transcription, e.g., mark text that needs correction or improvement (`???`), ask speaker or moderator for clarification.
63 | * Publishes minutes "soon after" the meeting (unless an another arrangement is made - to ensure it is on the same day).
64 | * Announces (draft and published) minutes in chats and elsewhere.
65 |
66 | ### Solid Community Group Chair
67 |
68 | * May adopt or request to take on a role before or during the meeting.
69 | * Provides guidance to processes, charters and the Solid ecosystem.
70 | * Follows up on Community Group related actions.
71 |
--------------------------------------------------------------------------------
/meetings/2021-08-31.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-08-31
4 |
5 | ## Present
6 |
7 | - Justin Bingham
8 | - Dmitri Zagidulin
9 | - Kjetil Kjernsmo
10 | - Sarven Capadisli
11 | - Tim Berners-Lee
12 |
13 | ## Scribes
14 | - Kjetil Kjernsmo
15 | - Sarven Capadisli
16 |
17 | ## Agenda
18 |
19 | * Where to store minutes
20 | * Weekly time
21 | * Notifications panel revival
22 | * Current month milestone
23 |
24 | ## Minutes
25 |
26 | ### Where to store minutes
27 |
28 | JB: Can we agree on a place to store minutes
29 |
30 | TBL: Can we host on solidcommunity.net?
31 |
32 | SC: There is https://specs.solidcommunity.net/ (currently used for WAC ED inboxb)
33 |
34 | JB: If we keep specs and minutes close to eachother (e.g. github), use PR on solid/specification/meetings/ but then automatically publish to sp.org (along with spec), and if sp.org runs off of solid, then we can accomplish both together? SC +1 TBL +1
35 |
36 | SC: Ensure that the meeting minutes do not substantively change the discussion - only to ensure that they are accurate of exactly of what was discussed. JB +1, TBL +1
37 |
38 | https://gitter.im/solid/specification?at=609265f3f7e4221825bae33d
39 |
40 | ### Weekly Time
41 |
42 | JB: Moving forward I will have some issues with this time slot, and also Dmitri has issues as it stands. Propose to find a new slot that works for everyone if thats OK? TBL +1, KK +1, Sarven +1, Dmitri +1
43 |
44 | ### Issue Review
45 |
46 | KK: Notifications panel restart and two issues related to container descriptions. Also open a nomination period where community can bring their issues to bear.
47 |
48 | TBL: Need to ensure that secure websockets is prioritized
49 |
50 | ### Notifications
51 |
52 | JB: Notifications panel restart *ideally* will allow us to resolve the shortfall in websockets with a design that we can live with long-term - since we're gotten implementors to commit to participate and work in conjunction on the draft + supporting implementations (client and server side).
53 |
54 | SC: Need to ensure that there is viable upgrade path
55 |
56 | TBL: Should be sure to look at the solution that has been provided and shared from inrupt at https://github.com/solid/specification/blob/feature/notification-protocol-data-flows/notification-protocol-data-flows.md
57 |
58 | SC: Does it patch things up or replace them
59 |
60 | TBL: It is a change and reimplementation. I am OK with that.
61 |
62 | SC: Are you OK with the design / architecture as proposed
63 |
64 | TBL: Fastest way to a good resolution is to use the changed / proposed protocol
65 |
66 | KK: I believe that we can move this from our monthly editorial panel and pick it up when the panel returns it in Q4 - +1 JB
67 |
68 | SC: Doesn't matter to me where it is taken up.. but whether it needs to wait for a complete solution (eg. discovery+negotiation+syntax/model) resolved before we have the prioritised secure websockets..
69 |
70 | ### Current Month Milestone
71 |
72 | Regarding: [Current Month Milestone](https://github.com/solid/specification/projects/1?card_filter_query=milestone%3A%22current+month%22)
73 |
74 | #### [Specify Container Description](https://github.com/solid/specification/issues/227)
75 |
76 | KK: https://github.com/solid/specification/issue/227
77 | SC: https://github.com/solid/specification/pull/228 . Currently in Protocol:
78 | >Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.
79 |
80 | Follow up issue in NSS:
81 | https://github.com/solid/node-solid-server/issues/1567
82 |
83 | JB: There are a lot of paths to provide efficiency and optimization, but you cannot un-expose data once you've exposed it. I think the protocol should only provide containment triples, and then we can separately look at ways to make access to metadata for resources more efficient.
84 |
85 | SC: Protocol should only provide containment triples
86 |
87 | KK: Provide in the issue the reasoning that containment triples should not provide any information that would require any permissions on the resource
88 |
89 | ## Action Items
90 |
91 | - Add meetings/ under solid/specification and move historical hackmds there (JB)
92 | - Find a weekly recurring time that works for all editors due to constraints from Justin and Dmitri (JB)
93 | - Await submission from notifications panel to resolve websocket gap
94 | - Follow up discussion #227
95 |
--------------------------------------------------------------------------------
/meetings/2022-05-11.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2022-05-11T13:00:00Z
4 | * Call: https://meet.jit.si/solid-specification
5 | * Chat: https://gitter.im/solid/specification
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Present
9 | * [Sarven Capadisli](https://csarven.ca/#i)
10 | * Kjetil Kjernsmo
11 | * Tim Berners-Lee
12 | * Justin Bingham
13 |
14 |
15 | ---
16 |
17 | ## Announcements
18 |
19 | ### Meeting Recordings and Transcripts
20 | * 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.
21 | * Join queue to talk.
22 |
23 |
24 | ### Participation and Code of Conduct
25 | * [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/)
26 | * [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/)
27 | * 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.
28 | * If this is your first time, welcome! please introduce yourself.
29 |
30 |
31 | ### Scribes
32 | * Sarven Capadisli
33 |
34 |
35 | ### Introductions
36 | * name: text
37 |
38 | ---
39 |
40 | ## Topics
41 |
42 |
43 | ### Milestone/Roadmap/Prioritisation meeting
44 | * SC: (Planning chat..)
45 | * SC: 2022-05-18T13:00:00Z to 2022-05-18T16:00:00Z.
46 |
47 |
48 | ### Specification Versioning Scheme under TR/
49 | * SC: (A PR is in the works for this but to recap) We roughly agreed to version new documents starting at 1.0.0. with pre-release?
50 | * TBL: Use semver.
51 | * KK: Panels use specs below 1.0.
52 | * KK: Append stuff that.
53 | * TBL: This is like CSS 1,2,3. 1.0 doesn't mean it is stable. This is the first draft of 1.0, e.g. 1.0-fpwd. 1.0 could be more stable than 1.1.
54 | * KK: That's compatible with semver.
55 | * TBL: With semver, whenever you make any you can make patch releases. Going from 0.1 to 0.2 that indicates incompatible change.
56 | * KK: It is really how big is that problem.
57 | * TBL: Solid-OIDC had lots of versions in fact.
58 | * KK: but version number is for the document not the conceptual protocol.
59 | * TBL: I think more of a version of the protocol.
60 | * KK: That's where we disagree apparently :)
61 | * TBL: Documents can be incompatible because of back compatibility concept.
62 | * KK: We need to put Protocol to 1.0.
63 | * TBL: yea.
64 | * KK: 1.0.0-draft.
65 | * TBL: communication concern.. people have different notions/expectation..
66 | * JB: People may not make a major issue of it. maybe for the roadmap we figure out what we want for each of the versions for external stakeholders. If we want to wait 1.0 for certain things, sure.
67 | * TBL: I like semver after 1.0.
68 | * JB: we don't even have to explain.
69 | * SC: CCG uses 0.x for reports. Anything that's intended for the standards track (under a WG) will move on to 1.x.
70 |
71 |
72 | ### Test Suite Panel Charter
73 | * SC: Proposed agenda for second meeting: https://github.com/solid/test-suite-panel/pull/4
74 |
75 |
76 | ### Change Reference to Solid-OIDC?
77 | * SC: TR/protocol currently normatively references [Solid-OIDC Editor's Draft](https://solid.github.io/solid-oidc/). Continue to require Solid-OIDC and change reference to https://solidproject.org/TR/oidc ?
78 |
79 |
80 | ### Change Reference to Solid Notifications Protocol?
81 | * SC: TR/protocol currently non-normatively references [Solid Notifications Protocol](https://solid.github.io/notifications/protocol). Require https://solidproject.org/TR/notifications-protocol and https://solidproject.org/TR/websocket-subscription-2021 ?
82 | * SC: Aside: https://solidproject.org/TR/notification-subscription-types is a Living Document. Lists subscription types that are published under /TR/ . Currently only /TR/websocket-subscription-2021 . /TR/notifications-protocol refers to /TR/notification-specification-types so that implementers can discover published subscription types. WIP subscription types are listed at https://github.com/solid/notifications/blob/main/README.md#subscription-types .
83 |
--------------------------------------------------------------------------------
/meetings/2025-09-10.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-09-10:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Repository: https://github.com/solid/specification
6 |
7 | ## Chair
8 |
9 | * Hadrian
10 |
11 | ## Present
12 |
13 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
14 | * [Luke Dary](https://www.linkedin.com/in/lukedary/)
15 | * [David Pinto](https://www.linkedin.com/in/davidpinto101/)
16 | * Tom Byrd
17 | * [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)
18 | * [Michal](https://id.mrkvon.org)
19 | * [Rui Zhao](https://me.ryey.icu)
20 |
21 | ## Regrets
22 |
23 | ## Scribes
24 |
25 | * elf Pavlik (intros)
26 |
27 | ---
28 |
29 | ## Announcements
30 |
31 |
32 | ### Meeting Guidelines
33 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
34 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
35 | * 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.
36 | * Join queue to talk.
37 | * 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.
38 |
39 | ### Participation and Code of Conduct
40 | * [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/)
41 | * [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/)
42 | * 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.
43 | * If this is your first time, welcome! please introduce yourself.
44 |
45 | ---
46 |
47 | ## Review Action items
48 |
49 | * eP to add Solid World to CG calendar - will do after this call
50 | * Tom to prepare agenda topic about access control models and law - finishing it up, will share in few hours
51 | * PAC Look for a person to explore the possibility of TPAC session and discuss it with Jesse, there will be semweb conf before that. - PAC sent a direct email with ccs, eP to follow up
52 |
53 |
54 | ## Introductions
55 |
56 | * Luke Dary, developer at Red Hat, been following Solid since its inception. Couldn't convice anyone internally to use it. Now we have a reason and trying to get more invested into it. I work on external facing websites, I hope to propose Solid solution that spans various of my responsibilities.
57 | * David Pinto, mathematician and social anthropologist. Working on economy (hacking money at source, treating money as a vector generates a completely different social contract not based on exchange), currently working on game using AI. It maximises LLM use to generate narrative cohesion amongst players. The LLM-builders collapse into modes of operations which are categorically heavy, don't seem to scale. Exploring SOLID as potential means of p2p system http://sqale.co/ http://onen.ai/
58 |
59 | ## Topics
60 |
61 | ### Solid World
62 |
63 | https://theodi.org/news-and-events/events/solid-world-september-2025/
64 |
65 | Tue Sep 16th
66 |
67 | ### Tracking obstacles
68 |
69 | * HZ: should that be coordinated with Practitioners?
70 | * Michal: we can discuss what new formats to include in Practitioners, this could be a good option.
71 | * eP: I would appreciate expertise on JSON-LD framing
72 |
73 | ### Use cases and requirements
74 |
75 | * Coordinating with WG
76 | * Capturing ones like brought up by Fred for Trinpod
77 |
78 | ### Reconnecting with communities
79 |
80 | Maybe Practictioners could lead it
81 |
82 | * https://solidlab.be/
83 | * https://solidcommunity.au/
84 |
85 | #### TREE & LDES
86 |
87 | https://www.w3.org/community/treecg/
88 |
89 | ### Update on Solid Efforts (if time allows)
90 |
91 | * process for publishing to solidproject.org/TR
92 |
93 | ## Actions
94 |
95 | * ACTION: eP to ask Fred where his US is being tracked as well as the proposal, maybe CG can track it
96 | * ACTION: HZ to reach out to contacts in Australia
97 |
--------------------------------------------------------------------------------
/meetings/2022-01-05.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2022-01-05T14:00:00Z
4 | * Call: https://meet.jit.si/solid-specification
5 | * Chat: https://gitter.im/solid/specification
6 | * Repository: https://github.com/solid/specification
7 |
8 |
9 | ## Present
10 | * [Sarven Capadisli](https://csarven.ca/#i)
11 | * Kjetil Kjernsmo
12 | * Justin Bingham
13 |
14 |
15 |
16 | ---
17 |
18 | ## Announcements
19 |
20 | ### Meeting Recordings and Transcripts
21 | * 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.
22 | * Join queue to talk.
23 |
24 |
25 | ### Participation and Code of Conduct
26 | * [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/)
27 | * [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/)
28 | * 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.
29 | * If this is your first time, welcome! please introduce yourself.
30 |
31 |
32 | ### Scribes
33 | * Sarven Capadisli
34 |
35 |
36 | ### Introductions
37 | * name: text
38 |
39 | ---
40 |
41 | ## Topics
42 |
43 | ### Solid Protocol Publication and Access
44 | * SC: Pinged Solid Team about the proposal in https://github.com/solid/specification/blob/main/meetings/2021-12-22.md#solid-protocol-publication-and-access . Should be in the next Team agenda.
45 | * JB: Asked CSS team on recommending that. Running CSS behind nginx. Vanilla config should get us most of the way there. Where to put it? Most likely use the same hosting strategy for solidproject.org as solidcommunity.net. Will ping current Admins - needs to be a group project. I can collaborate with them - a go to people. Can set up hosting for it. Setup a stage environment to test different publishing strategies. What kind of control over the URI space etc.
46 | * KK: Came to the conclusion when updating the specs. Needs to be a high priority. How to do certain merges and releases. Protocol for publishing :)
47 | * JB: Agree. Need stable and automated way. Conversely really awesome when it works.
48 |
49 |
50 | ### Milestone 0.9.x
51 | URL: https://github.com/solid/specification/milestone/6
52 |
53 | * KK: There are some there. We haven't sized or prioritised. Just put stuff in there.. then we go and release.
54 | * SC: Issues or PRs tagged for revisit can be put into this milestone right?
55 | * KK: Right.
56 | * KK: JB, I created https://github.com/solid/specification/issues/370 . Assign to you?
57 | * JB: Yes.
58 | * KK: Publishing to a Solid server is what we'd want to do.
59 | * JB: GH pages make it easy for specific subset. Outside of that you're on your own. We can automate with actions.
60 | * SC: ..
61 | * KK: If we edit, and want to do something. We'll dump the patch version.
62 | * SC: Use github actions and solid server together.. read-only or read-write server?
63 | * KK: read-write for github action.
64 | * SC: ..
65 | * JB: There are options e.g node-client. Just need to auth. We can make it so that it triggers automatically e.g on merge to main. There is flexibility.
66 | * SC: Can have writes to URL and flow back into git repo. There are node modules that can create commits and push on resource change. Can't remember the name - tested with dokieli writes against NSS. inotifywait?
67 |
68 |
69 | ### Solid Ecosystem
70 | URL: https://solidproject.org/TR/ecosystem
71 |
72 | * SC: Intended to communicate how the specifications in the ecosystem come together. But currently only includes a copy of `/TR/protocol#introduction` to emphasise the general vision, ethical considerations, and web architecture.
73 | * `/TR/` (Index of Technical Reports) includes Work Items in context of the Solid CG.
74 | * SC: If we keep `/TR/ecosystem`, it should talk or refer to the vision of the Solid project.
75 | * KK: Keep /TR/?
76 | * SC: Useful. Like W3C's /TR/
77 | * JB: /TR/ is useful.
78 | * KK: There are issues tagged with ecosystem. Things that need to be explained without normative text.
79 | * JB: There is more that can go in there. /ecosystem would be like the primer.
80 | * SC: Cool.
81 |
82 |
83 | ### Versioning and Publication of Work Items
84 | * SC: ...
85 | * KK: Fine with /ED/ /TR/ alongside /TR/{yyyy}/
86 |
--------------------------------------------------------------------------------
/meetings/2021-02-16.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2021-02-16
4 |
5 | ## Present
6 | * Justin Bingham
7 | * Dmitri Zagidulin
8 | * Tim Berners-Lee
9 | * Sarven Capadisli
10 |
11 | ## Scribes
12 |
13 | * Sarven Capadisli
14 | * Justin Bingham
15 |
16 |
17 | ## Agenda
18 |
19 | * Announcements
20 | * Pull Requests
21 | * Issues
22 | * Topic Items
23 | * W3C CredentialsCG Presentation (March 10)
24 | * WICG / WebID Meeting (February 22)
25 | * Shape Tree Validation / CSS
26 | * Publish / Subscribe
27 | * Discovery Patterns
28 |
29 |
30 | ## Minutes
31 |
32 | ### W3C CredentialsCG Presentation
33 |
34 | SC: Aim to look at places where we can collaborate / overlapping places / digital wallets / did. Present out key work items / specs. They will present in our authz panel time slot, and they will present in their regular time slot later that day.
35 |
36 | Agenda: Sarven will intro to Solid CG / Tim on Solid project/ecosystem/architecture / Sarven on Protocol / Henry - Identity / Aaron - Authentication / Henry - Authorization / Justin - Interop
37 |
38 | DZ: Two groups are very similar. Central CG with a bunch of task forces / sub-groups (e.g. panels). They have DID, COnfidential storage, Educational Task Force. Form some very complimentary sets of technology. Working on tech that solid could just drop in. DID, VC, Confidential storage (drop LDP on top of it). Things Solid is working on that could be beneficial - higher application level protocols: multi-rs authentication. Access control - they have the zcap spec, but there's no equivalent identity-based acl. Data interop ecosystem stuff - this is an access request. This is an application's web id profile. These are indexes / type indexes. That group will need to do that also, but hasn't started thinking about it yet. One area of concern - two thirds of the community group are familiar with JSON-LD. Almost none are familiar with turtle. Since we tend to be turtle focused, it might appear as more exotic and unfamiliar to them.
39 |
40 | TBL: JSON-LD/Turtle always been something where community has wanted to have their cake and eat it too. Lets try to avoid that dispute. Look at getting VC code into the data browser code base.
41 |
42 | JB: Have been able to demonstrate VCs in Application Profiles
43 |
44 | DZ: Confidential storage - describes a key-value interface, plus a simple query interface. Using EDV as a storage adapter is a natural fit (e.g. for CSS). Second spec that confidential storage group is working on - identity hubs (essentially solid). Identity Hub is broader / more vaguely defined. Wants to do everything that solid does (e.g. collections, authentication, access control, inboxes, messaging). Might be interesting for identity hub portion to use Solid specs.
45 |
46 | JB: Why not use Solid for Identity Hub
47 |
48 | DZ: Primarily unfamiliarity. Recommend people from Solid start joining in those sessions as well. Just started to talk about interface between EDV and Identity Hub.
49 |
50 | JB: What's the interface between?
51 |
52 | DZ: HTTP API exposed by EDV (CRUD HTTP API). Main discussion is division of responsibilities? Which of the specs controls replication? Who's going to be doing the replication? Which spec will handle which aspect.
53 |
54 | JB: Seems there are two aspects: Technologies we can collaborate on (DID, VC), but then whether we work together on a data store (e.g. Solid) vs. work in parallel on competing / similar things (Solid vs. Identity Hub).
55 |
56 | TBL: MS should be a good fit for Solid. If we can get a global ID system.
57 |
58 | JB: Diverge or Converge
59 |
60 | TBL: Need to be sure that we look at these opportunities to diverge vs. converge and try to converge where we can. We have aspirations to be very big. We're fed up with have six different ways to log into things. We want to be able to use this for all data. May be worth having some combined workshops.
61 |
62 | Goal: Get additional sessions setup with different people for work moving forward
63 |
64 | JB: How do we work backwards from having one combined projects to currently having two diverging projects
65 |
66 | SC: That's what a working group is for - approach to standardize
67 |
68 | TBL: Could start a chartered working group
69 |
70 | DZ: Tim thoughts on potential for integration of WebIDs / DIDs?
71 |
72 | TBL: No reason not to have that integration, as long as there's a way to come in through HTTP.
73 |
74 | TBL: Other homework - Solid Roadmap is missing things. Needs a bit of refactoring. SolidOS vs. broader Solid roadmap. If there are things missing from it - there needs to be a Solid ecosystem roadmap. Please review.
75 |
76 | Look at Web KMS and digital wallets
77 |
78 |
--------------------------------------------------------------------------------
/2022/acp-code-20220518.css:
--------------------------------------------------------------------------------
1 | .highlight table td {
2 | padding: 5px;
3 | }
4 |
5 | .highlight table pre {
6 | margin: 0;
7 | }
8 |
9 | .highlight .cm {
10 | color: #999988;
11 | font-style: italic;
12 | }
13 |
14 | .highlight .cp {
15 | color: #999999;
16 | font-weight: bold;
17 | }
18 |
19 | .highlight .c1 {
20 | color: #999988;
21 | font-style: italic;
22 | }
23 |
24 | .highlight .cs {
25 | color: #999999;
26 | font-weight: bold;
27 | font-style: italic;
28 | }
29 |
30 | .highlight .c,
31 | .highlight .ch,
32 | .highlight .cd,
33 | .highlight .cpf {
34 | color: #999988;
35 | font-style: italic;
36 | }
37 |
38 | .highlight .err {
39 | color: #a61717;
40 | background-color: #e3d2d2;
41 | }
42 |
43 | .highlight .gd {
44 | color: #000000;
45 | background-color: #ffdddd;
46 | }
47 |
48 | .highlight .ge {
49 | color: #000000;
50 | font-style: italic;
51 | }
52 |
53 | .highlight .gr {
54 | color: #aa0000;
55 | }
56 |
57 | .highlight .gh {
58 | color: #999999;
59 | }
60 |
61 | .highlight .gi {
62 | color: #000000;
63 | background-color: #ddffdd;
64 | }
65 |
66 | .highlight .go {
67 | color: #888888;
68 | }
69 |
70 | .highlight .gp {
71 | color: #555555;
72 | }
73 |
74 | .highlight .gs {
75 | font-weight: bold;
76 | }
77 |
78 | .highlight .gu {
79 | color: #aaaaaa;
80 | }
81 |
82 | .highlight .gt {
83 | color: #aa0000;
84 | }
85 |
86 | .highlight .kc {
87 | color: #000000;
88 | font-weight: bold;
89 | }
90 |
91 | .highlight .kd {
92 | color: #000000;
93 | font-weight: bold;
94 | }
95 |
96 | .highlight .kn {
97 | color: #000000;
98 | font-weight: bold;
99 | }
100 |
101 | .highlight .kp {
102 | color: #000000;
103 | font-weight: bold;
104 | }
105 |
106 | .highlight .kr {
107 | color: #000000;
108 | font-weight: bold;
109 | }
110 |
111 | .highlight .kt {
112 | color: #445588;
113 | font-weight: bold;
114 | }
115 |
116 | .highlight .k,
117 | .highlight .kv {
118 | color: #000000;
119 | font-weight: bold;
120 | }
121 |
122 | .highlight .mf {
123 | color: #009999;
124 | }
125 |
126 | .highlight .mh {
127 | color: #009999;
128 | }
129 |
130 | .highlight .il {
131 | color: #009999;
132 | }
133 |
134 | .highlight .mi {
135 | color: #009999;
136 | }
137 |
138 | .highlight .mo {
139 | color: #009999;
140 | }
141 |
142 | .highlight .m,
143 | .highlight .mb,
144 | .highlight .mx {
145 | color: #009999;
146 | }
147 |
148 | .highlight .sa {
149 | color: #000000;
150 | font-weight: bold;
151 | }
152 |
153 | .highlight .sb {
154 | color: #d14;
155 | }
156 |
157 | .highlight .sc {
158 | color: #d14;
159 | }
160 |
161 | .highlight .sd {
162 | color: #d14;
163 | }
164 |
165 | .highlight .s2 {
166 | color: #d14;
167 | }
168 |
169 | .highlight .se {
170 | color: #d14;
171 | }
172 |
173 | .highlight .sh {
174 | color: #d14;
175 | }
176 |
177 | .highlight .si {
178 | color: #d14;
179 | }
180 |
181 | .highlight .sx {
182 | color: #d14;
183 | }
184 |
185 | .highlight .sr {
186 | color: #009926;
187 | }
188 |
189 | .highlight .s1 {
190 | color: #d14;
191 | }
192 |
193 | .highlight .ss {
194 | color: #990073;
195 | }
196 |
197 | .highlight .s,
198 | .highlight .dl {
199 | color: #d14;
200 | }
201 |
202 | .highlight .na {
203 | color: #008080;
204 | }
205 |
206 | .highlight .bp {
207 | color: #999999;
208 | }
209 |
210 | .highlight .nb {
211 | color: #0086B3;
212 | }
213 |
214 | .highlight .nc {
215 | color: #445588;
216 | font-weight: bold;
217 | }
218 |
219 | .highlight .no {
220 | color: #008080;
221 | }
222 |
223 | .highlight .nd {
224 | color: #3c5d5d;
225 | font-weight: bold;
226 | }
227 |
228 | .highlight .ni {
229 | color: #800080;
230 | }
231 |
232 | .highlight .ne {
233 | color: #990000;
234 | font-weight: bold;
235 | }
236 |
237 | .highlight .nf,
238 | .highlight .fm {
239 | color: #990000;
240 | font-weight: bold;
241 | }
242 |
243 | .highlight .nl {
244 | color: #990000;
245 | font-weight: bold;
246 | }
247 |
248 | .highlight .nn {
249 | color: #555555;
250 | }
251 |
252 | .highlight .nt {
253 | color: #000080;
254 | }
255 |
256 | .highlight .vc {
257 | color: #008080;
258 | }
259 |
260 | .highlight .vg {
261 | color: #008080;
262 | }
263 |
264 | .highlight .vi {
265 | color: #008080;
266 | }
267 |
268 | .highlight .nv,
269 | .highlight .vm {
270 | color: #008080;
271 | }
272 |
273 | .highlight .ow {
274 | color: #000000;
275 | font-weight: bold;
276 | }
277 |
278 | .highlight .o {
279 | color: #000000;
280 | font-weight: bold;
281 | }
282 |
283 | .highlight .w {
284 | color: #bbbbbb;
285 | }
286 |
287 | .highlight {
288 | background-color: #f8f8f8;
289 | }
290 |
--------------------------------------------------------------------------------
/meetings/2024-07-17.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2024-07-17T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 | * Status: Published
8 |
9 |
10 | ## Present
11 |
12 | * Hadrian Zbarcea
13 | * [Rahul Gupta](https://cxres.pages.dev/profile#i)
14 | * Willem Datema
15 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
16 | * [Matthias Evering](https://solidweb.me/testpro/)
17 | * Grace Elcock
18 | * Rui Zhao
19 |
20 | ---
21 |
22 | ## Announcements
23 |
24 | ### Meeting Guidelines
25 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
26 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
27 | * 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.
28 | * Join queue to talk.
29 | * 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.
30 |
31 | ### Participation and Code of Conduct
32 | * [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/).
33 | * [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/)
34 | * 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.
35 | * If this is your first time, welcome! please introduce yourself.
36 |
37 | ### Scribes
38 |
39 | * elf Pavlik
40 |
41 | ---
42 |
43 | ## Topics
44 |
45 | ### TPAC: Call for Group updates and Technical demos (videos)
46 | > We invite your group to create a video (or more) to be featured on the TPAC24 website at https://www.w3.org/2024/09/TPAC/group-updates.html
47 | This is a great opportunity to showcase your work, share updates, and present technical demos of your latest advancements to the wider W3C community.
48 | Drawing from our experience, we have compiled a set of best practices to help create impactful videos:
49 | https://www.w3.org/wiki/TPAC/2024/Demos_and_Group_updates#Best_Practices_for_Recording_Videos
50 | For reference, please have a look at the TPAC 2023 videos: https://www.w3.org/2023/09/TPAC/group-updates.html
51 |
52 |
53 | * HZ: Does anybody plan to be present or prepare a demo?
54 | * eP: Is it part of the breakout session?
55 | * HZ: I think the videos can be seen outside of the session.
56 | * eP: I have some videos for SAI, so I can prepare some short videos; will look at the guidelines.
57 | * HZ: Please let me know if I can help.
58 | * eP: I can do it as an individual but open to do it as shared CG effort.
59 | * RG: What is the plan of CG or Solid team? What will be the structure of this session? I can update work on notifications. If the plan is to talk about administration, it probably will not fit.
60 | * HZ: I don't think it is decided how we will run the session. I imagine a lot of conversation will be around future of CG and WG. Last year, there were a lot of conversations. If we have videos, they will be mentioned during the session. This way people will have a chance to ask questions. In the end, I don't know and this is not just up to me. I'm not sure if I will be there in person.
61 | * RG: Can you have a chat with Solid team?
62 | * HZ: Next meeting will be the 2nd week of August.
63 | * RG: I don't know if you have a chair for this session appointed.
64 |
65 | ACTION: HZ to find out who will chair the TPAC meeting
66 |
67 |
68 | ### WG status
69 |
70 | * HZ: AC vote is not scheduled yet, even though TAG has approved the charter. Vote will probably start in September.
71 | * GE: Do you have any more news on WG? Did someone speak with PAC?
72 | * HZ: I didn't. I know that Aaron and Eric have regular meetings. From what I know, PAC expected TAG review to end in June, and that happened.
73 | * HZ: Tim should know, since he should receive notifications. I assume that people might be on vacations/holidays.
74 |
75 | ### Open topic
76 |
77 | * eP: I think Solid might miss something equivalent to a Project Manager role.
78 | * RG: There are projects in the community that have no maintainers. We need a plan to make sure these things get maintained. Financing is another aspect to talk about. One idea is to have some sort of Solid Foundation.
79 |
80 |
--------------------------------------------------------------------------------
/meetings/2025-09-17.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-09-17: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 | * [Erich Bremer](https://ebremer.com)
14 | * Tom Byrd
15 | * Marc Haddle
16 | * Theo - Thhck
17 | * [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)
18 | * [Rui Zhao](https://me.ryey.icu)
19 |
20 | ## Regrets
21 |
22 | ## Scribes
23 |
24 | * Theo
25 |
26 | ---
27 |
28 | ## Announcements
29 |
30 | ### Meeting Guidelines
31 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
32 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
33 | * 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.
34 | * Join queue to talk.
35 | * 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.
36 |
37 | ### Participation and Code of Conduct
38 | * [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/)
39 | * [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/)
40 | * 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.
41 | * If this is your first time, welcome! please introduce yourself.
42 |
43 | ---
44 |
45 |
46 | ## Introductions
47 |
48 |
49 | ## Review Action items
50 | * Tom from 2 weeks ago - https://hackmd.io/@dtb23/SyWsIvljll
51 | * ACTION: eP to ask Fred where his US is being tracked as well as the proposal, maybe CG can track it
52 | * eP: Fred created a use case https://github.com/w3c/lws-ucs/issues/215
53 | * ACTION: HZ to reach out to contacts in Australia
54 |
55 |
56 | ## Topics
57 |
58 | ### Tracking Proposals for UCR
59 | * eP: How do we track prior art and new proposals?
60 | * eP: Or who can track those? Hadrian?
61 | * EB: Track it on a github issue
62 | * RZ: Github issue is OK but not the best; can show all the categories together and can't do a good semantic link between the issue. Can also use github project (like a kanban), (but has some limitation too)
63 | * eP: I can follow up on that, and coordinate with Hadrian. Ppl from WG can join CG meeting to organise it. Can find time and space to work on that.
64 |
65 |
66 | ### Pull Requests
67 |
68 | #### Publish SAI v0.1
69 |
70 | https://github.com/solid/specification/pull/743
71 |
72 | * eP: Mostly reserves canonical URLs and publishes minimal RDF description of spec/primer and product classes
73 | * eP: Try to get canonical URL or permalink for the primer and spec, get ride of github pages. Create a `solidproject.org/TR` link . Someone has opinion on this?
74 | * eP: Sarven raised concernes on the spec [...]
75 | * no opinion from the meeting participants; eP will wait for the review of the tagged reviewer
76 |
77 | ### Tracking obstacles
78 |
79 | * Theo: I was able to run ESM-only library on CSS 8-alpha.1 fedify a FediVerse library implementing most of ActivityPub spec. I plan to make some glue to have it working with Solid via CSS.
80 | * eP: Are you coordinate with Michal? He plans to present something?
81 | * Theo: Yes, we take different approaches, he develops an external agent, and I'm implementing directly in CSS. It will be good to see the two different approaches in action.
82 | * eP: Michal might do a demo on his work.
83 |
84 | ### Implementation feedback
85 |
86 | https://theodi.org/news-and-events/events/solid-world-september-2025/
87 |
88 | * eP: Important part of CG is to work on report, and to be in contact with actor implementing. Get implementation feedback and report to the spec. Yesterday, ppl who presented at the SolidWorld were mostly ppl who are not part of the CG. How can we get feedback from those implementers? Shoud we reach out? Let's try to get this feedback.
89 | * eP: Two very interesting projects were presented during the SolidWorld. We could gather important implementation feedback from their tech leads. Who would like to make an attempt to organize initial meetings, where we could start deep dive into technical details? Preferably we would coordinate with LWS WG in case someone wants to join. After that we should produce PR capturing that feedback that gets reviewed by the implementers providing it.
90 | * eP: We can make a separate meeting or invite them to the CG.
91 | * Theo: I can contact them
92 |
93 | ## Actions
94 |
95 | * ACTION: Theo to connect with muze.nl and PASS to gather feedback
96 | * ACTION: eP to follow up with Hadrian, Rui, and others to put it on the agenda as longer topic
97 |
98 |
--------------------------------------------------------------------------------
/meetings/2025-06-25.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-06-25T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Chair
9 |
10 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
11 |
12 | ## Present
13 |
14 | * Hadrian Zbarcea
15 | * Marc Haddle
16 | * Jeff Zucker
17 | * Tom Byrd
18 | * Erich Bremer
19 | * Matthias Evering
20 | * Jesse Wright
21 |
22 | ## Regrets
23 |
24 |
25 | ## Scribes
26 |
27 | * elf Pavlik
28 |
29 | ---
30 |
31 | ## Announcements
32 |
33 | ### Meeting Guidelines
34 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
35 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
36 | * 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.
37 | * Join queue to talk.
38 | * 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.
39 |
40 | ### Participation and Code of Conduct
41 | * [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/)
42 | * [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/)
43 | * 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.
44 | * If this is your first time, welcome! please introduce yourself.
45 |
46 | ---
47 |
48 | ## Topics
49 |
50 | ### Review Action items
51 |
52 | * ACTION: ✅ HZ to reach out to Inrupt to understand the commitment to maintain the repo
53 | * ACTION: ✅ eP to make a PR on text we worked on with Ian
54 | * ACTION: ✅ PAC to check with W3C about content negotiation for /TR/
55 |
56 | ### CG Chair rotation schedule
57 |
58 | https://github.com/solid/specification/discussions/703
59 |
60 | * eP: when we copy minutes from the pad we can simply update *chair* for the next meeting
61 |
62 | ### initial drafts of principles and framework for proposals
63 |
64 | https://github.com/w3c-cg/solid/pull/22
65 |
66 | #### Concerns about overlap and ambiguity introduced by PR 22
67 | URL: https://github.com/w3c-cg/solid/issues/23
68 |
69 |
70 | ### solid catalog - plans for self publishing
71 |
72 | https://github.com/solid/catalog/issues/4#issuecomment-2994170980
73 |
74 | * eP: ...
75 | * JZ: sharing screen
76 | * JZ: this is current version of catalog, my and Pavlik's goals are very different. I worked on it for 5 years and gathered hundreds of records. What I designed is meant to be public facing catalog intended for people not familiar with solid to get involved. Find resources, help with app development, information on technical resources.
77 | * JZ: Very important part is categorization and presentation of categories, it is an ongoing process and changes based on user's feedback. I think it is premature for most parts to talk about self publishing. Some of technical resources that Pavlik is working on, are close to be ready for self publishing. On the other hand learning resources, communication channels etc. Those don't have existing descriptions and we don't have a way to pull that information out. There is a number of issues with organizations and people. We can say that they have WebID and we can just scrape that. People may want to have different things in their WebID profile and in solid catalog profile. I don't think we will ever get to the point where everyone has capability to do that. I think we need central catalog with forms. We can also eventually accomodate pulling in the data from other sources. I don't think shapes are ready, especially in the form of categorization. If we look at existing classes, we don't get any further categorization of that. We have keyword system as well to gather input for the future.
78 | * JZ: I'm in favor of eventual self-publishing effort, not in favor to jump directly into that.
79 | * JZ: Another difference is in using SKOS categories, Pavlik takes a position that those are catalog specific and we shouldn't have it as part of our shapes. If the idea is to self publish without paying attention to categorization I'm opposed for that.
80 | * JZ: I proposed that we can have submission process where categories can be added. I don't agree to dump data into catalog without categorizing it. Categorization can help with drawing in users.
81 | * eP: ...
82 | * EB: Where is the RDF data?
83 | * eP: https://github.com/solid/catalog/blob/main/catalog-data.ttl
84 | * JZ: For some kinds of resources categories can be added afterwards. For example for apps people should be able to add categories by themself. I think this should be part of shapes. Here is published skos taxonomy, public can say it makes sense or not, app providers can say if it describes their apps or not.
85 |
86 |
87 | conversation continues unscribed
88 |
--------------------------------------------------------------------------------
/meetings/2025-09-03.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-09-03:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Chair
9 |
10 | * Michiel
11 |
12 | ## Present
13 |
14 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
15 | * [Pierre-Antoine Champin](https://champin.net/#pa)
16 | * [Matthias Evering](https://soliweb.me/testpro/)
17 | * [Erich Bremer](https://ebremer.com)
18 | * Tom Byrd
19 | * [Michal](https://id.mrkvon.org)
20 | * Marc Haddle
21 | * Michiel de Jong
22 | * Mahdi Baghbani
23 | * [Matthieu Bosquet](https://github.com/matthieubosquet)
24 | * Ted Thibodeau Jr (he/him) (OpenLinkSw.com) // GitHub:[@TallTed](https://github.com/TallTed) // Mastodon:[@TallTed](https://mastodon.social/@TallTed)
25 | * [Rui Zhao](https://me.ryey.icu)
26 |
27 |
28 | ## Regrets
29 |
30 | ## Scribes
31 |
32 | * elf Pavlik
33 |
34 | ---
35 |
36 | ## Announcements
37 |
38 |
39 | ### Meeting Guidelines
40 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
41 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
42 | * 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.
43 | * Join queue to talk.
44 | * 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.
45 |
46 | ### Participation and Code of Conduct
47 | * [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/)
48 | * [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/)
49 | * 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.
50 | * If this is your first time, welcome! please introduce yourself.
51 |
52 | ---
53 |
54 | ## Review Action items
55 |
56 | * eP: [Draft PR to CSS grant-type:jwt-barer — alternative to client credentials](https://github.com/CommunitySolidServer/CommunitySolidServer/pull/2053) — Client ID URL and multi tenant
57 | * eP: [Conformance Test Hanress 'main' seems broken](https://github.com/solid-contrib/conformance-test-harness/issues/673)
58 | * eP: [ESM support for Components.js](https://github.com/comunica/comunica/issues/930#issuecomment-3224275352) — affecting CSS, sai-js, LDO (indirectly NextGraph), Comunica, etc.
59 |
60 | ## Topics
61 |
62 | ### Community Council CG
63 |
64 | [Update on Project to Enhance Community Groups](https://www.w3.org/events/meetings/29a19815-57f8-488a-8e14-9b5809bf14de/)
65 |
66 | ### Solid World
67 |
68 | https://theodi.org/news-and-events/events/solid-world-september-2025/
69 |
70 | Tue Sep 16th
71 |
72 |
73 | ### Focus in Q4 2025
74 |
75 | #### Demos
76 |
77 | * PodOS — Angelo
78 | * DToU — Rui
79 | * LDES? — Wout?
80 | * SpOTy: Solid app developed in collab with research center in linguistics — PAC
81 | * Solid Activity Pub integration — Michal
82 |
83 |
84 | ##### misc
85 |
86 | * Tom: Discussion about access control models and law; for example, in US, regarding health care.
87 |
88 |
89 | ### Tracking obstacles
90 |
91 | We can keep better track of the obstacles participants are facing in achieving their goals. How CG and broader Solid community can help with overcoming them.
92 |
93 | eP: For instance, functionality someone needs in CSS or in the test harness.
94 |
95 | MdJ: Yes, for instance also, when someone asks a question on Matrix, in general we get good replies and pointers.
96 |
97 | Matthias: I managed to process read process, now working on write. It feels like the puzzle where pieces are falling into places. I'm diving into Noel's code, and following open source approach.
98 |
99 | ### Use cases and requirements
100 |
101 | * Coordinating with WG
102 | * Capturing ones like brought up by Fred for Trinpod
103 |
104 | ### Reconnecting with communities
105 |
106 | Maybe Practictioners could lead it
107 |
108 | * https://solidlab.be/
109 | * https://solidcommunity.au/
110 |
111 | PAC: Scope of Solid CG is pretty broad and it might be hard to track. There are break out sessions around TPAC and in spring. CGs may discuss and open what they do for broader audience. Also open our group and make joined sessions. PAC will be there in person.
112 |
113 | https://www.w3.org/2025/11/TPAC/breakouts.html
114 |
115 |
116 | ### Scribing
117 |
118 | Can we keep trying to automate it? More CGs need it, worth finding out what hapened to the [modern tooling](https://w3c.github.io/modern-tooling/) effort.
119 |
120 | * TallTed: Credentials CG has embraced GoogleMeet and some autotranscriber therein. It's still not perfect, but it's better than many humans, and far better than bot transcription was a year a few months ago.
121 |
122 | MdJ: I don't think scribing is enough of a reason to move away from open source tooling.
123 |
124 |
125 | ## Actions
126 |
127 | * ACTION: eP to add Solid World to CG calendar
128 | * ACTION: Tom to prepare agenda topic about access control models and law
129 | * ACTION: PAC Look for a person to explore the possibility and discuss it with Jesse, there will be semweb conf before that.
130 |
--------------------------------------------------------------------------------
/meetings/2025-10-15.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-10-15T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Repository: https://github.com/solid/specification
6 |
7 | ## Chair
8 |
9 | * Michiel
10 |
11 | ## Present
12 |
13 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
14 | * [Erich Bremer](https://ebremer.com)
15 | * Sarven Capadisli
16 | * Tom Byrd
17 | * Theo - @thhck
18 | * Hadrian Zbarcea
19 | * Marc Haddle
20 | * [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)
21 | * Luke Dary
22 |
23 | ## Regrets
24 |
25 | ## Scribes
26 |
27 |
28 | ---
29 |
30 | ## Announcements
31 |
32 | ### Meeting Guidelines
33 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
34 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
35 | * 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.
36 | * Join queue to talk.
37 | * 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.
38 |
39 | ### Participation and Code of Conduct
40 | * [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/)
41 | * [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/)
42 | * 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.
43 | * If this is your first time, welcome! please introduce yourself.
44 |
45 | ---
46 |
47 |
48 | ## Introductions
49 |
50 |
51 | ## Review Action items
52 |
53 | * HZ to reach out to contacts in Australia
54 | * Theo to connect with muze.nl and PASS to gather feedback
55 | * done. no answer yet from either, but
56 | * MdJ: if we invited them to contribute their experience and ideas then I guess that's enough
57 | * eP to follow up with Hadrian, Rui, and others to put it on the agenda as longer topic about tracking proposals for use cases
58 | * eP: can we plan next step today if everyone is present?
59 | * eP: Hadrian doesn't seem to follow matrix and my email ended up on spam list due to issue in DNS config. Can we pick a common communication channel?
60 | MdJ: we'll move these items to github, so we can remove them here
61 |
62 | ## Topics
63 |
64 | ### Pull Requests
65 |
66 | ### Tracking obstacles
67 |
68 | ### Removal of content in GitHub issues
69 |
70 | * eP: Followup on https://github.com/solid/specification/blob/main/meetings/2025-10-01.md#copyright-violation-claim-in-solid-cg
71 | * eP: From email thread, I understand that Ruben just wants to be left alone and CG should be able to restore content. We could write very short action plan to restore content I could double check with Ruben if he commits to accept that content being restored not to raise any copyright claims.
72 | * eP: Where exactly the offcial claim (not renaming issue) was raised and who is responsible for resolving it? There were mentions of ODI and W3C but to my understanding not directly Solid CG.
73 | * SC: Don't need permission from RV to restore content or change issue titles. Anything pertaining to copyright can be addressed by W3C, if it has any merit. The rest is about protecting CG material, and the CG (e.g., chairs) can do that.
74 | * SC: With respect to being "left alone", that certainly didn't seem to be the case when RV decided to participate in https://github.com/solid/specification/pull/711 (see also Internet Archive) on his own (years after leaving the CG). No one is chasing RV to my knowledge.
75 |
76 | ### Spin-off CGs?
77 |
78 | * MdJ: Thinking outside the box here — some of our work items (like personal data interop and personal data auth) are useful outside of Solid, too. So we could move them into spin-off CGs?
79 | * eP: yes, I tried something like this with RDF-CRDT, but there was too much overhead animating the momentum, so in the end we would maybe end up with 5 inactive CGs instead of one active one
80 | * SC: I think along the same lines. There needs to be significant activity to be worthwhile whether panel or another CG/WG/IG or whatever. SAI could become a WG because there is incubation history. You would also need to get buy-in from outside Solid. Groups have a risk of being exciting at first but then quieting down later. Have some commitment from people and have a charter etc.
81 | * eP: I'll join the CG program meeting again, we can improve interaction with other CGs. It's a bit like monorepo vs multiple repos, it doesn't really matter what you call it, the same people would be doing the same work.
82 | * TomB: I second what Pavlik said. Breakout sessions or panels or deep-dive groups, and report to the bigger group.
83 | * Ted: we could also use task forces (or working groups)
84 | * eP: if a topic is dominating the meeting space we can then create a task force
85 |
86 | ### Upcoming elections
87 | eP: we'll do them in November probably.
88 |
89 | ### participating in creating agenda
90 | eP: Please feel free to add things to meeting agendas, like demos
91 |
92 | ## Actions
93 |
94 | eP: reach out to Ruben about the name changes, then change the 11 issue names back.
95 |
--------------------------------------------------------------------------------
/meetings/2025-11-05.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-11-05T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Repository: https://github.com/solid/specification
6 |
7 | ## Chair
8 |
9 | * Michiel
10 |
11 | ## Present
12 |
13 | * Michiel
14 | * Erich Bremer
15 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
16 | * Michael Greig
17 | * Hadrian Zbarcea
18 | * [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)
19 | * Meem Arafat Manab
20 |
21 |
22 | ## Regrets
23 |
24 | ## Scribes
25 |
26 |
27 | ---
28 |
29 | ## Announcements
30 |
31 | * MdJ: 26 november will be the last time I chair, going travelling after that. There will be CG co-chair elections coming up soon, please consider volunteering! :)
32 |
33 | ### Meeting Guidelines
34 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
35 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
36 | * 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.
37 | * Join queue to talk.
38 | * 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.
39 |
40 | ### Participation and Code of Conduct
41 | * [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/)
42 | * [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/)
43 | * 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.
44 | * If this is your first time, welcome! please introduce yourself.
45 |
46 | ---
47 |
48 |
49 | ## Introductions
50 |
51 | * Meem: Doing PhD at ... Madrit. I'm integrating with data spaces. I will intorduce it to my superviser.
52 | * Michael: Product designer for about 8 years. Was working for consultatncy in US, now working in UK. After reading TimBLs memoir I found Solid. I resontate with the concerns Solid tries to solve about data owenership.
53 |
54 |
55 | ## Review Action items
56 |
57 | * HZ: to organize session about DIDs in Solid
58 |
59 | ## Topics
60 |
61 | ### Towards an end-to-end demo of Solid
62 | MdJ: We have partial demos of how Solid works but as far as I'm aware we can't show a full demo where:
63 | * the user authenticates to an app with their WebID
64 | * the storage is separate from the application
65 | * the app gets partial access (not root access) to the user's storage
66 | * BONUS: a second app can read and "understand" the data that the first app stored
67 |
68 | Some of us have had this goal since the start of the Solid project. What is holding us back from building it?
69 |
70 | We can use [SAI](https://solidproject.org/TR/sai) but there are no implementations of that available yet.
71 |
72 | We can tell people to hand-edit their ACLs but that's not really an acceptable demo in terms of UX, other than for power users.
73 |
74 | We can use [the app launcher based on ACP and type indexes](https://hackmd.io/@solid/cg-weekly) but this is not compatible with solidcommunity.net, with SolidOS, or with SAI.
75 |
76 | All in all there is nowhere where we can point interested people to try out a demo of Solid.
77 |
78 | MdJ: I think we sort of saw the limitations and stopped working on app authorization with ACLs after https://www.youtube.com/watch?v=5Q1nUmGdaXE&t=19s.
79 |
80 | We also discussed "Christoph's demo" (see Matrix chat):
81 | > From my experience of introducing people to Solid , the minimal demo that a user expects is (after signup - which is step 0) have a storage to put some data (even if it is a .pdf) and share that with another user. The fact that the same data can be used in different apps or by different users always came as a step 2. The critique always was along the lines of "well, then we just use drive/sharepoint/nextcloud" because this works the way the users are used to - when it comes to "control" who has access to your data.
82 |
83 | > As a side note: There is stuff out there that could be used by the community to build the desired simple data sharing.
84 | After addressing standing issues including https://github.com/solid/web-access-control-spec/issues/81,
85 | Look at demos from research/industry projects including https://purl.archive.org/mandatb2b/JWE2024 which showcases an Authorization App whose codebase is available github.com/DATEV-Research/Solid-authorization-app (granted not well-documented, but the stuff is there).
86 | >
87 | > I am in the progress of slowly extracting stuff from these things into repos that are better usable by the community.
88 | >
89 | >For example, the code of https://github.com/uvdsl/solid-oidc-client-browser was extracted from https://github.com/DATEV-Research/Solid-B2B-showcase-libs.
90 | Re-writing the AuthApp codebase to work with the Pods we have today rather than extended Pods with data registries etc. could bring us closer to the simple data sharing demo you are talking about...
91 |
92 |
93 | And we discussed how SAI could be implemented in the policy engine of CSS. https://github.com/CommunitySolidServer/policy-engine
94 |
95 |
96 | ### Pull Requests
97 |
98 | ### Tracking obstacles
99 |
100 |
101 | ## Actions
102 | * eP: send out the call for nominations for the chair elections
103 |
--------------------------------------------------------------------------------
/meetings/2024-06-26.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2024-06-26T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 | * Status: Agenda
8 |
9 |
10 | ## Present
11 | * [Michiel de Jong](https://michielbdejong.com)
12 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
13 | * Grace Elcock
14 | * [Jesse Wright](https://www.jeswr.org/#me) (jeswr)
15 | * Maxime Lecoq-Gaillard
16 | * [Rahul Gupta](https://cxres.pages.dev/profile#i)
17 | * Rui Zhao
18 | * [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/))
19 |
20 |
21 | ## Announcements
22 |
23 | * MdJ: Solid PoC presentation from SEMIC next Monday:
24 | * https://joinup.ec.europa.eu/collection/semic-support-centre/event/solid-poc-final-webinar
25 |
26 | ### Meeting Guidelines
27 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
28 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
29 | * 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.
30 | * Join queue to talk.
31 | * 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.
32 |
33 | ### Participation and Code of Conduct
34 | * [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/).
35 | * [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/)
36 | * 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.
37 | * If this is your first time, welcome! please introduce yourself.
38 |
39 |
40 | ### Scribes
41 | * Michiel
42 |
43 | ## Topics
44 |
45 | ### Some drafts need active editors
46 |
47 | * https://solidproject.org/TR/acp
48 | * https://solid.github.io/authorization-panel/authorization-ucr/
49 | * https://shapetrees.org/TR/specification/
50 | * eP: I could help with the last two, also planning to do some implementation work with `acp:vc` matchers
51 | * eP: I've been going over different drafts, to apply the template and the copyright, and it seems that some of them don't have active editors
52 | * eP: So I think we should try to figure out who wants to take ownership of each. For ShapeTrees, maybe Justin or Eric, I'll check with them,
53 | * eP: and willing to use with that one too.
54 | * eP: With the use cases one, I can also look how we can move it forward. It might be better to have one pool of use cases.
55 | * eP: The bigger question mark is ACP. Is Matthew still working with Inrupt? Is someone willing to keep iterating this spec? Someone other than me.
56 | * eP: I was hoping Hadrian would be here.
57 | * MdJ: thanks for working on this!
58 | * MdJ: if nobody's working on ACP then let's just leave it for the working group.
59 |
60 | ### Mapping Solid Ecosystem
61 |
62 | * eP: Jeff suggested that he will be able to present some of the work he has been collaborating on
63 | * eP: I started prototyping https://elf-pavlik.github.io/solid-efforts/
64 | * eP shares his screen and gives a demo
65 |
66 | ### A Solid implementation where each app gets their own folder
67 | * MdJ: After reading Noel's blog post, I wondered whether we should add this feature as a (security) recommendation. I can see pros (security) and cons (it steps off the path to, one day, inter-app interop).
68 | * eP: What's the degree of sandboxing? Could you do it with WAC. ACP has a client matcher. Can someone else access it too, then?
69 | * MdJ: I think with WAC, you would use ORIGIN, and with server side app, you would use WebID of that app. For other people to access data, isn't that an orthogonal problem?
70 | * eP: It depends what the app would let you do. if you access data you don't own, then it's not sandboxing. It's self-confining, you could also use cookie-based sessions or FTP then. You don't need the complexity of Solid.
71 | * MdJ: Ah, but you would separate the storage from the application.
72 | * eP: If you only want to use it with your own data, this could work.
73 | * MdJ: So what about the [autonomous data manifesto](https://autonomous-data.noeldemartin.com/architecture.html#the-autonomous-data-manifesto)?
74 | * eP: You mean like IndieWeb?
75 | * MdJ: Let's think of apps you use by yourself. Image editor, shopping list, ...
76 | * eP: Even here, I may want to let my spouse add something to the shopping list.
77 | * MdJ: Think of a normal app where you can create an account. Now, you apply autonomous data manifesto. Then, I choose to store it in my pod. Provider can't store this data, and has to describe model of that data. With Google, one could download a zip archive of the data.
78 | * eP: Ok so it could work if everyone is using the same app, how does it take us closer to them more ambitious goal of users haing freedom to choose their app?
79 | * eP: Which party is responsible for setting access on that app-specific container?
80 | * MdJ: NSS has this trusted apps array, which provides ... There is a dialog which asks if you want to let app access your pod.
81 | * eP: That should work where IdP and storage are coupled. Together they could set the permission during the auth redirect flow.
82 | * eP: WAC origin will fail if malicious app is running server side.
83 |
84 |
85 | ### How is app origin linked to OIDC audience
86 | We talked about this link, and thought it's probably useful to add to the security best practices that a server should never trust the HTTP Origin
87 | header as a way of determining the app's origin. Instead, it should use the audience or azp of the OIDC token.
88 |
--------------------------------------------------------------------------------
/meetings/2024-04-10.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2024-04-10T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 | * Status: Published
8 |
9 |
10 | ## Present
11 | * Hadrian Zbarcea
12 | * [Rahul Gupta](https://cxres.pages.dev/profile#i)
13 | * Maxime Lecoq-Gaillard
14 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
15 | * [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/))
16 |
17 | ## Announcements
18 |
19 | ### Meeting Guidelines
20 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
21 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
22 | * 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.
23 | * Join queue to talk.
24 | * 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.
25 |
26 | ### Participation and Code of Conduct
27 | * [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/).
28 | * [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/)
29 | * 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.
30 | * If this is your first time, welcome! please introduce yourself.
31 |
32 |
33 | ### Scribes
34 | * Hadrian Zbarcea
35 | * elf Pavlik
36 |
37 | ### Introductions
38 |
39 | * [name]
40 |
41 | ---
42 |
43 | ## Topics
44 |
45 | ### Co-chairs Rotation Schedule
46 | URL: https://github.com/solid/specification/discussions/618
47 |
48 | * hz: Just a reminder.
49 |
50 | ### Special Topic Meetings
51 | URL: https://github.com/orgs/solid/projects/16/views/1
52 |
53 |
54 | ### WG Charter Update
55 |
56 | * hz: none today
57 |
58 |
59 | ### WIP Implementation Feedback
60 |
61 | ### Discussion #555
62 | URL: https://github.com/solid/specification/issues/635
63 |
64 | * HZ: Virginia marked #555 as `archived`, I think this issue can be closed
65 | * HZ: no objections, will close
66 | * RG: what about 635? let's ask Ted what he needs done
67 | * HZ: let's wait for Ted
68 |
69 | ### WG Charter
70 |
71 | #### Tantek's feedback re 2 / 3 chairs
72 | URL: https://github.com/solid/solid-wg-charter/issues/66
73 |
74 | * VB: PAC, any status update on this?
75 | * HZ: I don't think is up to them (AB?) to decide how the W3C team selects it's chairs
76 | * HZ: I don't think it's up to the CG; we don't need to deal with it
77 | * RG: PAC is not here
78 | * eP: let's better wait for PAC
79 |
80 |
81 | #### Add Explainer
82 | URL: https://github.com/solid/solid-wg-charter/issues/52
83 |
84 | * VB: Can this issue be closed given reference to *an explainer* in https://github.com/solid/solid-wg-charter/blob/004ba63e1b76715a4c72b5d6147c9eca6a9c7ee5/charter/index.html ?
85 | * RG: I asked Tim to also do explainer for client-to-client specs.
86 | * RG: I shared the current explainer with various communities and the client-to-client part was hard to explain.
87 | * HZ: since it is out of scope for the WG, should we just mention that eventually this will be requried?
88 | * HZ: I can reach out to the Solid team asking for the status.
89 |
90 | #### Clarifying "Achieve Them" in Deliverables Section
91 | URL: https://github.com/solid/solid-wg-charter/issues/45
92 |
93 | * VB: If no proposal to improve, can we close this issue or do you prefer to wait for a PR?
94 | * eP: More confortable if PAC handles this and everything WG charter related. He can ask us for help whenever needed.
95 |
96 | #### Does the value come from the protocol or the applications?
97 | URL: https://github.com/solid/solid-wg-charter/pull/71
98 |
99 | * eP: More practical to leave it to PAC
100 |
101 | ### New Work Item C2C: Project Management
102 | URL: https://github.com/solid/specification/issues/641
103 |
104 | * eP: see also https://github.com/solid/specification/discussions/554
105 | * HZ: I was looking at contacts and it doesn't look very active. I'm afraid that we are starting work items which are going nowhere.
106 | * RG: I think the question is, is there someone to work with Pavlik to work on it?
107 | * MLG: I see two levels of interop. The client-to-client ??? . The other one is generic interop, where two apps from two different domains can interop.
108 | * eP: There is also overlap between the domains, we don't have hard boundries in real life and there is always interweaving.
109 | * HZ: is it Solid CG or contrib? I think CG is too general.
110 | * RG: what do you see the scope of CG? It seems protocol related work.
111 | * TT: it sounds like you ask for a task force within CG.
112 | * eP: if we already have SAI and type indexes, I agree with having a new repo for that. I will create a PR to the shapes repo; we don't need a full spec. This will allow us to validate our assumptions. I will build on top of SAI.
113 |
114 | ACTION: eP to make PR to https://github.com/solid/shapes
115 |
116 | ### Partial contact information sharing
117 | URL: https://github.com/solid/contacts/issues/5
118 |
119 | * eP: [ranting about access control and resource level assumption]
120 | * RG: One can mint a new URL. I'm skeptical about sub-resource access control. Even TrinPod assigns a URI to each triple.
121 | * eP: [ranting more about lack of process to evaluate proposals agains use cases]
122 |
123 | ACTION: HZ to add STM for how we work with use cases & requirements, and evaluate proposals based on that
124 |
125 | ### Proposal for integrating DIDs into Solid
126 | URL: https://github.com/solid/specification/issues/629
127 |
--------------------------------------------------------------------------------
/meetings/2025-01-29.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2025-01-29T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 | * Status: Agenda
8 |
9 |
10 | ## Present
11 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
12 | * Hadrian Zbarcea
13 | * [Pierre-Antoine Champin](https://champin.net/#pa)
14 | * [Rahul Gupta](https://cxres.pages.dev/profile#i)
15 | * Theo
16 | * Michal
17 | * [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/))
18 |
19 |
20 |
21 | ## Announcements
22 |
23 | ### Meeting Guidelines
24 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
25 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
26 | * 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.
27 | * Join queue to talk.
28 | * 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.
29 |
30 | ### Participation and Code of Conduct
31 | * [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/).
32 | * [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/)
33 | * 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.
34 | * If this is your first time, welcome! please introduce yourself.
35 |
36 |
37 | ### Scribes
38 |
39 | * elf Pavlik
40 |
41 | ## Topics
42 |
43 | ### [New Work Item] ActivityPub/Fediverse interoperability
44 |
45 | https://github.com/solid/specification/issues/708
46 |
47 | * eP: It is just an announcement. Next week I hope to bring it up for a vote.
48 | * PAC: It is important to have people from Social Web CG also involved. We need consistent story about Solid and Activity Pub.
49 | * HZ: Question to PAC: Isn't it more important to bring it to LWS WG?
50 | * PAC: The charter mentions Social Web CG as a contact that we will synchronize with. There is no active Social Web WG. WGs have active scope; they need to sync. What we are discussing isn't directly in the scope of the LWS WG.
51 | * HZ: What is the best path forward to bring it to LWS?
52 | * PAC: This is less urgent for the WG; at this moment, the WG is focused on use cases. I don't expect strong coupling with Social Web CG. This work item should be a joint work, in my opinion. Hopefully it will progress in CGs, and we will have better understanding how to progress.
53 | * RG: The way we were discussing it yesterday, it will be a layer on top of Solid, not something in the Solid spec. Everything should be workable as a layer on top of solid.
54 |
55 | ### State of CG reports
56 |
57 | https://www.w3.org/2024/09/linked-web-storage-wg-charter.html#dependencies
58 |
59 | > Depending on the Working Group progress, including consideration for adequate implementation experience, the Group may also decide to adopt the following dependencies as input documents
60 |
61 | * eP: It sounds like Solid-OIDC, ACP, WAC, and Solid Notifications **MAY** be adopted by the WG. Where should new implementation/deployment feedback be directed meanwhile?
62 | * eP: Possible inspiration for CG-WG coordination: https://github.com/w3c-fedid/Administration/blob/main/proposals-CG-WG.md
63 | * PAC: WG says that, at this moment, those reports are not formally considered as inputs from CGs. I would consider it OK to continue working on those reports in Solid CG. LWS WG may at some point signal that it wants to take over a specific report.
64 | * PAC: As for incubation in FedCM community group, I assume that this is browser-centric and it may relate to how the browser vendors work. It might not transfer well to our community.
65 | * eP: ...
66 | * RG: I have a larger criticism of the process. The whole requirement that you need to be an invited expert or paid member to participate. For example, I was refused to even observe the LWS WG meetings. I think this might be a problem.
67 | * eP: ...
68 | * RG: The minutes give some idea. Aaron asked me to raise use cases that I mentioned during the TPAC. When I asked to observe the relevant meeting, I was refused.
69 | * PAC: It is inaccurate to say that non-IE or non-members are not allowed. Chairs can invite observers to any meeting. I wasn't aware of your request. The process allows it, and it would make sense for you to be there if the use case you proposed is going to be discussed. On the other hand, having dozens of observers at every meeting would not work. I will follow up with the chairs to better understand your specific case.
70 |
71 | ### Aligning Authentication
72 |
73 | https://hackmd.io/8g6Lh81STPiXRInv8fBL_g
74 |
75 | * eP: what are the next steps?
76 | * RG: On March 16th, I plan to go to IETF. I can speak with SPICE.
77 |
78 | ### High level Solid Overview - reference
79 |
80 | * RG: I was approached by NDN. They are writing a paper which has a write-up on Solid. I found it dated; for example, term `pod` is not official. Can we have a cohesive explanation of Solid which is more technical than advertisement on solidproject.org? We can then point people to it to get an overview of Solid.
81 | * eP: Something like ?
82 | * RG: Maybe, but more detailed.
83 | * RG: Also the client-client standards are inadequately discussed in documents.
84 |
85 | ACTION: eP follow up on client client / interop effort.
86 |
87 | * RG: On C2C standards, we wanted to get feedback from Tim as soon as he's back.
88 | * RG: I want to tap into the collective intelligence of everyone who contributed to Solid.
89 | * eP: Maybe you could post on CG mailing list and/or on Solid Forum?
90 | * RG: In some time, I will.
91 |
--------------------------------------------------------------------------------
/meetings/2020-04-24.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2020-04-24
4 | * Duration: 90 minutes
5 | * Purpose: Meeting on Solid specifications; status, editorial
6 | * Call: https://global.gotomeeting.com/join/934529805
7 | * Chat: https://gitter.im/solid/specification
8 |
9 | ## Present
10 |
11 | * Justin Bingham
12 | * Sarven Capadisli
13 | * Ruben Verborgh
14 | * Dmitri Zagidulin
15 | * Tim Berners-Lee
16 |
17 | ## Scribes
18 |
19 | * Sarven Capadisli
20 |
21 | ## Agenda
22 |
23 | * Status update on work in progress eg. https://github.com/solid/specification/projects/1
24 | * Separating ecosystem document
25 | * Auxiliary Resources - https://github.com/solid/specification/pull/156
26 | * Rough consensus items: https://github.com/solid/specification/pull/157
27 | * Approach for WAC
28 | * Websockets / Notifications
29 |
30 | ## Minutes
31 |
32 | ### Status of PRs
33 |
34 | * SC: Commits in https://github.com/solid/specification/pull/157 reflect criteria that had rough consensus on it. Text may not be perfect but it covers what we've agreed on already.
35 |
36 | * JB: We are okay to merge things into master as long as issues are identified inline
37 | * RV: +1
38 | * DZ: +1
39 |
40 | * JB: https://github.com/solid/specification/pull/156
41 |
42 | ### Authorization
43 |
44 | * SC: Where should WAC live long-term? How should it evolve?
45 | * DZ: Pull it into the main solid repository. Solid-specific flavor of WAC.
46 | * TBL: Most important is that we have something up to date, works with tests. Should be only one WAC spec. Community does not need fragmentation.
47 | * RV: Which one are we talking about? There is a document in w3c space and people have complained.
48 | * DZ: There are three - original task for community note and [wiki page](https://www.w3.org/wiki/WebAccessControl), our github repo, [OpenLink Software's](https://www.openlinksw.com/describe/?url=http%3A%2F%2Fwww.openlinksw.com%2Fontology%2Facl%23&graph=urn%3Aontology%3Asemantic%3Amapping&graph=urn%3Aontology%3Acartridges%3Amapping&graph=urn%3Aopl%3Ashop%3Aoffering%3Asponging%3Acache%3Aofficial&graph=urn%3Aopenlink%3Aschema%3Ageneral%3Amappings&graph=urn%3Aopenlink%3Aschema%3Aoplweb%3Amappings&graph=urn%3Acartridges%3Amapping&graph=urn%3Adata%3Aopenlink%3Aproducts&graph=urn%3Adata%3Aopenlink%3Aglossary&graph=urn%3Adata%3Aopenlink%3Awebsites)
49 | * SC: Can the core vocab be carried with the solid project? Key point is that we only have one core WAC. Look for common terms shared across these versions. Have consensus on how we bring these together into ACL vocab.
50 | * SC: Can we create WAC document to solid/specification repo and then have pointers to the one in solid/specification?
51 | * TBL +1
52 | * JB +1
53 | * DZ +1
54 | * SC: We should go through issues and PRs in WAC first and close them out or transfer them into document
55 | * TBL: We have Basic WAC for conformance and Extended WAC with more advanced features
56 | * JB +1
57 | * SC: We need to consolidate as much as possible
58 |
59 | ### Websockets=
60 |
61 | * SC: Have categorized issues in the project board - https://github.com/solid/specification/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+events+and+notifications%22
62 |
63 | * SC: Is the focus to get a stable version out, and then deal with the extended version later, with the exception of authentication?
64 | * JB: Stable vs. Extended?
65 | * SC: Stable: All new features but authentication should be put off for later
66 | * RV: Now that we have a version number included it will help with backward compatibility
67 | * TBL: Need to have more explanation of what is implied by version numbering scheme
68 | * RV: Don't want people to misinterpret insecure version as intent::
69 | * TBL: Explain that in the specification, not the protocol
70 | * RV: Use 0.1 as current state, and go to major version with secure protocol.
71 |
72 | * SC: Alternative approaches for Notifications
73 | * SC: WebSocket, Websub, Push Notifications, LDN, etc - people are raising them for different use cases
74 | * JB: Websockets are a medium for delivering notifications, but we should also eventually support others, and should have a way that we determine what notifications are delivered.
75 | * TBL: Need to get the standard websocket support prioritized and working. Notifications are a different cycle. If I @mention you (for example), that should then be able to use another notification system to send you a ping.
76 | * JB: If we ultimately focus on two categories - what kind of things are of interest and how to notify people when things of interest happen
77 |
78 | ### Definition of Terms
79 |
80 | * DZ: Should we have an overall definition of terms used for Solid. Example - authentication spec explains terms for clients. Example - data owner vs. data controller.
81 | * SC: In ecosystem spec we have a definition section. Can we use that?
82 | * JB: +1
83 | * SC: +1
84 | * DZ: +1
85 |
86 | ## Outstanding pull requests on spec repo
87 |
88 | * https://github.com/solid/specification/pull/114 - Rename WebID-OIDC to Solid-OIDC
89 | * RV: Felt that Solid was too narrow, but open to an approach that encompasses other things like DID
90 | * JB: Can we agree that in writing the Solid Protocol spec we ensure that we don't forbid other identity systems that satisfy base requirements (i.e. DID)
91 | * SC: +1
92 |
93 | * https://github.com/solid/specification/pull/89 - Update LICENSE.md
94 |
95 | * JB: Who should we put for the copyright? Can we attribute to W3C community group
96 | * TBL: Look into attributing to W3C
97 | * SC: Will follow-up with someone at W3C to determine
98 | * SC: Consider CC0
99 | * JB: Can we create an issue and track this
100 |
101 |
102 | ## Secure data storage working group has started up - Joint W3C / DIF
103 | * Effects some of the standard work we're doing
104 | * Specifically deals with encrypted data storage
105 | * Specification specifically says authn and authz should be configurable and pluggable
106 | * We can make a good case that updated WAC approaches is valid as a supported mechanism
107 | * Solid is specifically mentioned in the charter of the working group
108 |
--------------------------------------------------------------------------------
/meetings/2023-03-22.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Weekly
2 |
3 | * Date: 2023-03-22T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://gitter.im/solid/specification
6 | * Repository: https://github.com/solid/specification
7 | * Status: Published
8 |
9 | ## Present
10 | * elf Pavlik
11 | * Matthias Evering (https://solidweb.me/testpro/)
12 | * April Daly
13 | * Huw Diprose
14 | * Kurt Cagle
15 | * Tim Berners-Lee
16 | * Michal Z.
17 | * Pierre-Antoine Champin
18 |
19 | ---
20 |
21 | ## Announcements
22 |
23 | ### Meeting Guidelines
24 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
25 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/solid/specification/blob/main/meetings/README.md).
26 | * 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.
27 | * Join queue to talk.
28 | * 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.
29 |
30 | ### Participation and Code of Conduct
31 | * [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/)
32 | * [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/)
33 | * 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.
34 | * If this is your first time, welcome! please introduce yourself.
35 |
36 |
37 | ### Scribes
38 | * April Daly
39 |
40 | ### Introductions
41 | * name: text
42 |
43 | ---
44 |
45 |
46 | ## Topics
47 |
48 | ### Implementation Feedback
49 | * SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
50 |
51 |
52 | ### AuthN and AuthZ Server side clients (apps)
53 | URL: https://github.com/solid/specification/issues/504
54 |
55 | * eP: Mostly focused on solid clients, running on servers. The backend is acting as the solid client for this.
56 | * eP: Listed a few clients but the list is not complete.
57 | * eP: working on authorization agent that uses solid storage. In some cases it acts as a server side client.
58 | * TBL: If a pod implements WAC, then it has to provide access to the group (root?)(???)
59 | * eP: In that case, the solid server itself will act as a client
60 | * eP: I propose to focus on three design principles, and see if we can agree on them. Hope these will act as "stakes in the ground".
61 | 1. Server-side clients can manage the private key
62 | * Security is based on signing (???) between the server ..
63 | * DPoP is a secondary signing (short lived keys for the session)
64 | * Reliable management of private keys is possible; we don't have to have the authority delegated to some ID Provider. The client can maintain their own keys.
65 | 2. Server-side clients should be able to authenticate independently from the end-user
66 | * Currently, there is the WebID claim for the end user; there is also the ACP claim thats identifying the client itself. The client has their own clientID/webID; so does the openID provider.
67 | * In the case of server side, we don't need this coupling of client and user, it could have it's own ID, and we might not want to couple these two for authorisation
68 | 3. Resource Server has an associated Authorization Server
69 | * There's also the issue of delegation. There's still an aspect that whenever we have a request, we'll need to know that "this client" acts on behalf of "this user". Here we're stepping beyond (??).
70 |
71 | ACTION: eP to create an issue with overview of end user delgating to app (client) cases, requirements, and prior discussions
72 |
73 | ### Auxiliary Resources with own Access Controls
74 | URL: https://github.com/solid/specification/issues/501
75 |
76 |
77 |
78 | ### Resource state changes and differences
79 | * SC: We can revisit the state of below issues (topics) and look at next steps.
80 |
81 | #### Standardizing state changes in resources (history, undo, sync)
82 | URL: https://github.com/solid/specification/issues/161
83 |
84 | #### Evaluate existing RDF delta/diff formats
85 | URL: https://github.com/solid/notifications/issues/157
86 |
87 | * SC: Move work to solid/specification?
88 | * eP: Question to PAC about latest work on deltas in RDF, maybe the [Canonicalization WG](https://www.w3.org/groups/wg/rch)
89 | * TBL: `rdflib` can handle deltas already. Data doesn't have an ocean of blank nodes. No need to panic about blank nodes and diffs. If we have a format in which client sends a patch to the server, the same format can be interpreted by the client if received in the notification.
90 | * PAC: I totally agree with Tim; blank nodes are not so bad in practice. The canonicalization algorithm could be a one way to use in patch. Again as Tim said, it could be overkill; in most cases, `WHERE` clauses are easier to identify those blank nodes.
91 | * TBL: Maybe the metadata that is added to notifications. The changelog is not only the changes, but also the basic stuff you need to undo, blame; basically, offline first.
92 | * eP: Authorization system would need to take it into account, if we disclose who made the change to the resource.
93 | * TBL: Concept of "who is the creator of the document" is important
94 |
95 | ---
96 |
97 | ### Solid WG
98 | URL: https://github.com/solid/solid-wg-charter
99 |
100 | * Proposed by PAC
101 | * PAC: The work is progressing; soon we will submit the proposal to horizontal review. When this is done, it will go to members for their approval. Don't hesitate to have another look at the charter.
102 | * PAC: I would like to set up a poll, as was done for previous charter. It was called "expression of support or interest". People and organizations could record interest in the future working group.
103 |
104 |
--------------------------------------------------------------------------------
/meetings/2022-06-15.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2022-06-15T13:00:00Z
4 | * Call: https://meet.jit.si/solid-specification
5 | * Chat: https://gitter.im/solid/specification
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Present
9 | * [Sarven Capadisli](https://csarven.ca/#i)
10 | * Kjetil Kjernsmo
11 |
12 | ---
13 |
14 | ## Announcements
15 |
16 | ### Meeting Recordings and Transcripts
17 | * 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.
18 | * Join queue to talk.
19 |
20 |
21 | ### Participation and Code of Conduct
22 | * [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/)
23 | * [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/)
24 | * 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.
25 | * If this is your first time, welcome! please introduce yourself.
26 |
27 |
28 | ### Scribes
29 | * Sarven Capadisli
30 |
31 |
32 | ### Introductions
33 | * name: text
34 |
35 | ---
36 |
37 |
38 | ## Topics
39 |
40 | ### Storage description
41 | URL: https://github.com/solid/specification/issues/355
42 |
43 | >ACTION: Follow up in issue 355. KK, SC.
44 |
45 | * KK: I commented and then..
46 | * SC: What's next?
47 | * KK: Was looking for the old websocket code on the client side. TIm said it was in the SolidUI but I couldn't find it there. Searched Update-Via, websocket.. but nothing active or a sign of implementation. I'll reach out to Timea.
48 | * SC: But for 355 to be PR'd, do we need a bit more support from the community e.g., an "intent" to implement something along those lines? So far I implemented but there should be others - besides the authors/editors (towards adequate implementation experience).
49 | * KK: I say we just PR and see what kind of support we. However, I think we also should reach out in storage description issue in same outreach.
50 | * SC: I'm fine to PR but we've been reaching out in the issue for *a long time* time. Not much signal there. We have support from the editors but not implementers.
51 | * KK: Then we reach out personally. How about private implementations?
52 | * SC: We can do that.
53 | * SC: I'll just wrap it up and PR and run all of these things at once.
54 | * KK: Okay!
55 |
56 |
57 | ### Actions from last Agenda Overview
58 | >ACTION: After resolving storage description, update ED to say MUST new/MAY old, SC.
59 | >ACTION: Publish 0.9.1 with that ED, SC.
60 | >ACTION: Update ED version. Include a change log for 0.9.1, SC.
61 | >ACTION: Reach out to solid-ui maintainers
62 | >ACTION: Ask in Solid/chat whether there are more WebSocket implementations.
63 |
64 | * SC: No update here.
65 | * KK: Right. We need to do the outreach quite urgently, I think.
66 |
67 |
68 | ### TPAC 2022
69 | URL: https://gitter.im/solid/specification?at=6299faf8da83520ac361f875
70 |
71 | * SC: Thoughts? There is a fee but it can be waved. I'll have to doublecheck whether it is required for CG breakouts (IIRC, last year there wasn't one.) How about the time slot?
72 | * SC: Oh, I do have a minor update. Checked with the W3C Events Team, and 15:30 UTC may work best on 2022-09-14 and online-only. Still need to confirm if that's possible.
73 | * KK: I'd love to do a F2F, but have a hard time going all the way to Vancouver
74 | * SC: I won't be at F2F.
75 |
76 |
77 | ### Add WebID Profile as work item
78 | URL: https://github.com/solid/specification/pull/413
79 |
80 | * SC: I reviewed. Was involved in the UD (as contributor, not editor). Additional reviews needed. I suspect there would be no objections to accept as work item.
81 | * KK: I'll review now... Approved.
82 |
83 |
84 | ### Add Test Suite Panel Charter. Update Panels
85 | URL: https://github.com/solid/process/pull/288
86 |
87 | * SC: This is deemed to be necessary to have a mutual understanding for a bunch of interrelated work.
88 | * KK: I haven't been following in detail.
89 | * KK: There are a quite a few comments open. Can they be resolved, so it is easier to review?
90 | * SC: Resolved all related to the Charter. One open one on the panels document. You're clear to review/comment.
91 | * KK cool, I'll try to find time.
92 |
93 |
94 | ### Add license
95 | URL: https://github.com/solid/specification/pull/412
96 |
97 | * KK: IANAL!
98 | * SC: That's my line. I'm suing you!
99 | * KK: I suppose you weren't enough on /.
100 | * KK: The final details for adding correct years.. I mean.. argh..
101 | * SC: The main thing is really about whether we link to a license document with a copyright.
102 | * KK: If you don't say anything, the usual copyright law has to be assumed. By adding a license we are giving permissions that they didn't have to begin with. The only thing is we give them freedom with that document. It seems to me that we aren't trying to restrict anything, we are just granting permissions. Therefore, I'm not sure how much could go wrong.
103 | * SC: We do state "MIT License" and the Copyright to the CG in the TRs but it is not the full license text. We do link to an MIT License template but I think that's not correct way of doing this. It needs to state actual years and entity that holds the copyright.
104 | * KK: We could state the one liner and link to the MIT license. Wouldn't that be sufficient?
105 | * SC: That's what we do but I don't find the current link is used correctly.
106 | * KK: Let me just restate IANAL. If this is complex, then we're not the ones who should decide.
107 | * SC: But wait. There is no particular controversy on this approach. Just need group understanding/practise. Because we will then go ahead with link to a human- and machine-readable license document that has our info.
108 | * KK: Alright. Sounds good to me.
109 | * SC: Then please review and let's get more people to review/acknowledge.
110 |
--------------------------------------------------------------------------------
/meetings/2022-03-30.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2022-03-30T13:00:00Z
4 | * Call: https://meet.jit.si/solid-specification
5 | * Chat: https://gitter.im/solid/specification
6 | * Repository: https://github.com/solid/specification
7 |
8 |
9 | ## Present
10 | * [Sarven Capadisli](https://csarven.ca/#i)
11 | * [Justin Bingham](https://justin.bingham.id/me)
12 | * [Tim Berners-Lee](https://timbl.inrupt.net/profile/card#me)
13 | * [Kjetil Kjernsmo](http://www.kjetil.kjernsmo.net/foaf#me)
14 |
15 | ---
16 |
17 | ## Announcements
18 |
19 | ### Meeting Recordings and Transcripts
20 | * 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.
21 | * Join queue to talk.
22 |
23 |
24 | ### Participation and Code of Conduct
25 | * [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/)
26 | * [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/)
27 | * 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.
28 | * If this is your first time, welcome! please introduce yourself.
29 |
30 |
31 | ### Scribes
32 | * Sarven Capadisli
33 |
34 |
35 | ### Introductions
36 | * name: text
37 |
38 | ---
39 |
40 | ## Topics
41 |
42 | ### Peg meetings to UTC
43 | * KK: Set this meeting to 13 UTC?
44 | * SC: https://gitter.im/solid/specification?at=6238817a9bd1c71ecab2a936
45 | * JB: Agree. It'll keep us consistent. No matter what the fluctuations - worse is not knowing what you're adjusting against. I raised this in data-interoperability-panel and no one was against it.
46 | * TBL: Sure. it is difficult. To set your computer to UTC you have to go to the command-line. But you can put GMT. if yo ucan put it in a calendar it'll be fine.
47 | * KK: If the invite is in UTC, calendar will adjust.
48 | * SC: Recommendation: Pick earlier.
49 |
50 | ACTION: Everyone follow-up on documentation/announcements to use UTC.
51 |
52 |
53 | ### Add Solid-OIDC draft specification and primer to Solid Project
54 | URL: https://github.com/solid/specification/pull/386
55 |
56 | * SC: Any comments about the PR before ACTIONs?
57 | * KK: Haven't read but will review.
58 | * JB: I'll have to reveal. I've been familiar up to a month and a half because I mad a Java client implemntation. Part of the review I'll do next week, will look some of the changes incorporated and make sure the client implementation is inline with it. The latest draft ensures that it can support a flow where you're using in concert with authorization server ??? which I have no issues with. I don't have a ready test environment but I can make sure it works in a typical flow from an implementation standpoint. If ned be turned around this weekend, I can do this weekend.
59 | * KK: I'm coming at it from a different perspective. I'll review with the thinking that if I understand what's there then that's good. I haven't done implementations... which I think is also an important perspective to have.
60 | * SC: Along the lines of KK, and I'll focus more on general editorial advisement. I'll probabably won't make comments on specific technical decisions within.
61 | * JB: General question: I don't know if this effects this in a blocking way. It might be fine but I know that CSS is in the process of adding support for some of these updates. I don' tknow if it is complete yet. I know the spec will work - testing against the Java implementation. Do we have a stance or need a stance from an implementation standpoint - fully implemented by CSS or other open servers. There is client / server support.
62 | * SC: I think this issue touches on that https://github.com/solid/solid-oidc/issues/19 to perhaps help us inform on interest to implement/adoption/WIP.
63 | * TBL: I just noticed that . I was going to raise th emessage that re VC-people. They have a website.. and they don't have a current list of implementations. Any specific is good to have with implementations.
64 | * KK: Also goes into the discussion we had with versioning. We want to have these things going to REC. To version the Solid-OIDC spec as 1.0 proper, we need those implementations. But not to publish it as a CR. When we have reviewed it, and agree to add as CR to community Reports.
65 | * SC: The proposal is raised as an equivalen to FPWD. We may not need to weigh too much on the implementations. It is nice to have but not strictly necessary. Following PRs/releases we may put more weight.
66 | * JB: This can be good context to include in the contributing document. Instead of recapping we can link to them.
67 | * SC: Sounds good. I didn't hash out all the details. I also wanted to get into the kind of fields/information that must be in the spec.
68 | * SC: Tim?
69 | * SC: We need to resolve the versioning convention that we are going with. The current PR is CG-DRAFT. WAC is Draft, Protocol is Version 0.9.0. What else?
70 | * TBL: I thought we came to the consens last time. KK said when a change is made the number is changed. I think it should have a version number like semver. A sort of a CR.
71 | * KK: I tink we should also call this as a 0.9. And WAC should as well.
72 | * TBL: They don't have to line up.
73 | * SC: Use 1.0-{state}
74 | * JB: We can decide to set them to 0.9 or whatever. They should be able to evolve individually. Otherwise stamping one you'll have to go to the other.
75 | * TBL: They're absolutely not in sync.
76 | * SC: On that note, WAC will have a new publication because most importantly the acl-link-relation is accepted to be reviewed by IANA and inclusion in the registry: https://github.com/protocol-registries/link-relations/issues/32 . Should WAC be 1.0-x?
77 | * SC: General consensus: WAC 1.0-PR (without acl:client) and WAC 1.1-CR with acl:client
78 | * SC: Then Solid-OIDC is 1.0-FPWD?
79 | * KK: How about 1.0-WD.1 (1.0-WD.x)?
80 | * SC: +1
81 | * JB: +1
82 | * TBL: +1
83 |
84 | ACTION: KK, JB, SC to review PR.
85 |
86 | ### High-level spec feature road
87 |
88 | * TBL: FYI, I wanted to get feedback on this way of thinking.
89 | * SC: Works for me.
90 |
--------------------------------------------------------------------------------
/meetings/2022-04-27.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Solid Editors
2 |
3 | * Date: 2022-04-27T13:00:00Z
4 | * Call: https://meet.jit.si/solid-specification
5 | * Chat: https://gitter.im/solid/specification
6 | * Repository: https://github.com/solid/specification
7 |
8 | ## Present
9 | * [Sarven Capadisli](https://csarven.ca/#i)
10 | * Kjetil Kjernsmo
11 | * Justin Bingham
12 | * Tim Berners-Lee
13 |
14 |
15 | ---
16 |
17 | ## Announcements
18 |
19 | ### Meeting Recordings and Transcripts
20 | * 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.
21 | * Join queue to talk.
22 |
23 |
24 | ### Participation and Code of Conduct
25 | * [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/)
26 | * [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/)
27 | * 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.
28 | * If this is your first time, welcome! please introduce yourself.
29 |
30 |
31 | ### Scribes
32 | * Sarven Capadisli
33 |
34 |
35 | ### Introductions
36 | * name: text
37 |
38 | ---
39 |
40 | ## Topics
41 |
42 | ### Spec Tests
43 | * SC: Where the repos might end up as per solid/team request to move is a bit of a concern. Some moved to a location perhaps they shouldn't have just yet...
44 | * SC: I suggest that all test related repos - at least the work items - for the move should be done through test-suite panel but it is unclear because not everything is looked after that group e.g., solid-oidc-tests.
45 | * SC: Implementer doesn't exactly why they should use solid/test-suite or solid/specification-tests etc..
46 | * KK: Need to be careful about coverage.
47 | * JB: Would be great to have multiple tests fully complete but don't think we can.. neither test suite gives a definitive answer. Unclear what the groups agree on. And need to give clear guidance for the spec.
48 | * KK: Might be useful to look at where the disagreements are. Might be our fault or a test suite's fault. We need more resources to work on the tests.
49 | * TBL: every time we have an issue in the tests or they disagree, that's useful. if there was no disagreement then i'd suspect that the test suite hasn't ??? .
50 | * TBL: when e.g., solid chat breaks then write tests. so my apps don't break. and test that the pod will actually work / provide the functionality. people want solid to work in different ways. some ux to be smooth .. some secure. we have to be careful for people sneaking in to tweak the code.. more secure but then users can't figure out what's going on. that's where the spec is important / solid hits the middle ground.
51 | * KK: That's a good example of where we have a protocol independent thing.
52 |
53 |
54 | ### Milestone/Roadmap/Prioritisation meeting
55 | * SC: Are we on for 2022-04-28?
56 |
57 | ACTION: KK to propose doodle.
58 |
59 |
60 | ### Solid-OIDC and Solid-OIDC Primer
61 | * SC: https://solidproject.org/TR/2022/oidc-20220328 is published as Version 0.1.0.
62 | * SC: https://solidproject.org/TR/2022/oidc-primer-20220328 is published as Version 0.1.0.
63 | * KK: I tried to engage but it got merged - don't blame you for that but.. but I think it is difficult to understand the text that it is really about authentication. That is something that shouldn't have been published before clear.
64 | * TBL: You mean the text is obscure.
65 | * KK: It gibes me the impression that authn and authz is mixed. Mentions authz more than authn (like 3 times).
66 | * KK: TBL, you can also look at it to see what impression it gives you.
67 | * TBL: We should push back on two things being mixed.. and those things being separate in Solid. That's all we need from Solid OIDC .. to produce the user's id and that's it.
68 | * SC: We covered this last time.. and it was fine for ~FPWD/0.1.0.. clear enough in context of Solid OIDC spec.. but can be better outside/globally.
69 | * TBL: Solid UI and SolidOS.. with mashlib in it.. every time solid OIDC becomes with changes in an non-interoperable way. They should change the version / force you the change the major number.
70 | * JB: Our problem may be around versioning. Without saying the logic of our version scheme - what is implied. When I use semver 0.x
71 | * SC: Can I make a proposal on this? Relates to CONTRIBUTING.
72 | * JB: +1
73 | * KK: +1
74 | * TBL: +1 to Sarven adding to Contributing the essence of Justin’s attitude to version control — use semver, don’t use things 0.x.x.
75 |
76 | ACTION: SC to propose.
77 |
78 | * TBL: Can we do that for Solid OIDC?
79 | * SC: We did that already.
80 | * JB: For all specs.
81 | * KK: I'd like to express breaking change in RDF / change log. Some code in github action.
82 | * SC: Just want to do the simple bit for revision - like at the top of the document.
83 | * TBL: What would it be for WAC / 0.9?
84 | * TBL: Version number is independent of process and maturity. It can be a CR... etc.
85 | * SC: What should the next WAC be (the one with acl link relation stuff).
86 | * TBL: 1.1
87 | * KK: Version number is not detailing the changes.
88 | * SC: How about Notifications Protocol?
89 | * TBL: I suggest 1.0.
90 | * SC: But it is missing the bit on discovering storage description (see next topic.)
91 | * KK: So then we can't publish anything before 1.0?
92 | * SC: I suppose
93 | * KK: How about 1.0.0-ed.01 ?
94 | * SC: ... to be continued...
95 | * KK: PERMATHREAD.
96 |
97 |
98 | ### Notifications Protocol and WebSocketSubscription2021
99 | * SC: Can we wrap up the reviews for https://github.com/solid/specification/pull/391 and https://github.com/solid/specification/pull/392 this week?
100 | * SC: Related https://github.com/solid/specification/issues/355 but probably won't get that resolved before publishing 0.1.0.
101 | * SC: Have review from KK. would be nice to have more.
102 | * JB: Will look into it.
103 | * KK: I have no idea how WebSocketSubscription2021 will be for clients to move from the old/unsecure to new one.
104 |
--------------------------------------------------------------------------------
/meetings/2023-10-10.md:
--------------------------------------------------------------------------------
1 | # W3C Solid Community Group: Special Topic Meeting
2 |
3 | * Date: 2023-10-10T14:00:00Z
4 | * Call: https://meet.jit.si/solid-cg
5 | * Chat: https://matrix.to/#/#solid_specification:gitter.im
6 | * Repository: https://github.com/solid/specification
7 | * Status: Published
8 |
9 | ## Present
10 | * [Sarven Capadisli](https://csarven.ca/#i)
11 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
12 | * [Rahul Gupta](https://cxres.pages.dev/profile#i)
13 | * April Daly
14 | * Jeff Zucker
15 | * Tim Berners-Lee
16 |
17 | ---
18 |
19 | ## Announcements
20 |
21 | ### Meeting Guidelines
22 | * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
23 | * [W3C Solid Community Group Meeting Guidelines](https://github.com/solid/specification/blob/main/meetings/README.md).
24 | * 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.
25 | * Join queue to talk.
26 | * 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.
27 |
28 | ### Participation and Code of Conduct
29 | * [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/).
30 | * [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/)
31 | * 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.
32 | * If this is your first time, welcome! please introduce yourself.
33 |
34 |
35 | ### Scribes
36 | * Sarven Capadisli
37 |
38 | ### Introductions
39 | * name: text
40 |
41 |
42 | ---
43 |
44 |
45 | ## Topics
46 |
47 | ### Solid CG Repository
48 |
49 | * SC: Currently `solid/specification` is used for specifications as well as some contributing/process-like information. `solid/specification` should continue to serve as spec publication stuff for TR/ and ED/.
50 | * SC: There are some advantages to establishing `solid/solid-cg` (or `w3c/solid`) for CG process and other CG wide documents. It may not be suitable to move some existing documents (e.g., minutes) because it breaks URLs without proper redirect, so some consideration is needed.
51 | * TBL: Beware of moving things. Make links and lists of links. In general do not break things.
52 | * SC: We'll need to find and update all back-references to anything that is referring to the old URLs at least in the solid-universe of things.
53 |
54 | #### Rough Plan
55 |
56 | * Create `solid/solid-cg` repository.
57 | * TBL: Fine.
58 | * Copy/Move some assets from `solid/specification` to `solid/solid-cg`:
59 | * TBL: DO NOT move. Only copy per-repo things like CONTRIBUTING
60 | * SC: Okay, we can copy, and then update with links referring to the latest location
61 | * `CONTRIBUTING.md`
62 | * TBL: Copy it
63 | * `meetings/`
64 | * TBL: make new empty and link to old
65 | * Under [Discussions](https://github.com/solid/specification/discussions/):
66 | * [Self-Review Questionnaire for Chair Candidates](https://github.com/solid/specification/discussions/568)
67 | * [Disciplinary Policy, Process, and Procedures](https://github.com/solid/specification/discussions/576)
68 | * [Special Topic Meetings](https://github.com/solid/specification/discussions/555)
69 | * [Solid CG Meeting Data](https://github.com/solid/specification/discussions/564)
70 | * SC: Should deprecate in favour of [Solid Ecosystem Monitor](https://github.com/virginiaBalseiro/solid-ecosystem-monitor/)
71 | * [Solid CG Chair Election Procedure](https://github.com/solid/specification/discussions/582)
72 | * [Task Force](https://github.com/solid/specification/discussions/581)
73 | * Minor: possibly other material from `solid/specification` issues/PRs.
74 |
75 | ### Solid Process
76 |
77 | * Migrate some assets from `solid/process` to `solid/solid-cg`:
78 | * `solid-cg-charter.md` — used for developing the charter, where [w3.org CG pages](https://www.w3.org/community/solid/charter/) includes the latest published and effective version
79 | * `notifications-panel-charter.md` — possibly sunset and/or convert to task force
80 | * `test-suite-panel-charter.md` — possibly sunset and/or convert to task force
81 | * `solid-editors-tr-process.md` — needs re-review and integration in context of charter and `CONTRIBUTING`
82 |
83 | ACTION: Create draft PR marking assets as archived and liking to new locations.
84 |
85 | ACTION: Mark draft PR as ready to review once new locations are provided.
86 |
87 | * Jeff: PR should make it clear that intention is to move those assets out of `solid/process` repo.
88 | * TBL: It's good to have links in both directions; new version also should link to the previous version in `solid/process`
89 | * Jeff: My point is about who controls the repos; people need to understand who will be in the control of new repo.
90 |
91 | ACTION: eP to investigate [Github Code Owners feature](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)
92 |
93 | ### Panel Repositories
94 |
95 | * SC: Panel repos have minutes, issues/PRS, including UCR documents, surveys.
96 | * SC: Work items should move to their own repos if they don't have one already. (Each new work item should go into its own repo.)
97 | * SC: Use GitHub "Transfer" issues/PRs of specific work items from the panel repo to their own repo.
98 | * SC: Leave non-work item specific / exploratory / random issues as is in panel repo.
99 | * SC: Consider moving minutes from panel to `solid/solid-cg`'s `meetings/`? Needs to be cleaned-up — use Minutes Template, etc. — to be used by Solid Ecosystem Monitor. There may be multiple meetings on the same dates, so may need to consider directory/filename pattern.
100 |
101 |
102 | ### Solid Specification
103 |
104 | `solid/specification`
105 |
106 | * SC: TR/EDs that are taken up as deliverables in the WG would be frozen while WG is active.
107 | * SC: once WG expires, there still might be work needed with errata and future work.
108 | *
109 |
--------------------------------------------------------------------------------