-
Notifications
You must be signed in to change notification settings - Fork 44
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add meeting agenda 2024-04-17 (#646)
* Add meeting agenda 2024-04-17 * Update meeting minutes * Minor. Correct spelling; update State; add Scribe name --------- Co-authored-by: Sarven Capadisli <info@csarven.ca>
- Loading branch information
1 parent
9b8eea7
commit 7ed5d71
Showing
1 changed file
with
152 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,152 @@ | ||
| # W3C Solid Community Group: Weekly | ||
|
|
||
| * Date: 2024-04-17T14:00:00Z | ||
| * Call: https://meet.jit.si/solid-cg | ||
| * Chat: https://matrix.to/#/#solid_specification:gitter.im | ||
| * Repository: https://github.com/solid/specification | ||
| * Status: Published | ||
|
|
||
|
|
||
| ## Present | ||
| * [Virginia Balseiro](https://virginiabalseiro.com/#me) | ||
| * [elf Pavlik](https://elf-pavlik.hackers4peace.net) | ||
| * [Sarven Capadisli](https://csarven.ca/#i) | ||
| * Grace Elcock | ||
| * [Pierre-Antoine Champin](https://champin.net/#pa) | ||
| * [Rahul Gupta](https://cxres.pages.dev/profile#i) | ||
| * [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) | ||
| * Maxime Lecoq-Gaillard | ||
|
|
||
| ## Announcements | ||
|
|
||
| ### Meeting Guidelines | ||
| * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). | ||
| * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). | ||
| * No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur. | ||
| * Join queue to talk. | ||
| * Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed. | ||
|
|
||
| ### Participation and Code of Conduct | ||
| * [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/). | ||
| * [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/) | ||
| * Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome. | ||
| * If this is your first time, welcome! please introduce yourself. | ||
|
|
||
|
|
||
| ### Scribes | ||
| * Pierre-Antoine Champin | ||
|
|
||
| ### Introductions | ||
|
|
||
| * [name] | ||
|
|
||
| --- | ||
|
|
||
| ## Topics | ||
|
|
||
| * SC: Am only here for the first 5-10 minutes :S | ||
|
|
||
| ### Special Topic Meetings | ||
| URL: https://github.com/orgs/solid/projects/16/views/1 | ||
|
|
||
| ### WIP Implementation Feedback | ||
| * VB: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome. | ||
| * eP: this week wrapping up [StreamingHTTPChannel2023 for CSS](https://github.com/CommunitySolidServer/CommunitySolidServer/pull/1878) branch in the PR ready to be played with. (`text/turtle` only) | ||
| * eP: also starting implementing WebPushChannel2023 (and writing updated draft), plus enabling SAI Authorization Agent to act as Webhooks to WebPush bridge between apps and storages. | ||
| * eP: state of test suite for Solid Notifications? | ||
| * SC: Revisited some old type indexes code in dokieli. Want to update UI to write to it and also read from it for the Activities feature. The type indexes spec is relatively simple to implement but can use some cleaning up to appear even simpler to anyone that's not familiar. | ||
| * SC: I have finished implementing TypeIndex as part of Dokieli. It discovers where to write W3C Web Annotations. It was already detecting other channels (via `solid:storage`, `as:outbox`, `oa:annotationService`); now it also uses TypeIndex. The UI is interesting, in distinguishing public and private indexes. The spec is simple to implement. It could be useful for a lot of people. | ||
| * eP: I'm glad that you work on that, but I have concerns about privacy issues with TypeIndex. What's your experience with it? There is a need not only to prevent access to some data, but to also hide the fact that such data exists (e.g., medical record). | ||
| * SC: I know where you are coming from. What's discovered in the private TypeIndex should only be readable by the agent accessing it. | ||
| * eP: I'm focusing on types. Any application with access to your private TypeIndex knows about all the types of data that you have. You cannot filter what kind of application can see that you have this or that kind of data. Granted, the "Annotation" type is very generic, so this is not an issue in your case. But with other types of data (e.g., medical record), you would like to be able to hide it to some applications. | ||
| * SC: A malicious app could do something with the information it gets from the type index. But they would still not have access to the data itself, only know its location. | ||
| * PAC: My experience with using Solid application, whenever I use an app, I give it access to my pod. Is the discussion about filtering what the application can access? Is it implemented? Is it possible today to prevent an app from accessing some part of my pod? | ||
| * SC: There is an open question whether client identifiers are needed. This is one way, but there are alternative approaches. It is hard to get into it right now. There are questions whether client identifiers only limit clients to use OIDC. I think we may need to think more broadly. There are aspects related to signatures, which Social Web is picking up. ActivityPub is using signatures: | ||
| * So, [RFC 9421 HTTP Message Signatures](https://www.rfc-editor.org/rfc/rfc9421.html) is relevant | ||
| * [HttpSig Authentication for Solid](https://solid.github.io/httpsig/), a Solid CG work item. | ||
| * [ActivityPub and HTTP Signatures](https://swicg.github.io/activitypub-http-signature/), a Social Web CG work item. | ||
| * eP: With ACP you have client?? You can limit by agent or by client. It is not necessarily bound to OIDC. We could use WebIDs for identifying clients, not just agents. With SAI, I can give you access to, e.g., a calendar; then you can choose to which clients you delegate this access. This part is still missing for Solid in general. | ||
| * VB: Pavlik, do you want to present your own implementation feedback? | ||
| * eP: this is about streaming HTTP with CSS. Demo uses a public resource but works with access-protected resources as well. Similar to the old WebSocket, but works on standard HTTP, including for authentication. | ||
| * PAC: Is there a form of separator? How do I know when a chunk stops and the next one starts? | ||
| * eP: Each chunk is one message. If it is one notification per chunk, this is straightforward. You can make more complex things. | ||
| * RG: The assumption is that there is an infinite Turtle file containing all data. This works faster with HTTP/1. With HTTP/2 you need something different; it uses dataframes instead of chunks. | ||
| * eP: you need to provide a way to indicate when a bit stops and the other one starts. | ||
| * VB: the next implementation feedback is from Rahul. | ||
| * RG: Started Implementation of PREP in NSS. | ||
| https://github.com/CxRes/node-solid-server/tree/prep | ||
| * eP: invitation: on Friday, 15:00UTC, organized by Michiel, related to notification. Jackson will be presenting. WebPush will also be available soon. | ||
|
|
||
| ### Updating WDs | ||
| URL: https://solidproject.org/TR/ | ||
|
|
||
| * eP: outdated/invalid URL of JSON-LD context in WD https://solidproject.org/TR/notifications-protocol#protocol valid in ED https://solid.github.io/notifications/protocol | ||
| * eP: reminds me of need to publish updated WD https://solidproject.org/TR/oidc the ED has many fixes https://solid.github.io/solid-oidc/primer/ | ||
| * eP: as we do it should we switch to W3C CG draft templates? | ||
| * eP: There were some issues when publishing the JSON-LD context on W3C ns. The URL where it was published was different from the one in the spec. We need to quickly publish a new version with the correct context URL. We also need to publish OIDC-primer. Which template should we use? | ||
| * PAC: the CG templates. | ||
| * VB: I'll plan those topics for next meetings. We need to know who needs to be present or what is needed. | ||
| * eP: question to PAC: CG templates don't provide WD/ED distinction | ||
| * PAC: I don't remember whether ED says CG draft. I think so. Will check. | ||
|
|
||
| ### WG Charter | ||
|
|
||
| #### Please upvote and downvote proposed WG names | ||
| URL: https://github.com/solid/solid-wg-charter/issues/75 | ||
| URL: https://github.com/solid/solid-wg-charter/issues/73 | ||
|
|
||
| * TT: Might be good to propose a closing date, or at least a "we will discuss this on the xyz call starting yyyy-mm-ddZhh:mm", as I think that more people have participated in the suggesting than in the up/down polling. | ||
| * PAC: I created a [quick page that displays results sorted in a sensible order](https://champin.net/2024/solid-name.html), it updates automatically: https://champin.net/2024/solid-name.html | ||
| * ...: there was an AC meeting. People from the TAG were there as well as the people from the council. They expressed interest in seeing the new charter, especially if it addresses formal objections. If the formal objections are removed, it won't need another AC vote. We should send this new charter to the TAG as soon as possible. Even if the objections are not withdrawn, the council has the power to override them. I would like to send out new charter by the end of this week. I believe we addressed the objections as well as we could. | ||
| * eP: if you want to send it by the end of this week, we need to sort the name question by then. | ||
| * PAC: It has been two weeks already, there was enough time. | ||
| * eP: I agree, in the end it is a W3C call. The poll is a courtesy for the vote. We can discuss it here. | ||
| * TT: yes, 2 weeks is a lot of time, but without a deadline, people may delay their response. I have not voted yet. | ||
| * RG: can you make the submission next Wednesday instead of next Friday. | ||
| * PAC: I was not given any delay, so I can't know when exactly it will be too late. | ||
| * eP: anyway, there are already two strong candidates. | ||
| * RG: I would rather give a deadline to CG members. | ||
| * PAC: I send provisional charter to the TAG, as soon as possible. Mentioning that the name could still change. | ||
| * eP: will you leave "PUMPKIN" or use one of the names as temporary? | ||
| * PAC: I was thinking leaving a placeholder ("PUMPKIN" or "@@@"...) | ||
| * eP: I still think it is unlikely to change, given the current scores. | ||
| * TT: it is unlikely but possible that ~10 people add their votes and change the result. | ||
| * PAC: I understand that the preference was to pick one or use placeholder | ||
| * VB: I prefer a placeholder and wait for the final choice | ||
|
|
||
| ACTION: VB to announce the final date for feedback on the name choices | ||
|
|
||
| #### Tantek's feedback re: 2 vs. 3 chairs | ||
| URL: https://github.com/solid/solid-wg-charter/issues/66 | ||
|
|
||
| * VB: PAC, any status update on this? | ||
| * VB: was closed as duplicate. | ||
| * PAC: there is a tracking issue in W3C repo | ||
|
|
||
| #### Add Explainer | ||
| URL: https://github.com/solid/solid-wg-charter/issues/52 | ||
|
|
||
| * VB: Can this issue be closed given reference to *an explainer* in https://github.com/solid/solid-wg-charter/blob/004ba63e1b76715a4c72b5d6147c9eca6a9c7ee5/charter/index.html | ||
| * PAC: It was added by PR linking to Tim's writeup | ||
|
|
||
| #### Does the value come from the protocol or the applications? | ||
| URL: https://github.com/solid/solid-wg-charter/pull/71 | ||
|
|
||
| * PAC: I think it is good for merging. | ||
| * eP: I think it is ok to merge. There was some discussion about the "client-side" part. I put a comment yesterday about the rationale to restrict to client-side application (as opposed to PHP-like server-side apps). We need to distinguish "client-side" from "in-browser". | ||
| * PAC: client-side doesn't mean browser, servers in the Solid ecosystems are storage, there is nothing application-specific. | ||
| * RG: should we use user agent? | ||
| * PAC: agree, it is more appropriate than browser. | ||
| * eP: why not just say "application"? There does not seem to be an implication that it will be on the server. The term server is sloppy; we have a number of different servers. We want to allow in-browser applications, but we don't want to restrict to it (e.g., mobile). | ||
| * VB: Since Sarven had a strong point we can resolve it in the PR. | ||
| * PAC: I will follow up with Sarven | ||
| * eP: the "client-side" question is not blocking for me, although I find it confusing. | ||
|
|
||
|
|
||
|
|
||
| ### Proposal for integrating DIDs into Solid | ||
| URL: https://github.com/solid/specification/issues/629 | ||
|
|
||
| VB: we don't have time now. We can discuss it next week. I'll ping Hadrian to know what his intention was with this. | ||
| eP: a new participant joined a few weeks ago, I think she mentioned she was interested in DIDs. | ||
|
|