Meeting notes 2024-10-02.md

meetings/2024-10-02.md

@@ -0,0 +1,109 @@
+# W3C Solid Community Group: Weekly
+
+* Date: 2024-10-02T14: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)
+* Jesse Wright
+* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
+* [Virginia Balseiro](https://virginiabalseiro.com/#me)
+* Grace Elcock (observer)
+* [Sarven Capadisli](https://csarven.ca/#i)
+* [Rahul Gupta](https://cxres.pages.dev/profile#i)
+* Damon
+* Pierre-Antoine Champin
+
+---
+
+## Announcements
+
+* SC: W3C encourage people to join working groups, for instance as invited experts. It's important for continuity.
+
+### Meeting Guidelines
+* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
+* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
+* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
+* Join queue to talk.
+* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.
+
+### Participation and Code of Conduct
+* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
+* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Conduct](https://www.w3.org/policies/code-of-conduct/)
+* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
+* If this is your first time, welcome! please introduce yourself.
+
+
+### Scribes
+* Michiel de Jong
+* Sarven Capadisli
+
+### Introductions
+*
+
+---
+
+## Topics
+
+### Solid Interop in Practice
+
+URL: https://forum.solidproject.org/t/solid-interop-in-practice/7701
+
+* eP: we mentioned this topic two weeks ago, this is a write-up by Rosano, who interviewed multiple Solid app developers. My main take-away is people find especially client-client interop hard to work with
+* eP: General comments on JS, there is a lot of work there but it's not specific to Solid.
+* eP: Sharing and publishing specs. The expectation from app dev is that they have to write their own shapes. My take is that it shouldn't be up to each dev to come up with that. People working in the same domain come together and agree, maybe v1 of the shape. An individual shouldn't have all of the burden. Otherwise, I dont think we'll get to interop that way. The ecosystem needs a way for everyone to do it in a collaborative way. Perhaps look at things like schemaorg to collaborate on shapes.
+* eP: Another topic was on discovery. Currently having TypeIndexes and SAI. SAI requires server-side authorization agent. I applied with a project to NLnet to refactor an implementation of an authorization agent ??? in CSS. I plan to work over the next year to make it easier to have that deploy in CSS.
+* eP: Those were the main topics IMO.
+* eP: Other were specific kind of shape data. Things specific to a domain, e.g., blueprints in architecture. Calendar events would have different kind of requirements. For me, supporting ??? in different context. For example, sleepybike. I wouldn't authorize the app to see the messages between my doctor and I. If we say that hospitality thread have access to ??? we could narrow the relation data. Data matcher would have relations. One of the tasks I proposed was inheritance and manage the access control on how it is related. When you set access policies, you'll want to do it in a certain context. The only way I've seen that done is in SAI. I'm open to other possibilities it is important to do it with relations in the data.
+* MdJ: Regarding definition of shapes, would that be a role for the CG to provide a space or spaces for that?
+* JW: In SolidOS calls we were talking about shapes, and thinking about submitting a repo for that, and to reuse that cross applications. Also to get LDO type of things generated. While we were doing that JZ started a wiki on that.
+* MdJ: JM was doing something like that and have it done for Q4. There is PDS interop conventions repo. Some client-client specs in the Solid GH org, and also SolidOS. We have the contacts one. Some in Solid Labs Flanders also doing something IIRC. Perhaps we can provide meetings for developers to actually bringing them together, e.g., "what shape are you using?".
+* SC: https://github.com/solid/shapes/ . I'm trying to understand delta between the shapes repo. I think Jesse was also involved. Where is that prior thing overlap or differ.
+* eP: I think the technical infra is important but atm perhaps more on the process a way to work on things together and also separately. There is a general discussion started with WT. For example, the chat draft, and what should be domain specific and what's generic. With IRI templates for chat, I think that's kind of a bad design. For someting like shape trees and I tink CG should focus on that first. What the shape is for. What about nested shapes. I tink the CG has to adjust to finding those things. Then create a space for common things. Maybe have focused work groups on that. We may have little experience on that. My main point is about process and iterating. mentioned: https://shaperepo.com/
+* JW: TO extend eP's point. For LWS is first to focus on UCs. Perhaps worth trying to work with that for the task forces you're describing.
+* JW: re SC's existing GH's solid/shapes, I believe there is the place where we put the shapes for the NLnet project. That might be able to provide funding for these task forces, depending on approvl.
+* RG: It seems to me a lot of these issues are web platform issues not our issues. Do we define something like composible media types? It almost quickly falls out at what level we want to address these. I don't have an answer to these.
+* eP: When you say media types, with shapes we talk about RDF. I don't think media types is that much of an issue. I'm not sure if media types are the issue here. If each resource has its own graph, how do shapes are apply to different graphs. How do those datasets layed out.
+* RG: I get sense that how we define composability. Shape of shapes? Will come back to this.
+* MdJ: Yes, composability would be one of the topics around interop, like discoverability, authorization, etc.
+* SC: I think we should be careful on relying on any specific group output as an input for this group's work. In longer timeline LWS use cases can be a useful input. CG charter is broader than LWS. We even have some documents which are not perfect but they capture a lot. We should continue, aspects of this ecosystem go further any other gruop. We don't need to wait for anything. It is all incubation.
+* SC: There may be aspects of the protocol which are not going to be part of LWS. We can still write notifications protocol, work on PREP, work on access control. It is all in the scope for CG. Even that we talk about emphasis on client-to-client we shouldn't give up on the rest.
+* MdJ: Agree. Nice to think about interop between apps. Shapes is useful but so are things like notifications. Good to document shapes we see being used but not enough to put shapes in a wiki. Solid Data Modules project has ??? for ??? also funded by NLnet. We haven't finished that yet but am hoping for delivering code, including client-client.
+* eP: Let's say the CG, roughly speaking, works outside in. We can see what are the existing open source software we use or know in the community we use. For example, Discourse re Social Web CG has a task force for theaded discussions, from Open Food Network. Work with things that have specific behaviour and want to preserve it and centralise it. We already know the behaviour and there is a user base and don't need to reinvent. For me that's a useful approach. Like take 5 of them. While we do that, we encounter scenarios, such as order. Those orders and generic stuff besides food. Like working on exchanges, shipping etc. That's also specific domain but it crosses multiple similar domains Especially when devs are interested in collaborating. Like porting it to Solid. Let's try to do that for some stuff like event time organisation. For me that'd be most attractive. We wouldn't have to design the UX, just swap the engine.
+* RG: I think the larger conversation is what kind of a social infrastructure we want to build to bring all these people together. There is some merit to UC thing but we should be more open to out of box thing. What we think of the best possible system because we might not know what - just not necessarily the way LWS is thinking UCs. But be more broader / experimental.
+* MdJ: I like that. I think we can also focus on interop between applications. That uses Solid and make those work together. They might not be UCs we imagine. That's what I'd consider outside-in. Starting from real examples.
+* eP: Coming back to LWS UCs re overlap. As I understand hte harter, the client-client is out of scope. There is not going to be domain-specific. Naturally the WG will not fully satisfy all the UCs because there is always the client-client part. That's why I think the UCs should be shared. Ensuring what we have fits into the LWS.
+* RG: There can be generic use cases, I'll point you to Douglas Engelbart in that respect. Use cases don't necessarily have to be domain-specific. We have a generic UC on what knowledge-workshop would be and thats a good light of how software should be designed.
+* MdJ: To me the topic of how different specs are interoperable is interesting. As an app dev, one might use one and dev another. If all those things are incubating all being interop under Solid.
+
+
+### Use cases
+
+URL: https://solid.github.io/authorization-panel/authorization-ucr/
+URL: https://github.com/solid/user-stories
+URL: https://github.com/solid/webid-profile/blob/main/notes/use-cases.md
+URL: https://solid.github.io/notifications-panel/notifications-ucr
+
+* eP: Authorization use case were written in reverse, starting from WAC as a solution plus some know limitations.
+* eP: Instead of making up use cases, we can work with existing communities, preferably open source and document their real world usecases which already have user base. As an example we had a meeting with https://openfoodnetwork.org/
+* eP: We can also try to "eat our own cookings" more. This prototype tries to define some CG meetings based requirements https://github.com/janeirodigital/sai-js/tree/main/examples/plenary#requirements
+* eP: Unfortunately I didn't participate in the TPAC UC meeting.
+* eP: We (CG) has a bunch of work on this already (linked above).
+* eP: We need to have UCR managed in a way to evaluate proposals. Do we do it by simplicity or emotions or something else? ??? objectively. We can have a matrix for the proposals, then we can see best on practice. With e.g., added complexity, we could do with simpler. This is because different people coming with different proposals. Once we have implementation experience it is going to be subjective. We can have some rough way of evaluating the complexity. For me the main point for the UCs is to evaluate all the proposals. We are kind of stuck on what to focus on.
+* RG: I like a lot of the ideas behind on having some process to make a note of it, but at the end of the day we could do the matrices etc but it'll be subjective and no real way of measuring complexity. It is more of art than science.
+* MdJ: We can measure complexity by looking at how many implementing. Adding traction as a criteria.
+* RG: That's one measure and so many different ways of measuring. It is not something we can solve for, but to have an intuition for.
+* MdJ: If you look to see what solutions get traction, that is a proxy for how complex they are to implement. Look at shape files for instance, very few app devs write them, I think that's an indication that it's quite a complex solution.
+* SC: Use cases are important. In the past we had a use case survery, which ties to Michiel's point. This can signal from the community interest and commitment. People are brining up age old issues about Solid should be doing this or that. We have an aboundance of use cases. Data portability comes up, access requests. We had issues, we had proposals. For example [data migrator](https://pdsinterop.org/solid-migrator/). I'm also part of this and we didn't do great job on evaluating those proposals. We need storage provisiooning, migrating storate. There are proposals and we don't give them enough attention. Later in the future we come back "oh we need that". We do need those use cases but there are solutions in front of us. A solution is better than no solution. Recently we heard need for digital wallets, sometimes it is hard to dig out those proposals. We need to be evaluating those solutions, if we don't them enough attention people get impression that we don't take them seriously. I don't want us to get lost in the process and loos track of simple solutions in front of us.
+* eP: I hear there is an agreement on evaluating proposal. Also agree with SC on signal from community and what to implement. If UCs are real-world, then if a UC is not mine but an alternative is like mine, then I can use those three requirements. We can look at more generic and specific level. (from chat: example - https://github.com/solid/authorization-panel/tree/main/proposals/evaluation)
+* eP: re MdJ, we need to have a little more signaling. How the dev chooses one of the alternative proposals. With a matrix the dev can say I also have those requirements so I'll try to implement or 80% is good enough. Other people can make educated guesses on what to use. We also need the matrix of which proposal would allow implementers to decide. Also to know what they like or don't like.
+* MdJ: Also need people to vote with their feet.
+* RG: SC, one of the things is that all of these discusssions are very buried. I try to stab at one or two of these things, but we really need some effort to bring all of those from GH. You have this incredible domain knowledge due to you having been here for years but most of us are newer. There has to be more visibility on those discussions.
+* PAC: To react to SC, taking into account previous work, i think it is very important. It might be very importnt in the LWS WG for each UC. But also maybe reference earlier work in order to see what the CG has done with the UCs. So, ack not at all starting from scratch.
+* eP: Agree with PAC on crowdsourcing. I think it is fair to put the burden on the proposer to mark what requirements it is addressing.
+* PAC: I agree that we have a living UCs for the CG. For the WG, there is more of a deadline driven UCs. Also to decide how we design the REC. Both are valuable. Please don't expect the WG to drive the UCs. The scope of the WG is narrower. There should be between the two work. LWS would have a subset of UCs.
+* eP (in chat): the dataset can aggregate use cases and requirements from the WG. the work Jeff does on the catalog and me on solid efforts can provide some foundations for it