├── 2021
    ├── protocol-20211217.html
    └── wac-20210711.html
├── 2022
    ├── acp-20220518.html
    ├── acp-code-20220518.css
    ├── acp-data-model-20220518.svg
    ├── acp-main-20220518.css
    ├── notifications-flow-discovery-subscription-20221231.svg
    ├── notifications-flow-receivefrom-20221231.svg
    ├── notifications-flow-sendto-20221231.svg
    ├── notifications-flow-source-20220509.svg
    ├── notifications-flow-target-20220509.svg
    ├── notifications-protocol-20220509.html
    ├── notifications-protocol-20221231.html
    ├── oidc-20220328.html
    ├── oidc-primer-20220328.html
    ├── oidc-primer-login-20220328.svg
    ├── oidc-primer-request-20220328.svg
    ├── oidc-sequence-20220328.svg
    ├── protocol-20221231.html
    ├── wac-20220705.html
    ├── websocket-subscription-2021-20220509.html
    └── websocket-subscription-2021-flow-20220509.svg
├── 2024
    ├── notifications-flow-discovery.20240512.svg
    ├── notifications-flow-receivefrom.20240512.svg
    ├── notifications-flow-sendto.20240512.svg
    ├── notifications-flow-subscription.20240512.svg
    ├── notifications-protocol-20240512.html
    ├── protocol-20240512.html
    └── wac-20240512.html
├── .editorconfig
├── .gitignore
├── CONTRIBUTING.md
├── ED
    ├── protocol.html
    └── qa.html
├── LICENSE.md
├── README.md
├── acp.html
├── ecosystem.html
├── index.html
├── meetings
    ├── 2020-04-03.md
    ├── 2020-04-08.md
    ├── 2020-04-24.md
    ├── 2020-04-27.md
    ├── 2020-05-15.md
    ├── 2020-05-22.md
    ├── 2020-05-29.md
    ├── 2020-06-12.md
    ├── 2020-09-04.md
    ├── 2020-11-06.md
    ├── 2020-11-19.md
    ├── 2020-11-30.md
    ├── 2021-01-04.md
    ├── 2021-02-16.md
    ├── 2021-03-02.md
    ├── 2021-04-06.md
    ├── 2021-04-22.md
    ├── 2021-05-04.md
    ├── 2021-06-01.md
    ├── 2021-06-15.md
    ├── 2021-06-22.md
    ├── 2021-06-29.md
    ├── 2021-07-06.md
    ├── 2021-07-20.md
    ├── 2021-07-27.md
    ├── 2021-08-03.md
    ├── 2021-08-10.md
    ├── 2021-08-31.md
    ├── 2021-09-14.md
    ├── 2021-09-22.md
    ├── 2021-09-29.md
    ├── 2021-10-06.md
    ├── 2021-10-20.md
    ├── 2021-10-21.md
    ├── 2021-10-27.md
    ├── 2021-11-03.md
    ├── 2021-11-05.md
    ├── 2021-11-10.md
    ├── 2021-11-17.md
    ├── 2021-11-24.md
    ├── 2021-12-15.md
    ├── 2021-12-22.md
    ├── 2022-01-05.md
    ├── 2022-02-02.md
    ├── 2022-02-15.md
    ├── 2022-03-09.md
    ├── 2022-03-30.md
    ├── 2022-04-11.md
    ├── 2022-04-20.md
    ├── 2022-04-27.md
    ├── 2022-05-11.md
    ├── 2022-05-18.md
    ├── 2022-05-25.md
    ├── 2022-06-01.md
    ├── 2022-06-08.md
    ├── 2022-06-15.md
    ├── 2022-08-17.md
    ├── 2022-09-14.md
    ├── 2022-10-12.md
    ├── 2022-10-19.md
    ├── 2022-10-26.md
    ├── 2022-11-02.md
    ├── 2022-11-09.md
    ├── 2022-11-16.md
    ├── 2022-11-23.md
    ├── 2022-11-30.md
    ├── 2022-12-07.md
    ├── 2022-12-14.md
    ├── 2023-01-04.md
    ├── 2023-01-18.md
    ├── 2023-01-25.md
    ├── 2023-02-01.md
    ├── 2023-02-08.md
    ├── 2023-02-15.md
    ├── 2023-02-22.md
    ├── 2023-03-01.md
    ├── 2023-03-08.md
    ├── 2023-03-15.md
    ├── 2023-03-22.md
    ├── 2023-03-29.md
    ├── 2023-04-05.md
    ├── 2023-04-12.md
    ├── 2023-04-19.md
    ├── 2023-05-03.md
    ├── 2023-05-10.md
    ├── 2023-05-17.md
    ├── 2023-05-31.md
    ├── 2023-06-07.md
    ├── 2023-06-14.md
    ├── 2023-06-21.md
    ├── 2023-07-05.md
    ├── 2023-07-12.md
    ├── 2023-07-19.md
    ├── 2023-07-26.md
    ├── 2023-08-02.md
    ├── 2023-08-09.md
    ├── 2023-08-16.md
    ├── 2023-08-23.md
    ├── 2023-08-30.md
    ├── 2023-09-06.md
    ├── 2023-09-11.md
    ├── 2023-09-19.md
    ├── 2023-09-20.md
    ├── 2023-09-26.md
    ├── 2023-09-27.md
    ├── 2023-10-04.md
    ├── 2023-10-10.md
    ├── 2023-10-11.md
    ├── 2023-10-18.md
    ├── 2023-10-24.md
    ├── 2023-10-25.md
    ├── 2023-11-01.md
    ├── 2023-11-08.md
    ├── 2023-11-15.md
    ├── 2023-11-22.md
    ├── 2023-11-29.md
    ├── 2023-12-05.md
    ├── 2023-12-06.md
    ├── 2023-12-13.md
    ├── 2024-01-09.md
    ├── 2024-01-10.md
    ├── 2024-01-17.md
    ├── 2024-01-24.md
    ├── 2024-01-31.md
    ├── 2024-02-07.md
    ├── 2024-02-14.md
    ├── 2024-02-21.md
    ├── 2024-02-28.md
    ├── 2024-03-06.md
    ├── 2024-03-13.md
    ├── 2024-03-20.md
    ├── 2024-03-27.md
    ├── 2024-04-03.md
    ├── 2024-04-10.md
    ├── 2024-04-17.md
    ├── 2024-04-24.md
    ├── 2024-05-01.md
    ├── 2024-05-08.md
    ├── 2024-05-15.md
    ├── 2024-05-21.md
    ├── 2024-05-22.md
    ├── 2024-05-28.md
    ├── 2024-05-29.md
    ├── 2024-06-04.md
    ├── 2024-06-05.md
    ├── 2024-06-12.md
    ├── 2024-06-19.md
    ├── 2024-06-26.md
    ├── 2024-07-03.md
    ├── 2024-07-10.md
    ├── 2024-07-17.md
    ├── 2024-08-07.md
    ├── 2024-08-07T12_00_00Z.md
    ├── 2024-08-21.md
    ├── 2024-08-28.md
    ├── 2024-09-04.md
    ├── 2024-09-11.md
    ├── 2024-09-18.md
    ├── 2024-09-27.md
    ├── 2024-10-02.md
    ├── 2024-10-09.md
    ├── 2024-10-23.md
    ├── 2024-10-30.md
    ├── 2024-11-06.md
    ├── 2024-11-13.md
    ├── 2024-11-20.md
    ├── 2024-11-27.md
    ├── 2024-12-04.md
    ├── 2024-12-11.md
    ├── 2024-12-18.md
    ├── 2025-01-08.md
    ├── 2025-01-15.md
    ├── 2025-01-22.md
    ├── 2025-01-29.md
    ├── 2025-02-05.md
    ├── 2025-02-12.md
    ├── 2025-02-19.md
    ├── 2025-02-26.md
    ├── 2025-03-05.md
    ├── 2025-03-12.md
    ├── 2025-03-19.md
    ├── 2025-03-26.md
    ├── 2025-04-02.md
    ├── 2025-04-09.md
    ├── 2025-04-23.md
    ├── 2025-04-30.md
    ├── 2025-05-07.md
    ├── 2025-05-14.md
    ├── 2025-05-21.md
    ├── 2025-05-28.md
    ├── README.md
    └── template.md
├── notification-subscription-types.html
├── notifications-protocol.html
├── oidc-primer-login.svg
├── oidc-primer-request.svg
├── oidc-primer.html
├── oidc-sequence.svg
├── oidc.html
├── protocol.html
├── protocol.timemap.html
├── solid.svg
├── wac.html
├── wac.timemap.html
├── websocket-subscription-2021-flow.svg
└── websocket-subscription-2021.html


/.editorconfig:
--------------------------------------------------------------------------------
 1 | root = true
 2 | 
 3 | [*]
 4 | charset = utf-8
 5 | end_of_line = lf
 6 | insert_final_newline = true
 7 | 
 8 | [*.html]
 9 | indent_style = space
10 | indent_size = 2
11 | 


--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | *.bs
2 | 


--------------------------------------------------------------------------------
/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 | 


--------------------------------------------------------------------------------
/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 | 


--------------------------------------------------------------------------------
/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 | 


--------------------------------------------------------------------------------
/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 | 


--------------------------------------------------------------------------------
/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-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/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/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-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/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 | 


--------------------------------------------------------------------------------
/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/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-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/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


--------------------------------------------------------------------------------
/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-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-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/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 | 


--------------------------------------------------------------------------------
/meetings/2021-03-02.md:
--------------------------------------------------------------------------------
 1 | # W3C Solid Community Group: Solid Editors
 2 | 
 3 | * Date: 2021-03-02
 4 | * Call: https://meet.jit.si/solid-specification
 5 | 
 6 | ## Present
 7 | * Justin Bingham
 8 | * Sarven Capadisli
 9 | 
10 | ## Scribes
11 | 
12 | * Sarven Capadisli
13 | 
14 | ## Agenda
15 | 
16 | * Announcements
17 | * Pull Requests
18 | * Issues
19 | * Topic Items
20 |     * Discuss WICG / WebID Meeting from February 22nd
21 |     * Prepare for W3C CredentialsCG Presentation (March 10)
22 |     * DID support - https://github.com/solid/specification/issues/217
23 |     * Publish / Subscribe
24 | 
25 | ## Minutes
26 | 


--------------------------------------------------------------------------------
/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-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/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/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-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/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-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 | 


--------------------------------------------------------------------------------
/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/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-08-03.md:
--------------------------------------------------------------------------------
 1 | # W3C Solid Community Group: Solid Editors
 2 | 
 3 | * Date: 2021-08-03
 4 | 
 5 | ## Present
 6 | 
 7 | - Justin Bingham
 8 | - Kjetil Kjernsmo
 9 | - Sarven Capadisli
10 | 
11 | ## Scribes
12 | - Justin Bingham
13 | 
14 | ## Agenda
15 | 
16 | - Notification / Secure Websockets
17 | - Current Month Milestone: https://github.com/solid/specification/milestone/4
18 | - Open PRs: https://github.com/solid/specification/pulls
19 | 
20 | ## Minutes
21 | 
22 | ### Notifications / Secure Websockets
23 | 
24 | KK: Ruben has action item to collect information on this
25 | 
26 | JB: Justin to recruit participants to the Notifications and Secure Websockets
27 | 


--------------------------------------------------------------------------------
/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-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/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/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-11-17.md:
--------------------------------------------------------------------------------
 1 | # W3C Solid Community Group: Solid Editors
 2 | 
 3 | * Date: 2021-11-17T14: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 | * Dmitri Zagidulin
13 | * Justin Bingham
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 | URL: https://github.com/solid/specification/pull/351
45 | 
46 | * KK: Tried PR 350 but didn't feel right. Created PR 351 off PR 341 (N3 Patch) which references existing definitions.
47 | * SC: That seems better.
48 | * JB: 351 is definitely an improvement. Good definition in SPARQL11. Our Terminology in Solid Protocol.. triple and triple pattern would seem to be useful enough in the Terminology section. We have other definitions defined elsewhere we reference. Personally I like this a bit more but I'd be fine with 351 because it sends you to the right place.
49 | * KK: That's what I tried in 350. But had to define IRI and bnode and literal. There are a lot of definitions we go in there. It is a balance with triple pattern in the SPARQL spec. It is not entirely easy to understand. Tried to have not quite a formal definition but that can be understood by broader audience.
50 | * SC: That's fine. The terms are used in context of the references.
51 | * SC: What would merging entail?
52 | * KK: It goes into PR 346.
53 | * SC: Close 350.
54 | * SC: Noting group agreement to merge 351.
55 | 
56 | ACTION: KK to merge 351 and close 350.
57 | 
58 | 
59 | ### Describe N3 Patch
60 | URL: https://github.com/solid/specification/pull/346
61 | 
62 | * KK: Seems to be in good shape now. Let's make sure to have all the ids right so we can hook other stuff (tests).
63 | * SC: I will review ASAP.
64 | 
65 | 
66 | ### Tighten consistency requirements for resource types
67 | URL: https://github.com/solid/specification/pull/341
68 | 
69 | * KK: Did this off a 0.9 milestone. Seems we won't be able to agree on that. I'm still taking that as today's deadline. I'd like to have legitimate tests that can point out semantic inconsistencies that could lead to social engineering hacks. That's where I'm going with this. If it is difficult to write this for normative requirements. It does change how NSS is working. CSS is close to doing this. It is NSS that is ignoring the Link headers which I think is bad in this case. So I don't know if we need to take time here or postpone this like I did to some other location/milestone..
70 | * SC: https://github.com/solid/specification/issues/301#issuecomment-970334856
71 | * KK: It doesn't matter what's in the spec because these are things in the wild. So, how do we constrain the spec so that the stuff in the wild don't have strange effects. It is very difficult because it tries to prevent certain attacks ??? There will  be people effected by it. The evil-path tests are designed to shake out what the server might be doing in the case of things in the wild. To help with certain misunderstanings. It is assuming that servers are not compliant and find ways where people might exploit that. The sentences you put forward,.. we can wordsmith.. I didn't interpret those as something what I've intended.
72 | * JB: I'd be a big supportor of consistency on typing. From an interop standpoint, being able to get some baseline from the server what the resource is based on what the resource is.. what is an RDF or Non-RDF source, being a container or not through the headers is.. I think for interop, any place where you get consistency is helpful. From a implementation standpoint, having written code that determines is a bit messy or makes me concerned. Essentially telling the clients to figure out.. it is not on us from the server, I think that's going to leave clients up to making incorrect choices. Possibly different servers making different ??? I think it'd be worth to provide more explicit typing and rules around it.
73 | * SC: ...
74 | * KK: What I really want to achieve for example that if ... so your point JB on the side is relevant but I'm trying to go beyond that. If client thinks something is an RDF source, that data will be out there. Somebody will write an RDF source, it simply goes into the data of the resource.
75 | * SC: ...
76 | * KK: I originally wrote some tests and noted some of them failing. ESS, NSS, CSS are all failing in different ways. You probably would expect the architecture.
77 | * SC: ...
78 | * KK: If you allow types of errors that NSS is expecting certainly going to end in disaster. The client is thinking that I have this type of abstract type. It is based on the assumption that the server is making. That is putting this.. the progammer will think that they are doing something ??? and someone else will engineer an attack. That is the attack that we should prevent. Therefore it is not sufficient non-normative statements because then we can't test. We need to have normative statements.
79 | * SC: ...
80 | * KK: BUT, as long as you have that kind of stuff in the wild, there are bound to be cases where there's...
81 | * KK: We can go through the tables that are there. If you can come up with normative .
82 | * SC: https://github.com/solid/specification/issues/301#issuecomment-970334856
83 | 
84 | 
85 | ### Specify existing practice for Container data about contents
86 | URL: https://github.com/solid/specification/pull/352
87 | 
88 | * SC: Follows ACTION of https://github.com/solid/specification/blob/main/meetings/2021-11-10.md#specify-existing-practice-for-container-data-about-contents
89 | 


--------------------------------------------------------------------------------
/meetings/2021-12-22.md:
--------------------------------------------------------------------------------
 1 | # W3C Solid Community Group: Solid Editors
 2 | 
 3 | * Date: 2021-12-22T14: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 | 
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 | ### Solid Protocol milestone
42 | * SC: Steps towards the publication of 0.9.x and 1.0.
43 | * KK: How do we get things into the milestone, getting implementers and stakeholders and also have commitments of time towards doing things that needs to be done.
44 | * KK: The previous milestone was to mandidate existing practice and yet we didn't have enough commitment to prioritise stuff and now we are brining more stakeholders and we need to have the ability to address that complexity. It is far too early to find the mandates and what issues should be in the milestone and think about in high-level on what we need for 1.0 or put off. Have higher-level things, break it down to issues, then have milestones.
45 | * JB: What's needed to getted into 0.9.x and where is that line drawn? At least document a practice.
46 | * KK: What don't yet have what's for 1.0 in public record.
47 | * SC: What we have is milestones on ~CR and ~PR that can be shuffled around as we did for ~FPWD milestone and 0.9.
48 | * KK: Those are your opinions what should be in there. I and other stakeholders have other opinions. We need to have consensus around what it is what we needed (on high level) and then milestone. And time commitments from various stakeholders.
49 | * SC: Need vision statement and a way to translate to milestones.
50 | * KK: We need a full day meeting.
51 | * JB: I agree. Information we got like from implementation feedback (re: other stakehodlers with opinions). I've followed on that session with Tim on the importance of well-porganised roadmap where we have doucmented feedback, support and reasoning is consumtable by stakeholders and give actual input and also input for process like this. When we talk about prioritisation, ... here is all the data to know how to prioritise. I was trying to reconcile on the feedback session,.. some of the stuff are on Tim's roadmap and at least try to put it into some structure that we can then at least look at and work from. In the SolidOS task manager some things may be miscategorised but that could be one effective one for everyone. At least there is a need to put the data together and organise so it can be consumed better.
52 | * KK: We also need a full view. We focus on the Protocol here but there is also the panel work that also takes time from us. We need to organise also with that to understand the time commitments. Like service to the community.. but we can't do that for a long time.
53 | * KK: Should we try to organise for first thing in new year to organise a time.
54 | * JB: half or full day?
55 | * KK: full.
56 | 
57 | ACTION: KK to organise a full day meeting for the editors group.
58 | 
59 | * SC: There are a lot of items in front of us that need to be dealt with that we can start / need to be working on right now. That should happen in parallel to the longer-term priotization that will unfold over a couple of months+
60 | * SC: Lets' come back to this in a January meeting.
61 | * SC: Do revisit issues/PR for 1.0 in milestone-next.
62 | * KK: Should we create milestone-0.9.1?
63 | * JB: So lets move the stuff we know into 0.9.1 milestone.
64 | 
65 | ACTION: KK to create 0.9.1 milestone.
66 | 
67 | 
68 | ### Solid Protocol Publication and Access
69 | * SC: PROPOSAL: The publication of the next release of the Solid Protocol specification (i.e., "v1.0", "~REC", or equivalent) MUST be accessible from a Solid server, along with all other resources under https://solidproject.org/ . To make it so we need commitment (issue/milestone..) and coordination from everyone that may be involved (Solid Team, server/app developers..).
70 | * JB: +1. It would be great to get some assistance ... A lot of the stuff ends up being administrator or any of that stuff tends to funnel down to me - I'm happy to do - but we should try to bring people together, including some of us. It is not insignificant work but stuff related to current composition of the site (sp.org) - there is deployment, re KK's point about doc changes, releases to the spec and those need to be autopublished and correctly. Like devops actions. And ideally we want the work in the panels get published to a in-process stage somewhere in sp.org. Maybe we can ask Ruben for someone to volunteer in CSS to help with this. And other people that worked in/around the site. Essentially this will be one big pod. Do we need a discussion on information we want to move or relocate there. How do we want to organise that. Perhaps to SC's point on leading by example. Do we want to talk about what data should be there, organised and represented.
71 | * KK: +0.9. This is an example of another thing that we need people's time commitment. This needs to be part of that process .. sufficient number of people to say this ia a "MUST" and time for
72 | * SC: can we break this down to ACTIONs for various groups?
73 | * KK: it is an issue of priority. the final priorisation for 1.0 needs to have it on the whole table.
74 | * JB: I tested the site on CSS some months ago and it mostly worked - the were was one issue re directory support. have seen some work go into CSS that will probably eleviate that. most of the time we want a proxy in the front but the other issue that need sa proxy b/c there was no https support but that's resolved in CSS. At least seemingly addressed. We can work together to figure out the publishing and it didn't seem like it was that far away. We can probably phase this out. I think what SC is looking for can be addressed in MVP state. If it means that we need to in the first phase - manually checkout and commit the specs for example while we do the autodeployment stuff. We can portion out and mak it a progress rather than a big reveal. Maybe getting there wouldn't be crazy. If we break those out in steps.
75 | 
76 | ACTION: SC to ping Solid Team about this proposal.
77 | 
78 | ACTION: JB to re-test CSS with sp.org and follow-up with them.
79 | 
80 | ACTION: KK to look at the outcomes - list of concrete actions for getting publishing Solid on top of CSS.
81 | 


--------------------------------------------------------------------------------
/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/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/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-11.md:
--------------------------------------------------------------------------------
  1 | # W3C Solid Community Group: Solid Editors
  2 | 
  3 | * Date: 2022-04-11T12: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 | 
 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 | The following is a list of Solid Roadmap Milestones, force-ranked in priority order (*note: still pending review)*.
 44 | 
 45 | ### Solid Notifications Protocol and WebSocketSubscription Type
 46 | * SC: Reference in the next publication of /TR/protocol e.g., 0.9.1.
 47 | * SC: Pending review/acceptance of PRs on solid/specification PRs: https://github.com/solid/specification/pull/391 , https://github.com/solid/specification/pull/392
 48 | * SC: I'll abstain from reviewing at least 391 (as I'm one of the editors). May do minor reviewing of 392 but I've indirectly approved this as per notifications-panel/chairing..
 49 | * KK: I will review as soon as possible.KK
 50 | * JB: Consider proposals to add normative language to the [Solid Protocol Specification](https://solidproject.org/TR/protocol) that requires support for the [WebSocketSubscription2021](https://solid.github.io/notifications/protocol#websocketsubscription2021) subscription type as specified by the [Solid Notifications Protocol](https://solid.github.io/notifications/protocol).
 51 | * JB: Target for next publication.
 52 | * JB: Will review both PRs.
 53 | 
 54 | 
 55 | ### Solid OIDC and Solid OIDC Primer
 56 | * SC: PR https://github.com/solid/specification/pull/386
 57 | * SC: Will submit review this week.
 58 | * SC: Should be referenced in 0.9.1.
 59 | * KK: I have started reviewing.
 60 | * JB: Will submit review by next week (maybe sooner, but cannot commit to sooner)
 61 | * KK: Too many ping-pongs. I'd like to see how that can be simplified. Some terms on authn/z needs to be clarified.
 62 | * SC: How deep are we reviewing the technical decisions in these specs? We need to be consistent on how we evaluate.
 63 | * JB: Will look at how information is presented in order to support implementaiton / authz server. What does authorization-server entail? It came towards near the end of the process. Was it jammed in or is there enough context for everyone?
 64 | * KK: We can't stop from publishing. Not our role. But it also needs bigger picture of things. Useful to get feedback from others. I'd challenge them on the simplifications and notions on the complexity.
 65 | * SC: If it generally fits the big picture / scope, it is acknowledged as a work item. This is proposed as ~FPWD.
 66 | 
 67 | 
 68 | 
 69 | ## Authorization by Client Identifier
 70 | 
 71 | * JB: Consider proposals to add normative language to the [Solid Protocol Specification](https://solidproject.org/TR/protocol) that requires any supported access control system (e.g. WAC, ACP) to enable or restrict access by a client application identifier.
 72 | * SC: WAC will have acl:client (as per prior meeting/agreement).
 73 | * JB: Make sure Authorization section mentions agent and client as MUST.
 74 | * SC: This is approaching authorization with identity/actor-centric access control. Is that the only approach we are taking? https://github.com/solid/authorization-panel/issues/121 is broad view.
 75 | * KK: Is it replacing same-origin?
 76 | * SC: Orthogonal
 77 | * JB: Origin only plugged for a specific case.
 78 | * SC: Auth making use of Origin header is about the warning from the browser. SOP has been a cornerstore of Web security.
 79 | * SC: Currently requiring client_id for Authorization would tie or expect it to work with something like Solid OIDC. If we are decoupling these components, does that still make sense?
 80 | * JB: The system provides the credentials for client - need to be able to.
 81 | * SC: If a new authn doesn't provide client, what would it mean for authz? e.g., capability
 82 | * JB: Saying support for client ids need not exclude non-client id..
 83 | * SC: 0.9.1ish
 84 | 
 85 | 
 86 | 
 87 | ### Storage Description and Capability Discovery
 88 | * SC: https://github.com/solid/specification/issues/355
 89 | * JB: Ack.
 90 | * KK: Ack.
 91 | * SC: 0.9.1 or 0.9.2?
 92 | 
 93 | 
 94 | ### Server Description and Capability Discovery
 95 | * SC: https://github.com/solid/specification/issues/355 - started off with server but seems like storage is the only one with a resource.
 96 | * SC: Storage provisioning: https://github.com/solid/specification/issues/317
 97 | * JB: How a client may determine capabilities and/or features offered by a given Solid server. For example, if a server supports additional notification types beyond WebSocketSubscription2021, or server-side validation by a given mechanism.
 98 | * JB: Standardise API for storages and
 99 | * KK: My main concern is that a server administrator should not override the storage's management of its own scope.
100 | * SC: How about creating identities.. falls on Solid OIDC?
101 | * JB: Yes. Keep separate.
102 | * SC: Would Solid Protocol refer to Solid OIDC for IdP etc.
103 | * JB: Server could say issuers they trust.. 
104 | * SC: 0.9.2 or closer to 1.0?
105 | 
106 | 
107 | 
108 | ### Additional Notification Types
109 | 
110 | * JB: Consider proposals to add normative language to the [Solid Protocol Specification](https://solidproject.org/TR/protocol) that add support for additional Notification Types detailed by the [Solid Notifications Protocol](https://solid.github.io/notifications/protocol), including but not limited to [EventSourceSubscription2021](https://solid.github.io/notifications/protocol#eventsourcesubscription2021), [LinkedDataNotificationSubscription2021](https://solid.github.io/notifications/protocol#linkeddatanotificationssubscription2021), and [WebHookSubscription2021](https://solid.github.io/notifications/protocol#webhooksubscription2021).
111 | * SC: Solid Notifications Protocol will publish a separate document for subscription types. It is not required by Solid Notifications Protocol to implement any. So, up to Solid Protocol or other specs to require as they see fit which subscription types they need.
112 | * SC: Need to check/compare their scopes to see where they're useful. WebSocket is for 'live updates'. LDN for client-server-server.
113 | * JB: Solid can be valuable for different types of communications. 
114 | * KK: Don't need to prioritise until there is more interaction with the community.
115 | 
116 | 
117 | * SC: To be continued..
118 | 


--------------------------------------------------------------------------------
/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/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/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/2022-06-01.md:
--------------------------------------------------------------------------------
 1 | # W3C Solid Community Group: Solid Editors
 2 | 
 3 | * Date: 2022-06-01T13: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 | * Ruben Verborgh
11 | * Tim Berners-Lee
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 | 
46 | ### Requirement levels for Notifications
47 | * SC: Continuation of https://github.com/solid/specification/blob/main/meetings/2022-05-18.md#change-reference-to-solid-notifications-protocol
48 | 
49 | 
50 | ### Roadmap
51 | * SC: Continuation of https://github.com/solid/specification/blob/main/meetings/2022-05-18.md#milestone--roadmap--prioritisation
52 | 
53 | 
54 | ### Storage description
55 | URL: https://github.com/solid/specification/issues/355
56 | 
57 | * SC: Implementation feedback: https://github.com/solid/specification/issues/355#issuecomment-1140508784
58 | * TBL: Two designs 1) where each resource points to the space or every folder or 2) resources don't but folders do or 3) you have to search for the storage because nothing points to it.
59 | * TBL: I thought we agreed on 2nd. 3rd was too slow.
60 | * SC: I don't recall 2nd as an option. We discussed 1 and 3.
61 | * RV: Either can be implemented they can all work. No help in breaking ties.
62 | * SC: We could rule out 3rd.
63 | * TBL: Right. Do one GET on storage space itself and hten get information whether it supports SPARQL queries and things like that.
64 | * SC: re 2) why not resource?
65 | * TBL: Buy me vegan food every week for every link header. The folders are part of a folder hierarchy so logical to say this is the top folder. You find its contents and from the breadcrumbs these are the ancestors. That's useful information to know.
66 | * TBL: Instead of in the header you can put it in the data of the folder.
67 | * TBL: Another thing I thoguht about puting in the folder is the parent folder.
68 | * RV: I think we have an opportunity that's orthogonal. To work in an non-LDP environment.
69 | * TBL: LDP contains in rev. when folder a contains folder b, the triple, a ldp:contains b is in both a and b.
70 | * SC: Makes sense. Useful for anything that can read the container. But because we require slash semantics, that can still be determined.
71 | * TBL: That idea of having it in both a and b may be an bad idea so only have it in a. Current practice with ldp:contains.
72 | * RV: back to original 355. Discovery is good.. without description required, can't use it.
73 | * SC: `solid:owner` is one candidate that can be expected there.
74 | * TBL: Don't need it until coded.
75 | * SC: `notify:notificationChannel` info is also needed here.
76 | * RV: Got to go. Have to follow up via comments.
77 | * TBL: Leave the description state where it is a design but put in a status where we need actual practical cases to arrive. Has to write code for it. And protocol doesn't get more complicated / pods don't get more complicated.
78 | * SC: Agreed.
79 | * TBL: you're not interested random apps but only within the spec the functionality needed. implementation feedback on 
80 | * TBL: What you're looking for other protocols needing it.
81 | * SC: Solid Protocol requires.. Notifications Protocol and that requires notificationChannel.
82 | * TBL: At the moment we have fast async websocket.. and some people want slow webhooks etc.. the architecture can be created for diff channels but people need to come up with other stuff.. like for organising a party.. or deliver people when need to be able to kick people's through their pods.. so then you get more requirements - advertising more functionality on the pod.
83 | * SC: What do you think of something like this for discovery for starters. We can deal with description later:
84 | >The server MUST include the `Link` header with `rel="http://www.w3.org/ns/solid/terms#storageDescription"` targeting the URI of the storage description resource in the response of `HTTP HEAD` or `GET` requests.
85 | * TBL: Is it okay to have a situation where there is no storage description.
86 | * SC: It could just simply empty. Is there a cost?
87 | * TBL: Every time you add to the Solid Protocol there is a cost.
88 | * TBL: Available of websockets is put on every resource.
89 | * SC: The current/old/insecure websockets yes
90 | * SC: This storageDescription is about as close as it gets to that unless resource header includes the subscription URL for each notification channel - websocket's being one. But that then introduces new link relations in HTTP header.
91 | * TBL: This whole discussions of some sort of a Storage Description is not needed for or called for by Secure WS protcol, which has its own disovery meethod which is realively fast.  We should get the SWS protocol sepcd before spending time discussing Storage Descriptions, unless some other urgent need for them arises
92 | * TBL: When that need arises then the requiremts on the Storage Description will be cllear from that need, and so save us all wondering possible designed in the bsence of that clear need.
93 | * SC: But without making this feature available it makes it difficult to provide a solution for a number of use cases, e.g., storage description, contact information, policies, communication channels.
94 | * TBL: Contact info we already do withg the profile of the owner. Storage -> owner -> owner's profile includes contacts
95 | * SC: Sure.  but those are one off link relations per use case right?
96 | * TBL: Maybe it'll be a function of a folder. we don't have all the use cases yet so can't let it drive the whole thing / generalisation.
97 | 


--------------------------------------------------------------------------------
/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-08-17.md:
--------------------------------------------------------------------------------
  1 | # W3C Solid Community Group: Solid Editors
  2 | 
  3 | * Date: 2022-08-17T13: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](https://timbl.inrupt.net/profile/card#me)
 12 | * Henry Story
 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 | 
 40 | ## Topics
 41 | 
 42 | ### Solid Control
 43 | 
 44 | * HS: Hi all. Just an update on what I am doing:
 45 |   I have a 1 year project from the EU to work on a project Solid Control based on 
 46 |      the [Launcher App](https://github.com/bblfish/LauncherApp) proposal I suggested a few years        ago in the Authentication panel. The idea  
 47 | * SC: There is an ACTION ([citation needed] in past minutes) on the Editors Team (for SC to propose) to have a community discussion on Authorization. And as you know the authn/z panels.
 48 | * SC: To find devs I think you should ping solid/chat and solid/app-development ?
 49 | * SC: Are you thinking about moving HTTPSig spec forward? How about CHAPI?
 50 | * TBL: What state is in?
 51 | * HS: Using IETF WG's RFC that's nearly finalised to signing HTTP headers and using that to authenticate.
 52 | * SC: It is a Draft now. What's next?
 53 | * HS: Yes, draft. Have implementation in Scala JS.. Java/Javascript. Spec from 5 months ago. Needs to be updated. The spec needs to be updated and update the server.
 54 | * TBL: How many other implementations of HTTPSig ar there?
 55 | * HS: HTTP Signature (or rather (httpbis-message-signature-11)[https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-11] is out there and has any implementations.
 56 | * SC: But what is the unique contribution that [HTTPSig](https://github.com/solid/authentication-panel/blob/main/proposals/HttpSignature.md) in context of Solid. I think right now that's the only consideration, not HTTP Signature in general.
 57 | * HS: HttpSig essentially just adds to the ietf RFC, the link to a WebID or KeyId. 
 58 | * HS: As part of [Solid-Control](https://github.com/co-operating-systems/solid-control) EU project I wrote an HTTP Signature in Scala [github httpSig implementation](https://github.com/bblfish/httpSig) (ready to be compiled for ScalaJS) making it easy for other solid pod implementations to allow authentication.
 59 | * SC: Suggestion: move spec forward, get more implementations (server or apps). Then we can look at if/where we can require. A bit early now. Right TBL, KK?
 60 | * TBL: Solid Pod should be open to ... authn is a function. ideally we have an api that swap in different things. allowing the user to select in real-time with a click. in a way we do for solid-oidc.. where they pick their IdP. We could also have log-in with HTTP Signature button.
 61 | * TBL: It is a good discipline. To have that flexibility point in the architecture.
 62 | * HS: ASambra had a protocol like that.. signing the headers. IETF is now closing in on HTTP Signature... so that can be used in Solid. We have it in/around since 2015.
 63 | * HS: It'll take time to get the milestones accepted.
 64 | 
 65 | 
 66 | ### Storage description
 67 | URL: https://github.com/solid/specification/blob/main/meetings/2022-06-15.md#storage-description
 68 | 
 69 | * SC: KK followed up in https://github.com/solid/specification/issues/355#issuecomment-1150434136
 70 | * SC: SC followed up on storage description in https://github.com/solid/specification/pull/416 . Merged.
 71 | * SC: Done.
 72 | 
 73 | ### Add requirement for Solid Notification Protocol
 74 | URL: https://github.com/solid/specification/pull/409
 75 | 
 76 | * SC: PR merged. Pending https://github.com/solid/specification/pull/409#issuecomment-1214977145
 77 | 
 78 | 
 79 | ### Actions from last Agenda Overview
 80 | URL: https://github.com/solid/specification/blob/main/meetings/2022-06-15.md#actions-from-last-agenda-overview
 81 | 
 82 | >ACTION: After resolving storage description, update ED to say MUST new/MAY old, SC.
 83 | 
 84 | * SC: TODO. Same as above re https://github.com/solid/specification/pull/409#issuecomment-1214977145
 85 | 
 86 | >ACTION: Publish 0.9.1 with that ED, SC.
 87 | 
 88 | * SC: TODO.
 89 | 
 90 | >ACTION: Update ED version. Include a change log for 0.9.1, SC.
 91 | 
 92 | * SC: 0.9.1 ED change log: https://solidproject.org/ED/protocol#change-log
 93 | 
 94 | ACTION: SC to add line about change/update re Websocket and Notification Protocol.
 95 | 
 96 | >ACTION: Reach out to solid-ui maintainers
 97 | 
 98 | * SC: TODO.
 99 | 
100 | >ACTION: Ask in Solid/chat whether there are more WebSocket implementations.
101 | 
102 | * SC: TODO.
103 | 
104 | 
105 | 
106 | ### Add WebID Profile as work item
107 | URL: https://github.com/solid/specification/pull/413
108 | 
109 | * SC: Done.
110 | 
111 | 
112 | ### Add Test Suite Panel Charter. Update Panels
113 | URL: https://github.com/solid/process/pull/288
114 | 
115 | * SC: Done.
116 | 
117 | 
118 | ### Add TR/2022/wac-20220705
119 | URL: https://github.com/solid/specification/pull/417
120 | 
121 | * SC: What's next?
122 | * SC: Version okay?
123 | * KK: ..
124 | * TBL: ..
125 | * SC: Current `doap:revision` is `1.0.0`. So change to `1.0.0-CR.1`?
126 | * KK: +1
127 | * TBL: +1
128 | * SC: Updated.
129 | * KK: Approved
130 | * TBL: +1'd.
131 | * SC: We should separate revision code and human-readable version re "cr" == "Candidate Recommendation".
132 | * KK: This is not really as unstable as a ED now, as CR it is less likely to change and implementers should implement it.
133 | 
134 | ACTION: KK, SC to follow with the suggestion.
135 | 
136 | ACTION: TBL to review.
137 | 
138 | 
139 | ### Add license
140 | URL: https://github.com/solid/specification/pull/412
141 | 
142 | * SC: What's next?
143 | 


--------------------------------------------------------------------------------
/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/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 | 


--------------------------------------------------------------------------------
/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/2023-09-20.md:
--------------------------------------------------------------------------------
  1 | # W3C Solid Community Group: Weekly
  2 | 
  3 | * Date: 2023-09-20T14: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 | * Aaron Coburn
 12 | * Osmar Olivo
 13 | * Hadrian Zbarcea
 14 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
 15 | * [Ross Horne](https://personal.cis.strath.ac.uk/ross.horne/)
 16 | * [Rahul Gupta](https://cxres.pages.dev/profile#i)
 17 | * Maxime Lecoq
 18 | * michal/mrkvon
 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/solid/specification/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 | 
 38 | ### Scribes
 39 | * Sarven Capadisli
 40 | 
 41 | ### Introductions
 42 | * name: text
 43 | 
 44 | 
 45 | ---
 46 | 
 47 | 
 48 | ## Topics
 49 | 
 50 | ### WIP Implementation Feedback
 51 | * SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
 52 | * ML: A draft of Solid client-to-client standard for the Data Food Consortium project is published [here](https://datafoodconsortium.gitbook.io/dfc-standard-documentation/solid-client-protocol).
 53 | * ML: It covers how resources are expressed and where they should be stored. Also, a few recommendations on indexing, using DFC ontology and taxonomy. We're using type index to let the user choose where they  want to store the data.
 54 | * eP: What would you like to do — re-work items, or work independently and provide feedback to the CG?
 55 | * ML: Will let you know after.
 56 | * eP: I'd be interested in it as a work item. I was working on Value Flows ... so interesting for me to see client-client for business domains, how much can be specific or generalised.
 57 | * ML: Talked with Value Flows. Chose to use our own ontology for now. Will let you know. Open to discussion.
 58 | 
 59 | 
 60 | ### Special Topic Meetings
 61 | URL: https://github.com/solid/specification/discussions/555
 62 | 
 63 | * SC: A couple of items may need a date.
 64 | * SC: "Security flaws in OIDC spec" still seems important. RH was/is? engaged w/ eP, HS. Why isn't this topic more up-front and centre in issues/chats?
 65 | * SC: We have a joint meeting scheduled with WebAgents CG on 2023-09-26. Please propose topics to the [agenda](https://hackmd.io/ftVbmvj0R0Oh6EsPWTEkwQ).
 66 | * eP: There is a [dedicated issue for OIDC](https://github.com/solid/solid-oidc/issues/221). We can link to it from [555](https://github.com/solid/specification/discussions/555).
 67 | 
 68 | 
 69 | ### Solid Ecosystem Monitor
 70 | URL: https://github.com/virginiaBalseiro/solid-ecosystem-monitor/
 71 | 
 72 | * SC: View at https://virginiabalseiro.github.io/solid-ecosystem-monitor/
 73 | * SC: Now includes data/charts for Present and Scribes (due to popular demand) from minutes.
 74 | * SC: Please use name in Present/Scribes as it appears in https://www.w3.org/groups/cg/solid/participants/ .
 75 | 
 76 | 
 77 | ### Solid Protocol Version 0.11.0
 78 | URL: https://github.com/solid/specification/milestone/7
 79 | 
 80 | * SC: Let's make sure to add any missing issues/PRs that can reasonably make it into this release. The ED includes class 3 and higher changes, and some in the pipeline. See [Solid Protocol ED Changelog](https://solidproject.org/ED/protocol#changelog).
 81 | 
 82 | 
 83 | ### Solid Symposium
 84 | 
 85 | * RH: Solid event in March (follow-up from Solid Symposium earlier this year.)
 86 | * RH: What would work for the community in that session? If we had tracks specific for developers working on the specs?
 87 | * SC: Have people from the CG to guide/tutorial perhaps?
 88 | * RH: Sure.
 89 | * eP: ???
 90 | * RH: Details on Symposium. 2-3 May 2024 in Leuven. Mixed Industry, Academics & Developers. Chair: Bart Buelens at VITO. Previous edition is here: https://solid.ti.rw.fau.de/public/2023/solid-symposium/
 91 | * RH: Organised in tracks, so it's possible to have a dedicated track for standards, making it a focal point for meeting in Europe in May 2024. Tracks may be hybrid. Another possibility is to have a keynote speaker or two from the Solid CG community.
 92 | 
 93 | 
 94 | ### CG Chairs Election
 95 | URL: https://www.w3.org/community/solid/charter/#chairs
 96 | 
 97 | * SC: I am looking into tooling. Trying to get support from W3C first. There are third-party tools/services, but prefer to use W3C infrastructure for simplicity and verification.
 98 | * SC: Please contribute to [Self-Review Questionnaire for Chair Candidates](https://github.com/solid/specification/discussions/568). Mentioned at TPAC in [Chartering at W3C breakout session](https://github.com/w3c/tpac2023-breakouts/issues/43) ([minutes](https://www.w3.org/2023/09/13-w3process-minutes.html)), and it was well received towards WG chair selection considerations.
 99 | 
100 | 
101 | ### Replace panels with breakout task forces
102 | URL: https://github.com/solid/process/issues/324
103 | 
104 | * SC: https://github.com/solid/process/issues/324#issuecomment-1719720918
105 | * SC: Any objections to merging those PRs? Perhaps update chat URLs to use Matrix (replacing Gitter)?
106 | * SC: Status update: https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$TetcgigSzuYAAIXt_I_hU8Po3ey6NAEPrgsl2QgO14Y
107 | * SC: webid-profile (TF) and test-suite-panel are no longer in the CG calendar. webid-profile convenes in chat before meeting. Note upcoming STM for Solid QA.
108 | * SC: data-interoperability-panel and notifications-panel have tentative status in the CG calendar.
109 | * RG: Do you have a timeline for when that transition will happen? Suppose I want to propose a new TF... when can I do that?
110 | * SC: Any time, but it is lightweight with specific focus.
111 | * eP: There is a STM.
112 | 


--------------------------------------------------------------------------------
/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
 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 | * 


--------------------------------------------------------------------------------
/meetings/2023-11-22.md:
--------------------------------------------------------------------------------
  1 | # W3C Solid Community Group: Weekly
  2 | 
  3 | * Date: 2023-11-22T14: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 | 
 11 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
 12 | * [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me) (until 14:30 UTC)
 13 | * [Rahul Gupta](https://cxres.pages.dev/profile#i)
 14 | * [Michiel de Jong](https://michielbdejong.com)
 15 | * Maxime Lecoq
 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 | * elf Pavlik
 37 | 
 38 | 
 39 | ### Introductions
 40 | * 
 41 | 
 42 | ---
 43 | 
 44 | 
 45 | ## Topics
 46 | 
 47 | ### WIP Implementation Feedback
 48 | 
 49 | 
 50 | ### Braid
 51 | 
 52 | * RG: spoke to Michael Toomim and he could do demo next week.
 53 | 
 54 | ### Solid CG Chair Election Procedure
 55 | URL: https://github.com/solid/specification/discussions/582
 56 | 
 57 | * RG: can you share an update?
 58 | * eP: we need candidates to step up: https://lists.w3.org/Archives/Public/public-solid/2023Nov/0081.html
 59 | * PAC: we should follow up on the mailing list thread
 60 | * MdJ: i can be a candidate
 61 | * HZ: if we don't have more than 3 nominations should we still do the election?
 62 | * eP: I think Sarven's idea was to test drive it for the future generations
 63 | * HZ: i can contribute to standards but my work will focus more on the adoption and building community
 64 | * MdJ: CG chairing doesn't need to do that much, mostly facilitating and holding the space for people to have conversation. Also cultivating the plurality of the solid community. Allowing things to grow in the space. It is different from the task of spec editor.
 65 | * HZ: I'm worried that my Inrupt position would be a disadvantage here.
 66 | * eP: Hadrian I hope you will join as candidate, as well as Michiel.
 67 | * HZ: Communication between chairs will be very important.
 68 | * HZ: I'm not sure how I could help from that role more than I do now?
 69 | * MdJ: I see need to continue the Solid CG as the space where the Solid can happen. We don't need to make it more buereucratic. It is important to keep it going. 
 70 | * HZ: I go to conferences and see a lot of enthusiasm about solid there.
 71 | 
 72 | Open conversation about Solid adoption...
 73 | 
 74 | * ML: Many people tell me that Solid seemst to them only for individuals and not for the organizations.
 75 | * ML: https://github.com/solid/solidproject.org/issues/813
 76 | * MdJ: The pod might be for individual and for organiatin, organization can benefit where the data is stored in user-centric way.
 77 | * 
 78 | 
 79 | ### Special Topic Meetings
 80 | URL: https://github.com/solid/specification/discussions/555
 81 | 
 82 | * eP: shall we setup a meeting about WG charter?
 83 | 
 84 | ### W3C Solid WG Charter Proposal
 85 | URL: https://github.com/solid/solid-wg-charter
 86 | 
 87 | * PAC: I have two charter in working Solid & DID, DID is currently more urgent. I should get it out of the way next week and can focus again on Solid.
 88 | * ...: We should officialize retracting the charter and proposing a new one. We need to figure out the best way to work on the new one.
 89 | * ...: It should narrow the scope and make the charter less ambitious.
 90 | * ...: On the other hand we need to respond to the criticism that the solution was chosen in advance. We should make it something that will appeal to more people than just Solid CG.
 91 | * eP: ...
 92 | * PAC: Solid is many different things to many different people. Based on reponses to my mailing list thread it also seems that case within solid community.
 93 | * RG: We should focus more on emphasis on decentralization and democratizing data ownership. We should also incorporate feedback from other groups.
 94 | * PAC: Sarven is organizing meeting with a Social CG. Saying "Solid is about fixing the web" this is to much for a single working group. If we talk about decentralization there are other groups which propose solutions.
 95 | * HZ: I think that even DID came up with ready solution. The reason for not using other solutions is that they don't meet requirements. For example blockchains are centralized.
 96 | * eP: Which REST based systems are we talking about specifically?
 97 | * PAC: To Hadrian, nowadays when WG are created they are backed by strong incubation. There is a tension between having enough incubation vs just rubber stamping an existing solution. It is a balancing act. 
 98 | * PAC: In response to Pavlik, the comparision would be very interesting one to write down, opposing to those arguments. Maybe this could be a part of explaination, clearly addressing what is overlapping.
 99 | * PAC: ActivityPub is very clear existing spec. It is not limited to 'tweets', it has notion of collections and objects.
100 | * RG: My sense is that we need to draw the boundires. Solid being based on HTTP and using Linked Data. Than we can look for comparable solutions.
101 | * PAC: We need to both broaden and narrow the scope. Mention HTTP and RESTful APIs, Linked Data. We should explain use of RESTful APIs. Maybe also we shouldn't call it Solid.
102 | * eP: We could clarify some non trivial use cases and compare around that
103 | * RG: ...
104 | * PAC: Gathering of use cases and selecting few representative use cases. Different people are trying to do different things. By gathering different use cases from different perspectives we can justify that Solid is meeting a broad range of use cases.
105 | 
106 | 
107 | 
108 | ### Holidays break in December?
109 | 
110 | * eP: I would suggest to stop official meetings after Dec 13th and resume from Jan 3rd.
111 | * 
112 | 


--------------------------------------------------------------------------------
/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
 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 | 
128 | 


--------------------------------------------------------------------------------
/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
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-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-01-08.md:
--------------------------------------------------------------------------------
 1 | # W3C Solid Community Group: Weekly
 2 | 
 3 | * Date: 2025-01-08T14: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
12 | * Grace Elcock (observer)
13 | * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
14 | * [Rahul Gupta](https://cxres.pages.dev/profile#i)
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/w3c-cg/solid/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 | ### 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 | 
34 | * elf Pavlik
35 | 
36 | ## Topics
37 | 
38 | ### Call for Review: Adding solid:storageDescription to Solid Terms
39 | URL: https://github.com/solid/vocab/pull/95
40 | 
41 | Proposed by SC.
42 | * MdJ: pretty straight forward, needs a few more reviews
43 | 
44 | ### Charter update
45 | https://github.com/w3c-cg/solid/pull/21
46 | 
47 | * MdJ: Still waiting for the reveiew from Hadrian
48 | * RG: We should put the change up for vote
49 | * MdJ: It makes sense to do it during the meeting, maybe next week if Hadrian reviews it. We also send out email for principled objections. Melvin expressed a different preference but I believe he didn't object. https://lists.w3.org/Archives/Public/public-solid/2024Dec/0012.html
50 | * RG: There are also suggestions by Ted.
51 | * MdJ: Do we agre that Melvin's email is not a principled objection?
52 | * eP: It sounds to me like a preference not an objection.
53 | * eP: Do you have admin acces to that solid cg repo?
54 | * MdJ: No
55 | * eP: There are also some IPR checks that didn't pass
56 | 
57 | ACTION: MdJ to contact Ian about permissions on Solid CG repo and the IPR check
58 | 
59 | ### Plans for Q1
60 | 
61 | * MdJ: Focusing on Pivot, making changes after testing it.
62 | * ...: Also planning to work on Trusted Apps
63 | * ...: Security review for Pivot/CSS — there was a discussion with Matthias, Jesse, and me. Documentation of CSS states that it is unfit for hosting Personally Identifying Information (PII). We were all planning to do a security review for Pivot. Once it is reviewed, we can communicate the review to people.
64 | * ...: Performance is still separate from security. Unless you are in an enterprise situation, where you want impeccable performance.
65 | * ...: Trusted apps is still an unsolved topic. We either have no solution or too many solutions. I want to show the launcher app with two bookmark apps, showing data portability with fine grained access control.
66 | * eP: Are you only focused on the special case where the Resource Owner and the End User are the same?
67 | * MdJ: Yes, it's just one user using two apps, no sharing.
68 | * MdJ: Also thinking about some milestones for the Data Modules
69 | * ...: I'm also presenting a lightning talk on FOSDEM. It will not be focused on Solid, but it will mention Solid.
70 | * RG: I don't have any firm plans; just talking to a few people. Also started a few threads on IETF mailing lists, mostly talking about media types and microtypes. This links to the question of how you organize data in a Solid pod — how to organize complex information; how to have pagination; and how to communicate it.
71 | * eP: Does it also relate to evolvability of the system?
72 | * RG: I'm thinking about users putting the data on the pod. If they change it, and the clients come to read that data, do they need something out of band, like client to client spec, or can they just rely on media types to understand the data? This also narrows the scope for the C2C specs. You may need to specify things that are handled by media types.
73 | * eP: Since RDF is a bit special when it comes to media types, do you focus on that or do you focus on both RDF and non-RDF?
74 | * RG: For example, pagination. Fred gives example of having 10,000 triples, and doesn't want to serve it. We can do it by introducing new serialization, new feature, new parameters for content negotiations. There are a few ways to solve it. One would be microtypes; another would be a `QUERY` method. This is not about RDF, but how to organize data in general. There is also non-RDF data which has links in it. Also, when you just want pieces of that data, how do you negotiate for that?
75 | * eP: There are use cases in LWS WG. We should make sure that some of the use cases are representative for the problem you are trying to solve.
76 | * RG: There are some use cases; for example, Sarven's use case about hosting HTML pages.
77 | * RG: https://lists.w3.org/Archives/Public/ietf-http-wg/2025JanMar/0007.html
78 | * RG: What are the things that we want to take to LWS?
79 | * MdJ: LWS will just define storage and IdP. I don't even think that it is that exciting in that sense. They will need to choose between WAC, ACP, and SAI. It's up to them; they have some time to think about it. I don't expect them to come up with something that works for data portability or sharing. I expect just a very robust spec for what we have now as Solid Protocol and probably ACP. Possibly Solid-OIDC, but there is also talk about OAuth2 and UMA. I'm more excited about research and development that is happening in SolidOS or SAI. There is even discussion about blank nodes in the patch. I think they will maybe solve a little more when it comes to paging and resumable uploads. I don't expect anything about the client part; the LWS WG charter makes client-to-client out of scope.
80 | * RG: What are the things that we as a community feel we shouldn't only discuss among ourselves, but bring to the attention of the WG? As a community, what do we think should be available?
81 | * MdJ: It would make sense if the CG had consensus which we could bring to LWS. We don't have consensus, so it is up to them to pick what they prefer. There is no single voice coming from community, other than what is already in the protocol spec.
82 | * RG: There is the whole issue of how we want to support features for C2C specs that are relevant for the server. There is one other issue raised last year, about pod portability. Do we want to work on the solution for that?
83 | * MdJ: That would make sense.
84 | * eP: I think we should try to have a joint meeting of the Solid CG and the LWS WG, to sync up and discuss how the collaboration should look.
85 | * eP: For me access delegation is a key requirement, both for authorizing apps and for group-based access control.
86 | 


--------------------------------------------------------------------------------
/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 (he/him) Thibodeau Jr](https://github.com/TallTed/) (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 <https://www.w3.org/TR/owl2-overview/>?
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/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 
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/README.md:
--------------------------------------------------------------------------------
 1 | <details open="">
 2 |   <summary>Document Status</summary>
 3 |   <dl>
 4 |     <dt>Modified</dt>
 5 |     <dd>2024-01-10</dd>
 6 |     <dt>Reason</dt>
 7 |     <dd>This document is no longer in effect and is no longer being updated here. For the latest information on the <a href="https://www.w3.org/groups/cg/solid/">W3C Solid Community Group</a>, please refer to its <a href="https://github.com/w3c-cg/solid/">repository</a>, <a href="https://www.w3.org/community/solid/charter/">charter</a>, and <a href="https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md">contributing guidelines</a>.</dd>
 8 |   </dl>
 9 | </details>
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/template.md:
--------------------------------------------------------------------------------
 1 | <details open="">
 2 |   <summary>Document Status</summary>
 3 |   <dl>
 4 |     <dt>Modified</dt>
 5 |     <dd>2024-02-26</dd>
 6 |     <dt>Reason</dt>
 7 |     <dd>Although the meeting minutes are still in this folder, this document (the template) is no longer in effect and is no longer being updated. To add a meeting, please refer to the <a href="https://github.com/w3c-cg/solid/blob/main/meetings/template.md">current meeting template</a>. For the latest information on the <a href="https://www.w3.org/groups/cg/solid/">W3C Solid Community Group</a>, please refer to its <a href="https://github.com/w3c-cg/solid/">repository</a>, <a href="https://www.w3.org/community/solid/charter/">charter</a>, and <a href="https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md">contribution guidelines</a>.</dd>
 8 |   </dl>
 9 | </details>
10 | 


--------------------------------------------------------------------------------
/protocol.timemap.html:
--------------------------------------------------------------------------------
 1 | <!DOCTYPE html>
 2 | <html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
 3 |   <head>
 4 |     <meta charset="utf-8" />
 5 |     <title>Solid Protocol TimeMap</title>
 6 |   </head>
 7 | 
 8 |   <body about="" prefix="xsd: http://www.w3.org/2001/XMLSchema# mem: http://mementoweb.org/ns# schema: http://schema.org/ prov: http://www.w3.org/ns/prov#">
 9 |     <main>
10 |       <article about="" typeof="schema:CreativeWork prov:Entity">
11 |         <h1 property="schema:name">Solid Protocol TimeMap</h1>
12 | 
13 |         <div datatype="rdf:HTML" property="schema:description">
14 |           <dl>
15 |             <dt>TimeMap</dt>
16 |             <dd><a about="" href="https://solidproject.org/TR/protocol.timemap" typeof="mem:TimeMap">https://solidproject.org/TR/protocol.timemap</a></dd>
17 |           </dl>
18 | 
19 |           <dl>
20 |             <dt>Original Resource</dt>
21 |             <dd><a href="https://solidproject.org/TR/protocol">https://solidproject.org/TR/protocol</a></dd>
22 |           </dl>
23 | 
24 |           <dl>
25 |             <dt>Memento</dt>
26 |             <dd about="https://solidproject.org/TR/protocol">
27 |               <ul>
28 |                 <li><a rel="mem:memento" href="https://solidproject.org/TR/2021/protocol-20211217">https://solidproject.org/TR/2021/protocol-20211217</a> (<time about="https://solidproject.org/TR/2021/protocol-20211217" datatype="xsd:dateTime" datetime="2021-12-17T00:00:00Z" property="mem:mementoDateTime">2021-12-17T00:00:00Z</time>)</li>
29 |                 <li><a rel="mem:memento" href="https://solidproject.org/TR/2022/protocol-20221231">https://solidproject.org/TR/2022/protocol-20221231</a> (<time about="https://solidproject.org/TR/2022/protocol-20221231" datatype="xsd:dateTime" datetime="2022-12-31T00:00:00Z" property="mem:mementoDateTime">2022-12-31T00:00:00Z</time>)</li>
30 |                 <li><a rel="mem:memento" href="https://solidproject.org/TR/2024/protocol-20240512">https://solidproject.org/TR/2024/protocol-20240512</a> (<time about="https://solidproject.org/TR/2024/protocol-20240512" datatype="xsd:dateTime" datetime="2024-05-12T00:00:00Z" property="mem:mementoDateTime">2024-05-12T00:00:00Z</time>)</li>
31 |               </ul>
32 |             </dd>
33 |           </dl>
34 |         </div>
35 |       </article>
36 |     </main>
37 |   </body>
38 | </html>
39 | 


--------------------------------------------------------------------------------
/solid.svg:
--------------------------------------------------------------------------------
 1 | <svg width="352" height="322" xmlns="http://www.w3.org/2000/svg">
 2 |   <g fill-rule="nonzero" fill="none">
 3 |     <path d="M87.97296 282.3527L27.24133 177.02207c-5.62041-9.75765-5.62041-21.77908 0-31.53674L87.97296 40.2328c5.64643-9.78367 16.08061-15.79439 27.32143-15.79439h121.3852c11.26684 0 21.72704 6.01072 27.32143 15.7944l60.75765 105.30458c5.62041 9.75766 5.62041 21.77909 0 31.53674l-60.73163 105.33061c-5.64643 9.78367-16.08061 15.79439-27.32143 15.79439H115.37245c-11.31888-.05204-21.72704-6.08878-27.3995-15.84643z" fill="#FFF"/>
 4 |     <path d="M93.15102 275.19708l-57.1148-99.0597c-5.30816-9.1852-5.30816-20.50408 0-29.66326l57.1148-99.08572c5.33418-9.21122 15.14388-14.85765 25.73418-14.85765h114.2296c10.5903 0 20.42602 5.64643 25.73418 14.85765l57.16684 99.03368c5.30816 9.1852 5.30816 20.50408 0 29.66326L258.875 275.2231c-5.33418 9.21122-15.14388 14.85765-25.73418 14.85765H118.93724c-10.64234 0-20.45204-5.67245-25.78622-14.88367z" fill="#7C4DFF"/>
 5 |     <path d="M118.46888 142.2328h117.53418c1.48316 0 2.65408-1.19695 2.65408-2.65409v-22.03928c0-14.6495-11.89132-26.54085-26.54081-26.54085h-70.56735c-20.5301-.026-37.15722 16.60105-37.15722 37.13115-.02594 7.83214 6.271 14.10306 14.07712 14.10306zM129.99592 239.60116H200.225c21.20663 0 38.43214-17.22551 38.43214-38.43214 0-7.07755-5.72449-12.82806-12.82806-12.82806H106.94184c-1.45715 0-2.55005 1.17091-2.55005 2.55v23.05408c-.02597 14.18112 11.47505 25.65612 25.60413 25.65612z" fill="#F7F7F7"/>
 6 |     <path d="M109.59592 139.3185l87.66275 87.66276c5.80255 5.80255 15.19592 5.80255 20.99847 0l15.19592-15.19592c5.80255-5.80255 5.80255-15.19591 0-20.99847l-87.63673-87.66275c-5.80255-5.80255-15.19592-5.80255-20.99847 0l-15.19592 15.19592c-5.8546 5.80255-5.8546 15.22194-.02602 20.99847z" fill="#F7F7F7"/>
 7 |     <path fill="#444" opacity=".3" d="M198.6898 228.46443l-51.4944-40.12347h11.39695zM144.35918 101.66698l40.56582 40.56581h13.7648z"/>
 8 |   </g>
 9 | </svg>
10 | 


--------------------------------------------------------------------------------
/wac.timemap.html:
--------------------------------------------------------------------------------
 1 | <!DOCTYPE html>
 2 | <html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
 3 |   <head>
 4 |     <meta charset="utf-8" />
 5 |     <title>Web Access Control TimeMap</title>
 6 |   </head>
 7 | 
 8 |   <body about="" prefix="xsd: http://www.w3.org/2001/XMLSchema# mem: http://mementoweb.org/ns# schema: http://schema.org/ prov: http://www.w3.org/ns/prov#">
 9 |     <main>
10 |       <article about="" typeof="schema:CreativeWork prov:Entity">
11 |         <h1 property="schema:name">Web Access Control TimeMap</h1>
12 | 
13 |         <div datatype="rdf:HTML" property="schema:description">
14 |           <dl>
15 |             <dt>TimeMap</dt>
16 |             <dd><a about="" href="https://solidproject.org/TR/wac.timemap" typeof="mem:TimeMap">https://solidproject.org/TR/wac.timemap</a></dd>
17 |           </dl>
18 | 
19 |           <dl>
20 |             <dt>Original Resource</dt>
21 |             <dd><a href="https://solidproject.org/TR/wac">https://solidproject.org/TR/wac</a></dd>
22 |           </dl>
23 | 
24 |           <dl>
25 |             <dt>Memento</dt>
26 |             <dd about="https://solidproject.org/TR/wac">
27 |               <ul>
28 |                 <li><a rel="mem:memento" href="https://solidproject.org/TR/2021/wac-20210711">https://solidproject.org/TR/2021/wac-20210711</a> (<time about="https://solidproject.org/TR/2021/wac-20210711" datatype="xsd:dateTime" datetime="2021-07-11T00:00:00Z" property="mem:mementoDateTime">2021-07-11T00:00:00Z</time>)</li>
29 |                 <li><a rel="mem:memento" href="https://solidproject.org/TR/2022/wac-20220705">https://solidproject.org/TR/2022/wac-20220705</a> (<time about="https://solidproject.org/TR/2022/wac-20220705" datatype="xsd:dateTime" datetime="2022-07-05T00:00:00Z" property="mem:mementoDateTime">2022-07-05T00:00:00Z</time>)</li>
30 |                 <li><a rel="mem:memento" href="https://solidproject.org/TR/2024/wac-20240512">https://solidproject.org/TR/2024/wac-20240512</a> (<time about="https://solidproject.org/TR/2024/wac-20240512" datatype="xsd:dateTime" datetime="2024-05-12T00:00:00Z" property="mem:mementoDateTime">2024-05-12T00:00:00Z</time>)</li>
31 |               </ul>
32 |             </dd>
33 |           </dl>
34 |         </div>
35 |       </article>
36 |     </main>
37 |   </body>
38 | </html>
39 | 


--------------------------------------------------------------------------------