Meeting notes 2024-10-02.md (#687)

* Create 2024-10-02.md

* Apply suggestions from @TallTed

Co-authored-by: Ted Thibodeau Jr <[email protected]>

---------

Co-authored-by: Ted Thibodeau Jr <[email protected]>

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 client-client interop especially 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 devs 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 can come together and agree, maybe v1 of the shape. An individual shouldn't have the whole burden. Otherwise, I don't think we'll get to interop. The ecosystem needs a way for everyone to work in a collaborative way. Perhaps look at things like schema.org to collaborate on shapes.
+* eP: Another topic was on discovery. Currently have TypeIndexes and SAI. SAI requires a server-side authorization agent. I applied to NLnet with a project to refactor an implementation of an authorization agent ??? in CSS. I plan to work to make it easier to have that deploy in CSS over the next year.
+* eP: Those were the main topics, IMO.
+* eP: Other were about specific kinds of shape data. Things specific to a domain, e.g., blueprints in architecture. Calendar events would have different 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 threads have access to ???, we could narrow the relation data. Data matcher would have relations. One of the tasks I proposed was inheritance and managing 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 reusing them across 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 will 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 bring them together, e.g., "what shape are you using?"
+* SC: <https://github.com/solid/shapes/>. I'm trying to understand the delta between the shapes repos. I think Jesse was also involved. Where do those prior things 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 something like shape trees and I think CG should focus on that first. What the shape is for. What about nested shapes? I think the CG has to adjust to finding those things. Then create a space for common things. Maybe have focused task forces on them. We may have little experience on them. My main point is about process and iterating. Also mentioned <https://shaperepo.com/>.
+* JW: To extend eP's point. For LWS, first is 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 approval.
+* RG: It seems to me a lot of these issues are web platform issues, not our issues. Do we define something like composable 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 lay 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 about relying on any specific group's output as an input for this group's work. In longer timeline, LWS use cases can be a useful input. Solid CG charter is broader than LWS WG. We have some documents which are not perfect, but they capture a lot. We should continue; aspects of this ecosystem go further than any other group. 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 scope for Solid CG. Even though we talk about an emphasis on client-to-client, we shouldn't give up on the rest.
+* MdJ: Agree. Nice to think about interop between apps. Shapes are 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 are hoping to deliver code, including client-client.
+* eP: Let's say the CG, roughly speaking, works outside-in. We can see the existing open source software we use or know is used in the community. For example, Discourse re Social Web CG has a task force for threaded 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; we 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 do we want to build to bring all these people together? There is some merit to UC, but we should be more open to out-of-box things. What we think of as the best possible system might be because do not know that — 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 the harter, the client-client is out of scope. There is not going to be domain-specific work. 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, to ensure that 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 a knowledge-workshop would be and thats a good light on 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 interoperable 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 known limitations.
+* eP: Instead of making up use cases, we can work with existing communities, preferably open source, and document their real world use cases, which already have a user base. As an example, we had a meeting with <https://openfoodnetwork.org/>
+* eP: We can also try to "eat our own cooking" 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, for instance, added complexity, we could do with simpler. This is because different people come 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 about what to focus on.
+* RG: I like a lot of the ideas about 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 an art than a science.
+* MdJ: We can measure complexity by looking at how many are implementing. Add traction as a criteria.
+* RG: That's one measurement with many different ways of being measure. It is not something we can solve for, but can 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 survey, which ties to Michiel's point. This can signal interest and commitment from the community. People are bringing up age old issues about "Solid should be doing this or that". We have an abundance 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 provisioning, storage migration. 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 a need for digital wallets; sometimes it is hard to dig out those proposals. We need to be evaluating those solutions. If we don't give them enough attention, people get the impression that we don't take them seriously. I don't want us to get lost in the process and lose track of simple solutions in front of us.
+* eP: I hear an agreement on evaluating proposals. Also agree with SC on signals from community about 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 proposals to 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, I think it is very important to take previous work into account. It might be very important in the LWS WG for each UC. But also, maybe reference earlier work, to see what the CG has done with the UCs. So, 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 UC for the CG. For the WG, there is more of a deadline-driven UC. 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 work between the two. 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