Fix present

meetings/2023-10-10.md

@@ -9,7 +9,7 @@
 ## Present
 * [Sarven Capadisli](https://csarven.ca/#i)
 * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
-* Rahul Gupta
+* [Rahul Gupta](https://cxres.pages.dev/profile#i)
 * April Daly
 * Jeff Zucker
 * Tim Berners-Lee
@@ -105,4 +105,4 @@ ACTION: eP to investigate [Github Code Owners feature](https://docs.github.com/e
 
 * SC: TR/EDs that are taken up as deliverables in the WG would be frozen while WG is active.
 * SC: once WG expires, there still might be work needed with errata and future work.
-* 
+*

meetings/2023-11-29.md

@@ -11,13 +11,13 @@
 * [Virginia Balseiro](https://virginiabalseiro.com/#me)
 * [elf Pavlik](https://elf-pavlik.hackers4peace.net)
 * Aaron Coburn
-* Michiel de Jong 
+* Michiel de Jong
 * Hadrian Zbarcea (Inrupt)
 * [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
 * Gordana Halavanja
 * Tim Berners-Lee
 * Michael Toomim
-* [Ted Thibodeau Jr](https://github.com/TallTed) (he/him) ([OpenLink Software](https://www.openlinksw.com/))
+* [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/))
 * Jeff Zucker
 
 ---
@@ -52,7 +52,7 @@
 
 ### Holiday Break
 * SC: We can use a break, and there is the general holiday time in December for some. We can cancel the following meetings: 2023-12-20, 2023-12-27, 2024-01-03. Any objection?
-* SC: No objections. 
+* SC: No objections.
 
 ### Special Topic Meetings
 URL: https://github.com/solid/specification/discussions/555
@@ -67,31 +67,31 @@ URL: https://github.com/solid/specification/discussions/555
 ### WIP Implementation Feedback
 
 * SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
-* eP: RG is not present but asked MT to present [Braid](https://braid.org/). We should prioritize since MT is present today. 
-* SC: 10 minute demo would be great. 
+* eP: RG is not present but asked MT to present [Braid](https://braid.org/). We should prioritize since MT is present today.
+* SC: 10 minute demo would be great.
 
 ### Braid Overview and Demo
-* MT: Braid is working on state synchronization, adding to HTTP, which Solid can use to get real-time updates of your state. 
+* MT: Braid is working on state synchronization, adding to HTTP, which Solid can use to get real-time updates of your state.
 
 [demo/screenshare]
 
 * SC: Is the extension available publicly?
 * MT: Yes
 * SC: https://github.com/braid-org/braid-chrome
-* eP: How does it work with media types? How does it work with HTTP, does it use fetch? 
-* MT: Implemented on top of fetch. We have a library, `braid-http`, that wraps fetch and parses response. It can work with any media type. 
-* TBL: You can pretty-print RDF and it reads like JSON. 
+* eP: How does it work with media types? How does it work with HTTP, does it use fetch?
+* MT: Implemented on top of fetch. We have a library, `braid-http`, that wraps fetch and parses response. It can work with any media type.
+* TBL: You can pretty-print RDF and it reads like JSON.
 * eP: (chat) or <https://www.w3.org/TR/rdf-canon/>?
 * MdJ: ??? get a generic way to deal with collaboration. Different systems express changes in different ways. Second problem is differing algorithms for computing state based on sets of changes. People say it's impossible. What do you think?
-* MT: ??? we have taken corner cases and looked at them. As we prove algorithms converge to same ???, that problem goes away. 
+* MT: ??? we have taken corner cases and looked at them. As we prove algorithms converge to same ???, that problem goes away.
 * HZ: Are you familiar with [Apache Wave](https://incubator.apache.org/projects/wave.html) (previously known as Google Wave)? What are the differences?
-* MT: Google used ??? for synchronization. 
+* MT: Google used ??? for synchronization.
 * SC: I work on an authoring tool and one of the questions is how to do synchronization. Is the spec work being carried out at IETF?
 * MT: There's interest in HTTP WG.
-* SC: Solid might be looking at ways to extend for RDF for example. 
+* SC: Solid might be looking at ways to extend for RDF for example.
 * MT: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http
 * eP: If someone wants to make a Solid app using Braid, I understand there's a fetch extension. ??? could be used on server.
-* MT: [`npm` braid-http package](https://www.npmjs.com/package/braid-http) has both client and server code 
+* MT: [`npm` braid-http package](https://www.npmjs.com/package/braid-http) has both client and server code
 * TBL: SolidOS code has a very ??? stack using websockets. We change the Solid API library and ???
 
 
@@ -108,14 +108,14 @@ URL: https://github.com/solid/specification/discussions/582
 * SC: PAC can process these now. Please review. See also https://lists.w3.org/Archives/Public/public-solid/2023Nov/0083.html and thread for discussion.
 * PAC: Few clarifications: this is a straw-man proposal. Goal is to explore a possible direction. It might be useful to make a distinction between Solid as a vision/problem-space and a solution/set-of-specs. Effort on mailing list towards an explainer might help because it addresses both sides. If we can make it clear what the problems are and how we are currently solving them, it might help the case that it is about Solid, but open to other solutions.
 * SC: My interpretation was that it was exploratory, as opposed to a concrete proposal. There's a history of why we ended up here with decisions around Protocol, LDP, and so on. We need to keep that in mind and not go back to drawing board or re-do the protocol. We need to look at what's really intended.
-* eP: For me, the main step would be focusing on authorization. One thing Solid adds is access control aspect. Given experience with WAC, ACP, access grants, there's ??? There could be different systems. We have enough to look at minimal ways to achieve that. 
-* TBL: As SC said, these decisions were made and everybody agreed and we have code implementing those decisions. The idea that we should start from scratch means running code would not be able to use that. We could call it something else but it would be confusing. 
-* PAC: I understand decisions were made for good reasons. W3C does not want to create a group whose sole mission is to rubber stamp something from outside. Solid specs would be used as inputs, but other inputs should be welcome. Need to define problem space so that decisions made by Solid can be argued as a good way to solve that problem space. This should be a consequence of how well we define the problem space, as opposed to coming with an existing spec. 
+* eP: For me, the main step would be focusing on authorization. One thing Solid adds is access control aspect. Given experience with WAC, ACP, access grants, there's ??? There could be different systems. We have enough to look at minimal ways to achieve that.
+* TBL: As SC said, these decisions were made and everybody agreed and we have code implementing those decisions. The idea that we should start from scratch means running code would not be able to use that. We could call it something else but it would be confusing.
+* PAC: I understand decisions were made for good reasons. W3C does not want to create a group whose sole mission is to rubber stamp something from outside. Solid specs would be used as inputs, but other inputs should be welcome. Need to define problem space so that decisions made by Solid can be argued as a good way to solve that problem space. This should be a consequence of how well we define the problem space, as opposed to coming with an existing spec.
 * SC: The way WAC is written is not at all coupled with Solid Protocol, but it can work alongside Solid Protocol, LDP, ActivityPub. Would you consider that as an example where it's not a solution looking for a rubber stamp? Is that the kind of framing that may help?
-* PAC: It's another aspect. Having pieces of the work framed in a way that can be used in other contexts is a good thing. Boils down to describing the problem space and then, once we have it precisely described, we can identify connections with other existing specs. For example, AP could benefit from WAC because WAC solves a bigger problem that exists in both Solid and AP. That'd be a nice side effect of focusing on the problem space. 
+* PAC: It's another aspect. Having pieces of the work framed in a way that can be used in other contexts is a good thing. Boils down to describing the problem space and then, once we have it precisely described, we can identify connections with other existing specs. For example, AP could benefit from WAC because WAC solves a bigger problem that exists in both Solid and AP. That'd be a nice side effect of focusing on the problem space.
 * SC: And again anything using LDP that needs authorization.
 * PAC: Yes.
-* MdJ: Some of this is about branding. PAC and I had a meeting and I proposed to have Solid as a ???, not naming it after a solution. There are other specs that will be worked on in the CG that are also part of Solid. WG should have Solid 1.0 as an end result, 2 years from now. We have lots of things that we don't have working like fine-grained access control. Maybe it's more honest to say the specs we have now do not solve all the problems we want to solve which is part of what TAG was poiting at. Rebranding the WG might help. 
+* MdJ: Some of this is about branding. PAC and I had a meeting and I proposed to have Solid as a ???, not naming it after a solution. There are other specs that will be worked on in the CG that are also part of Solid. WG should have Solid 1.0 as an end result, 2 years from now. We have lots of things that we don't have working like fine-grained access control. Maybe it's more honest to say the specs we have now do not solve all the problems we want to solve which is part of what TAG was poiting at. Rebranding the WG might help.
 * SC: One thing we didn't do right was looking at related or similar works/specs that address the same problem space. I replied to PAC on the mailing list, one example was Fedora spec. They have worked with LDP and put out stuff we haven't even touched like versioning. I can see that being put under the same umbrella. Input for that would be Solid protocol, Fedora, and others, and we can go through that with authorization, and other specs with track record of incubation, and the WG can make the best of it to solve the general problem. Right now it's Solid-centric and I understand why that doesn't fly with everyone else outside Solid.
 * MdJ: Even if you take versioning, you still don't have client-client specs in WG. It's more honest to say the WG will ??? what server does and a lot more happens on client side.
 * TBL: We can reverse engineer the requirements from the spec? Maybe. We have to make sure that we get everything which has been maybe implicit over the years. Process to start again with requirements?  Requirement: everyone who writes a Solid app has the benefit that they don't need to make any changes to the server.  Other platforms people have brought up, like [OSLC](https://open-services.net/), don't have that property.
@@ -144,8 +144,8 @@ URL: https://github.com/solid/specification/pull/575
 ### Solid Practitioners
 URL: https://github.com/solid-contrib/practitioners/
 
-* JZ: We started a new group called Solid Practitioners. Purpose is to work bottom up rather than top down. Focus on people actually creating usable products with Solid, especially those producing social benefit. We have a repo, chatroom, and meetings. Next one is tomorrow at 1700UTC. We intend to focus on project being worked on. Currently homelessness projects in Portland, bike project worldwide, Flanders, group from Mexico City. Some production, some approaching. 
-* SC: Glad you're leading this work. Important for ecosystem and community. 
+* JZ: We started a new group called Solid Practitioners. Purpose is to work bottom up rather than top down. Focus on people actually creating usable products with Solid, especially those producing social benefit. We have a repo, chatroom, and meetings. Next one is tomorrow at 1700UTC. We intend to focus on project being worked on. Currently homelessness projects in Portland, bike project worldwide, Flanders, group from Mexico City. Some production, some approaching.
+* SC: Glad you're leading this work. Important for ecosystem and community.
 
 ---