-
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.
* Meeting notes 2024-08-28 * Update meetings/2024-08-28.md Co-authored-by: Virginia Balseiro <[email protected]> --------- Co-authored-by: Virginia Balseiro <[email protected]>
- Loading branch information
1 parent
80f85cc
commit 3a8aec6
Showing
1 changed file
with
139 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,139 @@ | ||
| # W3C Solid Community Group: Weekly | ||
|
|
||
| * Date: 2024-08-28T14: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 | ||
| * [Michiel de Jong](https://michieldejong.com) | ||
| * [Virginia Balseiro](https://virginiabalseiro.co/#me) | ||
| * elf Pavlik | ||
| * Fred Gibson | ||
| * Grace Elcock | ||
| * Hadrian Zbarcea | ||
| * [Rahul Gupta] | ||
| * Ted Thibodeau (he/him) | ||
| * Willem Datema | ||
| * Tim Berners-Lee | ||
|
|
||
| --- | ||
|
|
||
| ## Announcements | ||
| * VB: I asked for more time for the videos for TPAC, working with Rahul to see if we can get some stuff across. From the Dokieli side we're going to demo the stuff we have on the screencasts, and perhaps some more stuff, I wanted the group to be aware. https://github.com/linkeddata/dokieli/blob/main/README.md#screencasts | ||
| * VB: We're going to submit Rahul's video and the Dokieli one by Monday. | ||
| * eP: I have some demos with SAI but it says nothing about what's happening under the hood. Yesterday I found app.icepanel.io (not open source). | ||
|
|
||
| ### 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). | ||
| * Neither audio or video recording nor automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur. | ||
| * Join queue to talk. | ||
| * Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed. | ||
|
|
||
| ### Participation and Code of Conduct | ||
| * [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/) | ||
| * [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Conduct](https://www.w3.org/policies/code-of-conduct/) | ||
| * Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome. | ||
| * If this is your first time, welcome! please introduce yourself. | ||
|
|
||
|
|
||
| ### Scribes | ||
| * Michiel | ||
| * elf Pavlik | ||
|
|
||
| ### Introductions | ||
| * | ||
|
|
||
| --- | ||
|
|
||
| ## Topics | ||
|
|
||
| ### TPAC Demos | ||
|
|
||
| * VB: see announcement | ||
|
|
||
| #### Demos | ||
| * elf Pavlik demos https://s.icepanel.io/YReKK7RsDL9BJv/YzC1 a view of projectron interoperability goals and https://elf-pavlik.github.io/[...] | ||
|
|
||
|
|
||
| ### Add server to support Last-Modified header field | ||
| URL: https://github.com/solid/specification/pull/678 | ||
|
|
||
| * SC: Please review. | ||
| * MDJ: needs more clarifications, let's commment on the issue first and add it to next week's agenda if needed | ||
|
|
||
|
|
||
| ### Solid+Braid | ||
|
|
||
| * MDJ: The [TAG explainer for Solid](https://timbl.solidcommunity.net/2023/03%20EWADA/TAGExplainerforSolid.html) mentions that Solid is designed to be combined with for instance Braid. How would that work? Would we get resource versioning in pod servers, and could Braid-Subscribe be used as a notification mechanism? | ||
| * TBL: [Braid](https://braid.org/) is a general solution for LocalFirst functionality. LocalFirst — the fact that you can start doing stuff on your device and later sync with other devices and the cloud — [has always been an item](https://solidproject.solidcommunity.net/Specification/Roadmap/state.ttl#Iss1648589891646) on the [roadmap for Solid](https://solidproject.solidcommunity.net/Specification/Roadmap/index.ttl#this). | ||
| * TBL: News: [HTTP Resource Versioning](https://datatracker.ietf.org/meeting/120/materials/slides-120-httpbis-versioning-for-http-resources-00.pdf) discussed at IETF 120 [draft](https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions), [slides](https://datatracker.ietf.org/meeting/120/materials/slides-120-httpbis-versioning-for-http-resources-00.pdf) | ||
| * SC: Background and presentation on Braid in Solid CG (a year or so go): | ||
| * https://github.com/solid/specification/blob/main/meetings/2023-08-23.md | ||
| * https://github.com/solid/specification/blob/main/meetings/2023-11-29.md | ||
| * SC: Issue on [Resource Versioning](https://github.com/solid/specification/issues/280) in Solid (c. 2019) | ||
| * MDJ: It was also presented on Solid Symposium, it may handle versioning and notifications. A lot of Solid server implementations don't support concurent updates. Two `PUTs` could be applied at the same time. The default mode is to fail if things are happening at the same time. | ||
| * RG: I was the chair of that session at SoSy and have been in touch with Michael. Braid it was presented at IETF in Nov 2023. He was given advice that Braid has to be split into a number of specifications which deal with different responsibilities — versioning, merge-types, notifications, range-patch, etc. They already started on that but need more time. It is in the IETF process, and all the pieces need to be there. Until that happens, I see Braid as experimental. | ||
| * RG: On the topic of notifications, Braid has it less complete than Solid notifications and PREP. You can see [Toomim's issue at PREP](https://github.com/CxRes/prep/issues?q=is%3Aissue+is%3Aclosed) and [my comments to Braid](https://github.com/braid-org/braid-spec/issues/124#issuecomment-1690538558). They are only concerned with PATCH updates. Solid Notifications has a broader use case. | ||
| * eP: There are different use cases, you can't say one replaces the other. | ||
| * MDJ: We can still have all those channel types, but Braid can help with the history, merge, and rebase. If you use if-match with older version, then the update will fail. | ||
| * eP: I fully agree, those things are a little orthogonal. | ||
| * eP: It may be a good idea because Noel is also working on CRDTs | ||
| * eP: We should probably organise a separate session about the question, *'how can we support CRDTs with Solid?'* and then Braid can be one of the options | ||
| * RG: There is no concept of time merging that can be introduced otherwise. In Noel's version, there is a specific type of CRDT, and Noel will be the first to admit that it's not a generic solution | ||
| * RG: But I want to emphasise, we should have patience because these specs are still in development | ||
| * eP: For me, all those topics are bringing back that we can evolve the Solid ecosystem over time. In the time of the WG, we may not get full support of CRDTs, but we can be ready for when the time comes. A future-proof strategy. We cannot wait for everything. | ||
| * MdJ: I agree, I guess we will just experiment with it. Server MAY support Braid. I'd like to work on that myself. We should have a session with interested people and ask the question, *'how do we support Local first?'* | ||
| * RG: We can talk about Local First. I would be more interested in if we can start experimenting with things on servers. The time to move spec is longer than what we can implement. We need a server of our own that we can experiment with. | ||
| * VB: I'm going to share that if the idea is to gather all the people working on this topic, I'm happy to set that up. | ||
|
|
||
| ACTION: VB to organize STM. | ||
|
|
||
| * eP: To respond to Rahul's point that CSS does not want to add features — it's designed to be modular. | ||
| * One can create custom components and mix them with core CSS components. | ||
| * MDJ: There is also Pivot and there is some funding to it. There are some issues holding it back. We can add extensions, add Braid, etc. | ||
| * eP: I would like to understand Pivot better, and what it tries to do. | ||
| * MDJ: It is just a config that configures CSS in a certain way. We need to change it in certain ways. If it requires code changes, we may just publish a small module on solid-contrib. If we need features that CSS doesn't provide, we may need to write a new module. | ||
| * TBL: I was exploring Braid and listening to Local First podcast. They try to do very similar things. It would be good to align Solid and Local First efforts. I'm worried about not-ready-yet and other options. It reminds me about not-invented-here. Braid bandwagen seems to have some energy. I'm worried about us starting something else. | ||
| * RG: There was a lot more context to the answer. I don't talk about not-invented-here. I've been following the whole Braid process. IETF feedback was to split Braid into multiple specs. Again, they've started, but some pieces are still missing, to be added in a more modular way. I only warned that we should treat it as experimental tech. | ||
| * TBL: 'experimental' sounds good | ||
| * eP: we should always keep in mind the normative references we make and maturity requirements. | ||
| * RG: This will not affect how Solid runs, a bunch of new headers. I see it as orthogonal. | ||
|
|
||
| ### Fix Test Cases to allow `201 (Created)` with `PATCH` | ||
|
|
||
| Don't know where this issue/PR needs to be filed. | ||
|
|
||
| Needed for: https://github.com/nodeSolidServer/node-solid-server/pull/1786 | ||
|
|
||
| * MDJ: we resolved this in the specification chat room, see https://github.com/nodeSolidServer/node-solid-server/pull/1786#issuecomment-2315391774 | ||
|
|
||
| ### Solid API Modeling | ||
|
|
||
| * FCG: Are there currently any RDF ontologies that would enable modeling the current Solid API specfications such that exports from that model could generate interoperable OpenAPI documentation? https://spec.openapis.org/oas/latest.html | ||
| * eP: have a look at Hydra CG (https://www.w3.org/groups/cg/hydra/) | ||
| * eP: Solid is probably more follow-your-nose, not URI templates. How do you see that from your requirement? | ||
| * FCG: We have a proposed search API. People who work with API specs can more easily start using Solid. We should keep in mind how the industry currently defines APIs. Is there an RDF ontology that models how APIs behave? | ||
| * TBL: You mentioned search API. I think for LDP, it doesn't matter. It wouldn't tell about things like shapes. For URI templates, autocomplete code pings SPARQL database in SolidOS. There is metadata there about which SPARQL endpoint is being used, for example, [DBpedia](https://dbpedia.org/sparql). | ||
| * eP: Do you have a link to your search proposal? | ||
| * FCG: We added some functionality to it, and I was looking at Inrupt's API docs, which looked machine-created, so that's how I got on this path, looking for a way to document it. I want it to be generated. We are planning to make our whole ontology public, including the hierarchy, soon. If you have any tips about docs generation, please post them on Matrix for us! | ||
|
|
||
| ### Access Delegation | ||
|
|
||
| URL: https://github.com/solid/data-interoperability-panel/issues/222 | ||
| URL: https://hackmd.io/@elf-pavlik/HJoZ62ERh | ||
|
|
||
|  | ||
|
|
||
| * eP: there are still some gaps, but when a resource owner delegates/gives access to another user, say Alice, and then Alice wants to delegate that access to an app she is using. Or maybe she needs to consult with Joe, and gives Joe read-only access. And Joe also wants to delegate to their preferred app. | ||
| * eP: There are some nuances — how is this delegation propagated? does it go back to authorization agents? there are a few topics here. I am finishing up this documentation and applied for some more [NLnet funding](https://nlnet.nl/funding.html). I would like to focus on this some more. | ||
| * eP: who else is interested in this? | ||
| * MDJ: I think this is an important goal but a difficult one. We do need delegation, to distinguish the user and the app. But if you have two users and the app of the second user than it becomes more difficult. If you have RO, they can add ACL to whitelist some apps, but the person who uses the app can whitelist it on the server. | ||
| * eP: from my perspective, ACLs already don't work, even with one user. For Alice to whitelist an app, even in a single step, it already doesn't work. | ||
| * MDJ: We could add it for the next week. | ||
| * TBL: I feel in practice being able to delegate things is a really valuable thing. However, I would for instance delegate to a group instead of a person, and then I can change the access by changing the group. I even have a group called "me", which has just me in it. :) | ||
| * MDJ: Ah, that's a great pattern, yes that would work. | ||
| * MdJ: That's all we have time for, hope to see you next week |