diff --git a/meetings/2023-10-10.md b/meetings/2023-10-10.md index af3055fd..ce3f9ece 100644 --- a/meetings/2023-10-10.md +++ b/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. -* \ No newline at end of file +* diff --git a/meetings/2023-11-29.md b/meetings/2023-11-29.md index 85f31fe8..5aa78ea1 100644 --- a/meetings/2023-11-29.md +++ b/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 ? * 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. --- diff --git a/meetings/2023-12-05.md b/meetings/2023-12-05.md index f7ffd723..334cdc72 100644 --- a/meetings/2023-12-05.md +++ b/meetings/2023-12-05.md @@ -7,7 +7,7 @@ ## Present * [Sarven Capadisli](https://csarven.ca/#i) * [Virginia Balseiro](https://virginiabalseiro.com/#me) -* [Ted Thibodeau Jr](https://github.com/TallTed) (he/him) (OpenLink Software) +* [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * Maxime Lecoq * [Michiel de Jong](https://michielbdejong.com) @@ -58,14 +58,14 @@ * elf Pavlik ### Introductions -* Tantek: Tantek Γ‡elik, Mozilla, was co-chair of Social Web WG (2014-2018) +* Tantek: Tantek Γ‡elik, Mozilla, was co-chair of Social Web WG (2014-2018) * bumblefudge (Juan Caballero): i'm researching ActivityPub "devex" and tooling, working very part-time on a tiny grant about same, no real understanding of Solid (high level or current-state!) so that would be appreciated * Michiel de Jong: have worked on unhosted web apps for a while, interest in both social web and personal data stores including Solid. Affiliation: Ponder Source (a small non-profit software company). -* Philippe Le Hegaret: W3C/Strategy Lead +* Philippe Le Hegaret: W3C/Strategy Lead * elf Pavlik (independent): I co-edit Solid-OIDC with Aaron as well as Solid Application Interoperability. I also maintain https://github.com/janeirodigital/sai-js * RG: Rahul Gupta, independent, Author of PREP, Co-author of Solid Notifications and contributor to Solid since 2020. Founder/Creator of [Syntropize](https://syntropize.com), a proposed Operating Environment which decentralizes data and applications. * Emelia S: Emelia Smith, I'm a former Inrupt employee, worked on Inrupt Solid SDKs, now I work on trust & safety for the fediverse and contribute to Mastodon, Pixelfed, and am a technical advisor to [IFTAS](https://about.iftas.org/) (this is being announced today/tomorrow). Independent. -* Sarven Capadisli , Independent. Solid CG Chair (2019-present) +* Sarven Capadisli , Independent. Solid CG Chair (2019-present) * Ted "[TallTed](https://github.com/TallTed)" Thibodeau, [OpenLink Software](https://www.openlinksw.com/) (2000-present). Identity, Privacy, Linked Data, RDF, and related CGs and WGs. Primary coding language is English, evidenced by a kajillion change requests. * Matthias Evering (@ewingson), independent, junior half pro pod provider * SΓ©bastien Rosset. Member of Virtual Assembly (France). Working since 2021 on [ActivityPods](https://activitypods.org) a software which aims to reconcile Solid Pods and ActivityPub. @@ -89,32 +89,32 @@ Proposed by [Sarven Capadisli](https://csarven.ca/#i). * SC: [Call to Contribute to Prospective WG Scope](https://www.w3.org/wiki/SocialCG/WG_Charter_Discussion) * TC: Social CG was established upon close of Social Web WG as a place to discuss specs produced by SW WG. Lot of focus on ActivityPub and Activity Streams. Evan P. has picked up editing of AP and regularly holding triage calls to go through issues, towards developing an errata and a revision of AP. Other specifications produced by SW WG are maintained in https://spec.indieweb.org * bumblefudge: Forum: https://socialhub.activitypub.rocks/ & Proposals for standards: https://codeberg.org/fediverse/fep/ - -* TC: Mailing list was created about a year ago. -* TC: There's overlap in use cases and desired user flows that different groups want to solve. There's more to be gained from collaborating and trying to find ways for different approaches to interoperate. -* SC: I tried not to say too much on mailing list about joint meeting because when people hear Solid/Social they have different understandings of what those mean. Not just these two communities but other communities are working on similar use cases, personal data and so on. -* SC: Historically from Solid perspective we took "social" as a given but ot to the extend Social Web puts on social. Of course the web is inherently social and that involves personal data and social interactions, but Solid wasn't so much trying to address those open challenges that are going on in Social Web like third party control and major centralized services, social acitvities being poured into these, and ethical considerations and harm that can be done. Social Web a bit more generic about controlling data and access given and so on. There's understanding of similar use cases, but we should have had one of these calls years ago. But after Social Web WG, social web has been quietly moving in the fediverse as opposed to CG. -* SC: There's shared interest and we come from the same philosophy about having control over data and activities on the web. -* TBL: When we say Social Linked Data, how come does that not ??? the community group? We called it the read-write web. It was suggested that it should be called Social Linked Data. If you write a solid app you should always think in the context of all the other people's data. It's not just about one person, but all people. The social graph of people is important. On the other hand you can write any solid app as a generic ??? because Solid pod is agnostic as to what it uses. The pod doesn't care or know what app is used. All it does is authn/authz and not care about the type of data. So it's any linked data... the fact that it's called solid does not mean we're ??? we're focusing on the social use cases but it's a very generic platform. -* TC: Great summary. SC posed the question that we should have met earlier. There's interesting broader context, potential collaborating beyond efforts described today, there's internet archive conducting a series of dweb conferences to get ideas pollinating. Implosion of twitter has spurred a bunch of projects as well, BlueSky (https://atproto.com/), nostr. They take different approaches but enough commonalities to have bridges. The fact that is possible is due to a lot of the people here, to try to get just enough vocabulary/semantic compatibility, using same terms to mean the same things. -* TC: when SW CG started there was a workshop in 2013 where a lot of protocols and format were demonstrated. Of those about 15 were proposed in SW WG. Of those we refined to 3 practical approaches with strong community interest, and that's how we ended up in the current situation. Adoption of these approaches has been a net benefit to all, despite general approach to standards being "you only want one". The HTML-based IndieWeb has continued to grow with software, services, users. ActivityPub and Mastodon have grown a lot as well, also in software, services, and adoption. There's also strong LD community with a bunch of apps. Each of these approaches has flourished. + +* TC: Mailing list was created about a year ago. +* TC: There's overlap in use cases and desired user flows that different groups want to solve. There's more to be gained from collaborating and trying to find ways for different approaches to interoperate. +* SC: I tried not to say too much on mailing list about joint meeting because when people hear Solid/Social they have different understandings of what those mean. Not just these two communities but other communities are working on similar use cases, personal data and so on. +* SC: Historically from Solid perspective we took "social" as a given but ot to the extend Social Web puts on social. Of course the web is inherently social and that involves personal data and social interactions, but Solid wasn't so much trying to address those open challenges that are going on in Social Web like third party control and major centralized services, social acitvities being poured into these, and ethical considerations and harm that can be done. Social Web a bit more generic about controlling data and access given and so on. There's understanding of similar use cases, but we should have had one of these calls years ago. But after Social Web WG, social web has been quietly moving in the fediverse as opposed to CG. +* SC: There's shared interest and we come from the same philosophy about having control over data and activities on the web. +* TBL: When we say Social Linked Data, how come does that not ??? the community group? We called it the read-write web. It was suggested that it should be called Social Linked Data. If you write a solid app you should always think in the context of all the other people's data. It's not just about one person, but all people. The social graph of people is important. On the other hand you can write any solid app as a generic ??? because Solid pod is agnostic as to what it uses. The pod doesn't care or know what app is used. All it does is authn/authz and not care about the type of data. So it's any linked data... the fact that it's called solid does not mean we're ??? we're focusing on the social use cases but it's a very generic platform. +* TC: Great summary. SC posed the question that we should have met earlier. There's interesting broader context, potential collaborating beyond efforts described today, there's internet archive conducting a series of dweb conferences to get ideas pollinating. Implosion of twitter has spurred a bunch of projects as well, BlueSky (https://atproto.com/), nostr. They take different approaches but enough commonalities to have bridges. The fact that is possible is due to a lot of the people here, to try to get just enough vocabulary/semantic compatibility, using same terms to mean the same things. +* TC: when SW CG started there was a workshop in 2013 where a lot of protocols and format were demonstrated. Of those about 15 were proposed in SW WG. Of those we refined to 3 practical approaches with strong community interest, and that's how we ended up in the current situation. Adoption of these approaches has been a net benefit to all, despite general approach to standards being "you only want one". The HTML-based IndieWeb has continued to grow with software, services, users. ActivityPub and Mastodon have grown a lot as well, also in software, services, and adoption. There's also strong LD community with a bunch of apps. Each of these approaches has flourished. * [in chat: bumblefudge: `bluesky : fediverse :: atproto : activitypub` https://atproto.com/] -* SC: I always found the philosophies and design considerations to be quite interesting. There's always different end result, and that's almost arbitrary, even within LD community people argue about their favorite format. So end result can be completely different. We had a bit of that on SW. The bigger concerns were actually whether we're solving the problems we agreed, broader societal issues on the web. I'm hoping we can re-focus in this particular meeting or future meetings in revisiting some of those issues, because we want to have individuals/communities/groups/orgs to have a better sense of their data,how they can express it and share it. +* SC: I always found the philosophies and design considerations to be quite interesting. There's always different end result, and that's almost arbitrary, even within LD community people argue about their favorite format. So end result can be completely different. We had a bit of that on SW. The bigger concerns were actually whether we're solving the problems we agreed, broader societal issues on the web. I'm hoping we can re-focus in this particular meeting or future meetings in revisiting some of those issues, because we want to have individuals/communities/groups/orgs to have a better sense of their data,how they can express it and share it. * [in chat: bumblefudge: to Sarven's point about anchoring interop goals in user stories and real world demand, i would suggest coming back to the user stories which were voted on in the minutes of one meeting but never really edited as a CG Note? https://github.com/swicg/general/issues/30 ] - * [ SC: bumblefudge, some user stories from the Solid end are documented here: + * [ SC: bumblefudge, some user stories from the Solid end are documented here: https://github.com/solid/user-stories ] * BW: It's important to point out it's been wonderful to see different approaches, nostr approach is interesting because it is so different, but as a community we haven't put enough effort into consolidating the knowledge and come up with approaches that adopt from other systems' good points and leave behind bad point. We have not done a good job in reducing the unnecessary amount of diversity and have common learnings. One thing about Solid is that it gives user control/ownership over its own data, which AP systems do not. It requires the person running a instance to own the data. That's a great weakness of how we implement AP. The fact that the protocol works that way does not mean the clients need to work that way. By collaboration Solid + AP we would be able to move forward. Diversity has been wonderful but we haven't done enough to figure out how we can learn from others and reduce the need for diversity by coming up with common solutions. -* ES: There is the client-server protocol in AP but due to the way a lot of servers work it was never implemented. Maybe that gives indication of how we ended up with server centered approach. as far as ??? it uses JSON-LD but we have ended up in fediverse with a lot of ??? that aren't part of any specification. Lots in more driven by implementations rather than standards. +* ES: There is the client-server protocol in AP but due to the way a lot of servers work it was never implemented. Maybe that gives indication of how we ended up with server centered approach. as far as ??? it uses JSON-LD but we have ended up in fediverse with a lot of ??? that aren't part of any specification. Lots in more driven by implementations rather than standards. * [in chat: bumblefudge: me says:the defacto standard of the Mastodon API πŸ˜„ ] -* eP: I'd like to clarify the scope of Solid and social web CG. I see Solid as more general/broad scope, where use cases I see use cases with healthcare, employment, supply chain, etc. Very broad use cases, while from my recalling of AP it is mostly about news feeds. Would be interesting to find the scopes of different projects and see the overlap. Narrow scope allows for simpler solutions. -* DZ: One of the things that SW can learn from Solid CG is access control. One of the main things lacking in the fediverse is the notion of access controls or friends' only posts. Among other aspects. -* BW: Along with access control, AP Collections are massively underspecified which causes all kinds of trouble. Solid, because it is focused on storage, does a lot with collections. AP would benefit from learning how to get a useful specification for collections. On access control, I've been suggesting AP too look more like ODRL because ??? and we don't have that right now. The right to reply is something that comes up, right to search/index people's content. Set of rights AP user want to grant/withhold and we have no method of doing that. Solid is primarily concerned with traditional access control. We know there's big holes in AP. There's opportunity to do something useful by comining efforts. -* ES: Accross fediverse there's not a standard for authn or authz. it is whatever the sever implements. Some have implemented some form of auth/oidc, but very hit or miss and do not support certain server metadata endpoints [which would help interop]; a lot pf this is driven by a desire to adopt the mastodon API, the defacto standard [since authZ is out of scope for AP]. +* eP: I'd like to clarify the scope of Solid and social web CG. I see Solid as more general/broad scope, where use cases I see use cases with healthcare, employment, supply chain, etc. Very broad use cases, while from my recalling of AP it is mostly about news feeds. Would be interesting to find the scopes of different projects and see the overlap. Narrow scope allows for simpler solutions. +* DZ: One of the things that SW can learn from Solid CG is access control. One of the main things lacking in the fediverse is the notion of access controls or friends' only posts. Among other aspects. +* BW: Along with access control, AP Collections are massively underspecified which causes all kinds of trouble. Solid, because it is focused on storage, does a lot with collections. AP would benefit from learning how to get a useful specification for collections. On access control, I've been suggesting AP too look more like ODRL because ??? and we don't have that right now. The right to reply is something that comes up, right to search/index people's content. Set of rights AP user want to grant/withhold and we have no method of doing that. Solid is primarily concerned with traditional access control. We know there's big holes in AP. There's opportunity to do something useful by comining efforts. +* ES: Accross fediverse there's not a standard for authn or authz. it is whatever the sever implements. Some have implemented some form of auth/oidc, but very hit or miss and do not support certain server metadata endpoints [which would help interop]; a lot pf this is driven by a desire to adopt the mastodon API, the defacto standard [since authZ is out of scope for AP]. * TC: SW WG was able to agree on values and methodology, but the one about user owning data is something we had universal agreement on. Also on technical apporaches like "follow your nose" as a method of discovery. The whole concept of using [HTTP] URLs to represent individuals was also something we made sure worked well across specifications. On the point of fediverse not allowing users to own data, [diaspora pods] was trying to achieve that goal since 2009/2010, generic approach to data storage and ownership has been there for a long time, but strong focus on social aspects. AP can be used with any vocabulary, not restricted to AS. Micropub is a way to generically put data back/forth on a server, most often used on social data. Access control as area to learn from, protected/limited audiences is a strong interest in IndieWeb (e.g. using TicketAuth extension to IndieAuth which itself is based on OAuth), good that we're using the same underlying technologies like OAuth. Even user interfaces of very social media silos, and what we learn from interactions/human behaviors, is that there's a lot of access control needs that's beyond any existing protocol. - * [in chat: bumblefudge: -https://codeberg.org/fediverse/fep/src/branch/main/fep/5624/fep-5624.md <-- One proposal for AuthZ per object can be found here ] + * [in chat: bumblefudge: +https://codeberg.org/fediverse/fep/src/branch/main/fep/5624/fep-5624.md <-- One proposal for AuthZ per object can be found here ] * [in chat: ES: One thing that is certainly notable perhaps is that almost all activitypub servers require some logic to process incoming activities, so it wouldn't necessarily be directly implementable with Solid, which just currently gives very basic file-type resource access (e.g., you can't have a virtual object that's doing some logic to e.g., collate all your activities into an outbox) ] -* SC: +1. We've barely scratched the surface with the specs we have. Actual challenges/concerns people have today. +* SC: +1. We've barely scratched the surface with the specs we have. Actual challenges/concerns people have today. ### Introduction to the Solid CG @@ -128,11 +128,11 @@ Proposed by [Sarven Capadisli](https://csarven.ca/#i). * SC: [Proposal for Solid WG charter](https://solid.github.io/solid-wg-charter/charter/). * SC: [Solid QA](https://solidproject.org/ED/qa) builds on the work of the [W3C QA Activity](https://www.w3.org/QA/Activity). -* SC: We have a charter, similar to other CGs. We had quite a bit of support in the group re: development. Details how we have new work items... resembles WG charter but with a lower bar for expectations. We have a chair election process which is currently underway, with three new chairs to be appointed soon. -* SC: TR covers protocol, notifications, authorization, and so on, with some data modeling as to how we express profiles, chats, all in progress. -* SC: We proposed a WG charter to W3C, we had some feedback from AC and horizontal reviews. There's some work we need to do to get the charter to express both the background but also suitable for the wider W3C and web community as to problems being solved. -* SC: Solid QA is quite central to the work we do. Test suite development as well as ???, how test coverages are connected, implementation report based on reviews of test authors and other reviewers. Based off W3C QA work, lots of great work there. We have a vocabulary that helps us express significant units of information in a spec. -* SC: There's an ocean of specs because Solid covers a broad problem space. We have implementation experience in server and clients. +* SC: We have a charter, similar to other CGs. We had quite a bit of support in the group re: development. Details how we have new work items... resembles WG charter but with a lower bar for expectations. We have a chair election process which is currently underway, with three new chairs to be appointed soon. +* SC: TR covers protocol, notifications, authorization, and so on, with some data modeling as to how we express profiles, chats, all in progress. +* SC: We proposed a WG charter to W3C, we had some feedback from AC and horizontal reviews. There's some work we need to do to get the charter to express both the background but also suitable for the wider W3C and web community as to problems being solved. +* SC: Solid QA is quite central to the work we do. Test suite development as well as ???, how test coverages are connected, implementation report based on reviews of test authors and other reviewers. Based off W3C QA work, lots of great work there. We have a vocabulary that helps us express significant units of information in a spec. +* SC: There's an ocean of specs because Solid covers a broad problem space. We have implementation experience in server and clients. ## Open Discussion @@ -150,8 +150,8 @@ Proposed by [Sarven Capadisli](https://csarven.ca/#i). * ES: [OCapPub](https://gitlab.com/spritely/ocappub), extension of ActivityPub that uses OCaps for authenticating/authorizing different actions * SC: [Web Access Control](https://solidproject.org/TR/wac), [Access Control Policy](https://solidproject.org/TR/acp) -* SC: I mentioned some of authn/z things because we have similar interests. There's also explorations on statement-level access control. We can;t dive in too deep into these, but heads up that there's work done and we need more collaboration from various people. - +* SC: I mentioned some of authn/z things because we have similar interests. There's also explorations on statement-level access control. We can;t dive in too deep into these, but heads up that there's work done and we need more collaboration from various people. + ### Notifications @@ -161,8 +161,8 @@ Proposed by [Sarven Capadisli](https://csarven.ca/#i). * TC: [Webmention](https://webmention.net/) * SC: There's interest in general notion of notifications in both groups. Other work that we have, Solid Notifications Protocol, Webmention also one of the core specs out of SocialWeb. Not sure if there's new activity around notifications in SW CG, but work on AS and AP is still ongoing... * DZ: We should talk about next steps. -* TC: I agree. We have a great set of people, but want to point out we don't have everyone from every community and that's okay. Some folks are really passionate about getting details right. Creating a separate task force / ongoing meetings to discuss areas of overlap would be really positive. -* SC: This was an "intro" meeting so good idea to continue. Solid CG has a slot (2-hours) for special topics where we dive into topics. Happy to have something like that. Pick a topic and have everybody join. There's related topics about chartering. Solid is interested in WG and considerations in Social to continue under a WG. Maybe we can hash out some understandings as to what makes sense i na WG charter given our shared interest in "social" problems. +* TC: I agree. We have a great set of people, but want to point out we don't have everyone from every community and that's okay. Some folks are really passionate about getting details right. Creating a separate task force / ongoing meetings to discuss areas of overlap would be really positive. +* SC: This was an "intro" meeting so good idea to continue. Solid CG has a slot (2-hours) for special topics where we dive into topics. Happy to have something like that. Pick a topic and have everybody join. There's related topics about chartering. Solid is interested in WG and considerations in Social to continue under a WG. Maybe we can hash out some understandings as to what makes sense i na WG charter given our shared interest in "social" problems. * SC: Let's continue the discussion on having task force / special meetings. ### Charters @@ -184,7 +184,7 @@ Proposed by Emelia Smith; Talking about approaches to moderation for Fediverse s * BW: We need to distinguish between speech which is legal and which is illegal. There is a tremendous amount of moderation focused on legal speech. Those subject should be considered separately. Relying on moderators might require diverse choice of providers user can pick from. There is also problem of transparency of moderation rules. * ES: There was a large Youtube producer who signed up for Mastodon. They had problem with posts they were seeing there. People replied that you have block button available. They replied that they don't want to use it based on their values. There are cases where platform operators need to leave some moderation up to the users. * ES: ... case of misleading report which lead to someone's account being blocked. -* SC: We could capture it as use cases. +* SC: We could capture it as use cases. * https://github.com/swicg/general/issues/30 * https://github.com/solid/user-stories * https://solid.github.io/authorization-panel/authorization-ucr/ diff --git a/meetings/2023-12-06.md b/meetings/2023-12-06.md index 50c7c21f..0c9380f1 100644 --- a/meetings/2023-12-06.md +++ b/meetings/2023-12-06.md @@ -14,7 +14,7 @@ * [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me) * Maxime Lecoq * [Michiel de Jong](https://michielbdejong.com) -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * Hadrian Zbarcea --- @@ -40,7 +40,7 @@ ### Introductions -* +* --- @@ -148,6 +148,7 @@ URL: https://github.com/solid/authorization-panel/issues/194 (Universal Access M ``` BASE_URL=https://example.com/folder/ ADDRESSBOOK= {BASE_URL}subfolder/addressbook.ttl - ``` -* ... I don't think RDF supports this though. + ``` +
+* ... I don't think RDF supports this though. * MdJ: (from chat) You could also look at [Pod Migrator](https://dapsi.ngi.eu/success-story-pds-pod-migrator-migrating-your-solid-data/) which was a DAPSI-funded project by the PDS Interop team. It's about moving a whole pod, but might also be useful for moving just one file or folder around. diff --git a/meetings/2024-02-07.md b/meetings/2024-02-07.md index db7387e0..81b2fb25 100644 --- a/meetings/2024-02-07.md +++ b/meetings/2024-02-07.md @@ -10,7 +10,7 @@ ## Present * [elf Pavlik](https://elf-pavlik.hackers4peace.net) -* [Thhck](https://github.com/thhck) +* [Theo](https://github.com/thhck) * Grace Elcock (Guest) * Hadrian Zbarcea * Aaron Coburn @@ -53,10 +53,10 @@ * eP: is there a link? * HZ: not yet, should be available tomorrow. -### fedcm demo +### fedcm demo * Th: I have few slideds. -* Th: Similar to the article +* Th: Similar to the article https://www.liquid.surf/2024/2/7/Can-FedCM-improve-Solid-login-flow#what-is-fedcm * Th: New draft spec for web browser, started by Google and developed in [Federated Identity CG](https://github.com/fedidcg/). Comparing with and without FedCM. The goal is to have the browser as the middlware. Web browser pops window for user to select IdP; all the flow happens in the background. * Th: showing live demo... @@ -68,15 +68,15 @@ * Th: We are discussing use of trusted providers, so you can trust all the IdPs from the list of providers. * SB: I understand some kind of bootstrap step. Can you point me to more resources to read up about all the trust and identity issues. * Th: There is one github issue. ( link ??? ) -* AC: To a certain degree, FedCM is not trying to address the trust issue head-on. For what you are describing, you might take a look at OIDC Federation. This lets you get around the large *allow* lists. +* AC: To a certain degree, FedCM is not trying to address the trust issue head-on. For what you are describing, you might take a look at OIDC Federation. This lets you get around the large *allow* lists. * AC: In the flow that you have showed, it looked like authorization code flow. The site needs to re-run through the same flow when session expires. Is the flow different when you want to refresh expiry token? * Th: RP can do it directly without the browser refreshing. * AC: The use of cookies throws everyone off. Is use of cookies part of FedCM or is it orthogonal? Does 3rd party cookie go away? Is the IdP cookie only going to be available when there is a redirect from the same domain? * SB: Is it happening as redirect or is the browser acting as the broker? * Th: The browser acts as the broker. -* Th: FedCM can be a good improvement for Solid and Fediverse. +* Th: FedCM can be a good improvement for Solid and Fediverse. * HZ: How about non browser apps. -* Th: When you do it with OIDC you still get browser view to redirect. +* Th: When you do it with OIDC you still get browser view to redirect. * HZ: It is for the case when you have GUI, for the script you usually get tokens ... * Th: It is focus on the web browser. * AC: OIDC *is* browser-based login, client_credentials is not OIDC. @@ -111,10 +111,10 @@ URL: https://github.com/solid/specification/pull/598 * eP: If we cannot agree on a solution, we should at least agree on, and document, the problem. Security issues should be higher priority. * eP: PROPOSAL: create one place to track security issues, attack vectors. * HZ: the trade off is how many documents are there - +
ACTION: eP to make PR with security threat use cases and capture one discussed in the PR -* AC: OAuth has a "Security Best Practices" document. Perhaps we could do something similar +* AC: OAuth has a "Security Best Practices" document. Perhaps we could do something similar ### Clarify requests with N3 document in server-representation-turtle-jsonld URL: https://github.com/solid/specification/pull/608 @@ -140,7 +140,7 @@ URL: https://github.com/solid/specification/issues/227 * eP: also https://github.com/solid/specification/issues/525 * AC: The biggest issue is that we are going around in circles. I recall Tim weighing in. We need some clear direction. -* HZ: This brings a question on the process. I know that people are reluctant to vote one way or another. +* HZ: This brings a question on the process. I know that people are reluctant to vote one way or another. * eP: Proposal to document the status and close it with no-change, leaving the decision to the WG. * HZ: I think this may apply to the server description. @@ -160,4 +160,3 @@ URL: https://github.com/solid/specification/issues/610 * Proposed by SC. * SC: Chairs, can you use "status" labels, e.g., "waiting for commenter". * SC: I think this issue can be closed but if there is anything outstanding, it should be broken up into specific questions/issues to follow up. I'd like to hear from ML on what needs further clarification or request... - diff --git a/meetings/2024-02-21.md b/meetings/2024-02-21.md index 2931d4b8..9b21cc95 100644 --- a/meetings/2024-02-21.md +++ b/meetings/2024-02-21.md @@ -15,7 +15,7 @@ * Hadrian Zbarcea * Ted Thibodeau * Grace Elcock -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) --- @@ -91,7 +91,7 @@ URL: https://github.com/solid/specification/issues/610 * VB: From last week: > PROPOSAL: attach label and ping Maxime to resolve it * VB: Update? -* SC: There's plenty of feedback. I initially suggested to label this and have Maxime respond. AFAIK the questions were addressed. There's no more to do on that issue unless there's more information coming up. We can leave it there until Maxime responds. This does not require any change in the spec unless Maxime (or others) consider the response is not adequate. +* SC: There's plenty of feedback. I initially suggested to label this and have Maxime respond. AFAIK the questions were addressed. There's no more to do on that issue unless there's more information coming up. We can leave it there until Maxime responds. This does not require any change in the spec unless Maxime (or others) consider the response is not adequate. * eP: I'd suggest to close issue and reopen if need to. * TT: Concerned by the title of the issue... Perhaps it should've been changed? I haven't seen a suggestion where a Solid served document should only contain a single subject. The issue in and itself seems confused about how the RDF world works, including the misunderstandings in the definitions in the initial comment. By all means, be gentle, but I think, close with no action. * SC: Also lean towards closing it. Nudge Maxime to make it more specific. Agree there were a bunch of things that were misunderstood, makes new definitions as opposed to reusing existing. @@ -105,18 +105,18 @@ URL: https://github.com/solid/specification/issues/565 * eP: HTTP spec only has SHOULD and SP elevates to MUST. Discussion was about awkward terminology in the HTTP spec. * SC: Need to jog my memory / revisit issue. What's the question? * RG: Since `HEAD` is low resource intensive call, Wouter's argument is that you don't need to include `Content-Type`. -* VB: Let's revisit this next week. +* VB: Let's revisit this next week. * TT: What headers can `HEAD` omit? My understanding was same as `GET` without body. * AC: My understanding in RFC 9110, generally yes, but there are few headers like `Content-Length` being one where a few can be omitted. I think `Content-Type` is one of those that can be omitted. * RG: From [9110](https://www.rfc-editor.org/rfc/rfc9110#section-9.3.2): - > The server SHOULD send the same header fields in response to a `HEAD` request as it would have sent if the request method had been `GET`. However, a server MAY omit header fields for which a value is determined only while generating the content. For example, some servers buffer a dynamic response to `GET` until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to `GET` might contain `Content-Length` and `Vary` fields, for example, that are not generated within a `HEAD` response. These minor inconsistencies are considered preferable to generating and discarding the content for a `HEAD` request, since `HEAD` is usually requested for the sake of efficiency. + > The server SHOULD send the same header fields in response to a `HEAD` request as it would have sent if the request method had been `GET`. However, a server MAY omit header fields for which a value is determined only while generating the content. For example, some servers buffer a dynamic response to `GET` until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to `GET` might contain `Content-Length` and `Vary` fields, for example, that are not generated within a `HEAD` response. These minor inconsistencies are considered preferable to generating and discarding the content for a `HEAD` request, since `HEAD` is usually requested for the sake of efficiency. * SC: Determining resource type like multimedia, RDF source, or something else. If a server does not do that, client needs to do a `GET`. Do we want to force clients to do that? I would lean towards making sure the server can generate `Content-Type` for `HEAD`. Lowers total number of requests. * AC: +1 (we want to encourage the use of `HEAD`). * eP: Agree, for example when an application wants to display different icons. If resource is created in ways other than Solid Protocol. * SC: This could be a best practice: server should always know what it is serving. -* eP: In practise, if I run CSS and drop a binary file, I can still request it over HTTP but Solid server wouldn't know, -* SC: I don't know if that's a good practice / what that can do to an application. -* eP: Would you require server does not serve resources it does not the content type of? +* eP: In practise, if I run CSS and drop a binary file, I can still request it over HTTP but Solid server wouldn't know, +* SC: I don't know if that's a good practice / what that can do to an application. +* eP: Would you require server does not serve resources it does not the content type of? * SC: Protocol doesn't explain the use case you mention because it is technically out of scope. At least - there is an issue comment on this - server should know what it is serving, and not serve something by accident. diff --git a/meetings/2024-03-06.md b/meetings/2024-03-06.md index 14955d1c..709a3182 100644 --- a/meetings/2024-03-06.md +++ b/meetings/2024-03-06.md @@ -13,7 +13,7 @@ * Sarven Capadisli * [Pierre-Antoine Champin](https://champin.net/#pa) * [elf Pavlik](https://elf-pavlik.hackers4peace.net) -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * [Matthias Evering](https://solidweb.me/testpro/) * Alain Bourgeois * Tim Berners-Lee @@ -72,7 +72,7 @@ URL: https://github.com/solid/specification/discussions/618 * RG: The branding can be an asset or liability. Everyone knows there is something going on with Solid. Losing that could be a problem but everyone has a different idea on Solid. Compromise idea for the name would be using Solid as a different expansion. Something like "SOcial, LInked, Decentralization" or another play on Solid so keeping the branding but meaning is something more. * TBL: Maybe this Group can standardise different htings. Solid is an internet protocol. What bits go across the internet. Like CalDAV, IMAP - if I write a combination of different semantics. Philosophically very important to the WG because they'l be conscience of that. SC understood ??? what ???. The Solid Protocol deliverable has a lot of value and use by different apps. The Mission defines the internet. * HZ: Was at Data Transfer Initiative. Talking about portability. Aware of Solid but wondering why work out there at W3C. IMO -* PAC: Thanks all for sharing thoughts. Others have said before re branding, and liability. I like what eP said what the Group will do. Perhaps that's also how we present. To say that initiatives such as Solid. Which is differen tthan we are goin gto make Solid a rec. I expect than for Solid to be a thing. Then telling W3C Members we are not +* PAC: Thanks all for sharing thoughts. Others have said before re branding, and liability. I like what eP said what the Group will do. Perhaps that's also how we present. To say that initiatives such as Solid. Which is differen tthan we are goin gto make Solid a rec. I expect than for Solid to be a thing. Then telling W3C Members we are not * SC: Social Web had understanding about what Social meant. Controlling own data / Personal / Protected also brings some meaning, several initiatives touch area of people controling their own data. This is not a recent topic. If the group is focusing on personal compared to social, ..., the specs we come up with here are just scratching the surface when it comes to fixing the web. We need other gruops to also bring their expetise. * eP: Good to stay close to Linked Data Platform. Not sure if we should make it more prominent. At least point it to the paragraph in the Solid Protocol spec. What's missing or helpful towards LDP. * RG: Minor nit: Difference on protocols. Solid is working with any data not just personal. I think that needs to be emphasised as well. Not just contacts etc. @@ -92,8 +92,8 @@ URL: https://github.com/orgs/solid/projects/16/views/1 * RG: Only audio. * eP: I guess we're not updating the CG calendar? Perhaps synchronise the board. * HZ: The meetings are in the Solid Calendar -* TBL: There is a [Discussion 555](https://github.com/solid/specification/discussions/555) which is where last discussions were mentioned. -* SC: We moved it to [a project board](https://github.com/orgs/solid/projects/16). The discussion is now closed and chairs are maintaining the board. As far as the calendar, CG and STM have fixed slots. I used to update specific meetings to point to hackmd and the agenda. Right now the agenda is only mentioned in matrix chat; we could improve how we get the details out. +* TBL: There is a [Discussion 555](https://github.com/solid/specification/discussions/555) which is where last discussions were mentioned. +* SC: We moved it to [a project board](https://github.com/orgs/solid/projects/16). The discussion is now closed and chairs are maintaining the board. As far as the calendar, CG and STM have fixed slots. I used to update specific meetings to point to hackmd and the agenda. Right now the agenda is only mentioned in matrix chat; we could improve how we get the details out. ### Release 0.11.0 Milestone issues URL: https://github.com/solid/specification/milestone/7 @@ -139,4 +139,3 @@ URL: https://www.inrupt.com/blog/podbrowser-sunset ### Meeting recording and publication URL: https://github.com/w3c-cg/solid/issues/18 - diff --git a/meetings/2024-04-10.md b/meetings/2024-04-10.md index 16bcec45..b297b05a 100644 --- a/meetings/2024-04-10.md +++ b/meetings/2024-04-10.md @@ -9,7 +9,7 @@ ## Present * Hadrian Zbarcea -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * Maxime Lecoq-Gaillard * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) @@ -124,4 +124,3 @@ ACTION: HZ to add STM for how we work with use cases & requirements, and evaluat ### Proposal for integrating DIDs into Solid URL: https://github.com/solid/specification/issues/629 - diff --git a/meetings/2024-04-24.md b/meetings/2024-04-24.md index 0fe1587a..586552f1 100644 --- a/meetings/2024-04-24.md +++ b/meetings/2024-04-24.md @@ -16,7 +16,7 @@ * [Rahul Gupta](https://cxres.pages.dev/profile#i) * Damon * John Kirkwood -* Jesse +* [Jesse Wright](https://www.jeswr.org/#me) (jeswr) ## Announcements @@ -58,8 +58,8 @@ URL: https://github.com/orgs/solid/projects/16/views/1 URL: https://events.vito.be/sosy2024/ * SC: I suspect some will attend and others will be traveling, etc. I won't make it to the CG call next week (2024-05-01). Not sure about others. - - + + ### Updating WDs URL: https://solidproject.org/TR/ @@ -68,17 +68,17 @@ URL: https://solidproject.org/TR/ * VB: Let's revisit what needs to be done. * SC: eP, let's doublecheck if the changes to the JSON-LD context introduced in the Notifications Protocol ED are already reflected in https://www.w3.org/ns/solid/notifications-context/v1 or if we need to follow-up, PR at solid/vocab. We/I can do it. Just would like to verify. We can do this asynch. * SC: We made some updates to the JSON-LD context. We can also release 0.3 but we need to check. -* eP: Main problem is invalid URL for JSON-LD context. We can make a bug fix release because it is confusing. Go with bug fix release. -* SC: We don't want people to implement current WD; we made a number of changes affecting the implementations. -* eP: Don't remember many changes... If there are not many I can ???. If it's mostly JSON-LD context, can we make a bugfix release? -* SC: can you do that quick diff to see? -* eP: we will continue on the chat. +* eP: Main problem is invalid URL for JSON-LD context. We can make a bug fix release because it is confusing. Go with bug fix release. +* SC: We don't want people to implement current WD; we made a number of changes affecting the implementations. +* eP: Don't remember many changes... If there are not many I can ???. If it's mostly JSON-LD context, can we make a bugfix release? +* SC: can you do that quick diff to see? +* eP: we will continue on the chat. ACTION: eP: to share a link with a diff between WD and ED ### WIP Implementation Feedback -* VB: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome. +* VB: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome. #### Tentative, preliminary, pragmatic plans for a public CSS instance * VB: proposed by ME @@ -92,28 +92,28 @@ brainstorming, things to consider..., monetization ### WG Charter -#### Please upvote and downvote proposed WG names +#### Please upvote and downvote proposed WG names URL: https://github.com/solid/solid-wg-charter/issues/75 * VB: Discussion at https://github.com/solid/solid-wg-charter/issues/73 * VB: We agreed to decide on final name today. -* SC: I've made minor updates to PAC's code (): , e.g., shows voters. Feel free to update yours with this. I don't plan to keep my version on my site long. We could consider moving it over to Solid ecosystem monitor (ping @VirginiaBalseiro) to be used for any issue / poll / reactions stuff. +* SC: I've made minor updates to PAC's code (): , e.g., shows voters. Feel free to update yours with this. I don't plan to keep my version on my site long. We could consider moving it over to Solid ecosystem monitor (ping @VirginiaBalseiro) to be used for any issue / poll / reactions stuff. * SC: One thing to mind / pass on to PAC (Pierre-Antoine Champin) / W3C Team here is that majority of the the names and voters are from the Solid community. The names may be leaning with Solid-perspective, but not necessarily ideal for the WG in and of itself, that's intended to at least not come across as Solid-centric. There is no perfect name, and it'll mean different things to everyone. For example, "Linked Web Storage WG" may be quite meaningful to SW/LD/Solid folks, but perhaps not great for anyone outside that view β€” some may even dislike the whole "Linked" Stuff. Similarly "Decentralised Online Storage" could be well-rounded for a lot of people but "decentralised" can also mean different things to everyone. And, for some continuity with "Solid", I can see that being reused with a new acronym β€” but that might also add more confusion. Just wanted to raise these types of considerations towards the final naming that the wider W3C community can consider. * PAC: I agree with above, _Linked Web Storage_ is the most upvoted and least controversial name. I share some concerns about _Linked_. Nothing in the charter mentions linked data; currently it is not core to the charter. Some people may have reactions. That being said I don't want to impose a single view. The github issue is a good reference for the future. * PAC: I sent the current version of the charter, didn't get any feedback yet. I got a confirmation from the 3rd chair, Eric Prud'hommeaux who has more exprience previously working at W3C. -* eP: Glad to hear Eric will be involved especially because we want to rely heavily on shapes. +* eP: Glad to hear Eric will be involved especially because we want to rely heavily on shapes. ### Proposal for integrating DIDs into Solid URL: https://github.com/solid/specification/issues/629 * VB: Pinged Damon to see if he can attend a call and discuss. * VB: This is a duplicate of a previous issue, we can discuss it when we get damon and others involved. -* HZ: I'm netural and just wanted to clear some outstanding issues. My position is that Solid should accept anything that follows some characteristics. Solid should be future proof. -* PAC: At W3C, I'm a team contact of DID group, but took that role after the spec was published. On one hand, I feel responsible to be consistent across the W3C groups. I think it makes sense to consider that, DID documents share a lot of features with WebID documents. When you look at the history of WebID, there was the FOAF profile. Later, Henry Story proposed to use it to prove the identity. Its first purpose was to prove and verify that control. It makes sense to see how those things converge. People in DID community think one should put as little as possible in the DID document. This contrasts many tendencies in WebID and FOAF to be very descriptive. -* HZ: I would like to see something concrete. Someone could come up with a proposal. I would not expect all the DID methods to be applicable. +* HZ: I'm netural and just wanted to clear some outstanding issues. My position is that Solid should accept anything that follows some characteristics. Solid should be future proof. +* PAC: At W3C, I'm a team contact of DID group, but took that role after the spec was published. On one hand, I feel responsible to be consistent across the W3C groups. I think it makes sense to consider that, DID documents share a lot of features with WebID documents. When you look at the history of WebID, there was the FOAF profile. Later, Henry Story proposed to use it to prove the identity. Its first purpose was to prove and verify that control. It makes sense to see how those things converge. People in DID community think one should put as little as possible in the DID document. This contrasts many tendencies in WebID and FOAF to be very descriptive. +* HZ: I would like to see something concrete. Someone could come up with a proposal. I would not expect all the DID methods to be applicable. * VB: https://github.com/solid/specification/issues/217 is a proposal, we could pick up from there. -* HZ: There were many changes in DID since there. -* eP: Who considers themselves expert in DID? Dmitri would be a good person to invite. Jackson Morgan. We should try a STM to get the people who consider themselves experts and discuss with them. +* HZ: There were many changes in DID since there. +* eP: Who considers themselves expert in DID? Dmitri would be a good person to invite. Jackson Morgan. We should try a STM to get the people who consider themselves experts and discuss with them. * VB: We can ask on the mailing list and take it from there. * SC: While there are various individuals working on both, I think it's on them to make the case. We have limited bandwidth to dedicate to features. This is the incubation space; we shouldn't wait for the working group and try to bring it directly there, out of thin air. We can make a call, invite people to make a PR, whether like they want to change WebID to DID, or propose new method, or whatever. * eP: Would like to emphasize designing solid in a way tht is future-proof. wWe can do our best to make it easier to introduce in the future. We want to avoid breaking changes in the future. @@ -122,14 +122,14 @@ URL: https://github.com/solid/specification/issues/629 * SC: That's [architecture astronomy](https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/). We can't abstract everything just in case. * HZ: The issue was brought to the CG. There are two issue, second marked as a duplicate. We should close those issues one way or another. No one rejects the idea, maybe next step would be STM making sure we invite the people with interest and expertise to that meeting. -ACTION: HZ to post to mailing lists, Solid and DID, inviting people to comment on the topic of DID. +ACTION: HZ to post to mailing lists, Solid and DID, inviting people to comment on the topic of DID. ### WG Chairs * SC: I understand that Eric brings a lot of experience. Last I knew, he is affiliated with Janeiro Digital. There is one issue, some people with the same affiliation, as well as of another proposed chair with another affiliation, were trying to shortcut process of amending the charter without Solid CG's consensus: . I trust Eric, and I know he knows W3C rules. I wonder if the two original proposed chairs are being changed? Many objections were about those chairs. If the already proposed 2 chairs lack experience, what _do_ they bring to the table? -* PAC: I don't think they bring anything that could not be offered by other possible chairs. The objections raised by a number of AC reviewers, part of them were about W3C experience; adding Eric addresses that. Eric's association with Janeiro ended before the events you mention. I'm not sure but it might be not fair to have it weigh on him. I believe that the two proposed chairs bring different perspectives to the table. One is working in the private company that is implementing Solid servers, the other one working in the public sector. Eric has his own perspective working on the shapes, for example. I don't think concerns that were raised were sufficient to change the agreement with two proposed chairs. I think that adding Eric addresses the most justified objection. +* PAC: I don't think they bring anything that could not be offered by other possible chairs. The objections raised by a number of AC reviewers, part of them were about W3C experience; adding Eric addresses that. Eric's association with Janeiro ended before the events you mention. I'm not sure but it might be not fair to have it weigh on him. I believe that the two proposed chairs bring different perspectives to the table. One is working in the private company that is implementing Solid servers, the other one working in the public sector. Eric has his own perspective working on the shapes, for example. I don't think concerns that were raised were sufficient to change the agreement with two proposed chairs. I think that adding Eric addresses the most justified objection. * eP: Having the opportunity to work in the context of WG with those three chairs, I fully support; they have experience and understand the technology. I also have good experience of working with them in CG context. * SC: I see a record that some of the players were not following the rules when writing the charter. We can look at people's past behavior to see how they will act in the future. We can also look at the meetings' history to see when they were participating last time. Eric hasn't participated for a long time. For me, it is about the criteria. I put up a list of questions that chairs could ask themselves. Were they fighting for the CG or standing with their affiliations' agendas? There is work at W3C looking at transparency in chair selection process, e.g., some links at . * PAC: I see what you are saying with regards to participation in the group. There are only a few of us on the weekly CG calls. As much as I would like for the whole community to be well-represented during those calls. I'm trying, and it is hard; it doesn't seem to be the case for the whole community to be fully representing the larger community. We had to take this. -* eP: I think CG is unproductive. I don't blame people for not participating. For many people, it feels like an energy drain and like they move Solid forward by not participating. UX/DX meetings, hackathons are more productive. Solid Symposium has presentations that were never presented in the CG. CG should have a retrospective as to why it is discouraging for people to participate. If it's running against the wind. Not just last few weeks, but last few years. Too much effort to fight. +* eP: I think CG is unproductive. I don't blame people for not participating. For many people, it feels like an energy drain and like they move Solid forward by not participating. UX/DX meetings, hackathons are more productive. Solid Symposium has presentations that were never presented in the CG. CG should have a retrospective as to why it is discouraging for people to participate. If it's running against the wind. Not just last few weeks, but last few years. Too much effort to fight. * SC: I think we're off on a tangent. The point is whether you want Solid stuff to succeed. The minimum assumption is to see how they worked on making CG to succeed. The ground work, chairing, running after minor and large issues. Things that have to be done for Solid to move ahead. Saying that "I don't see CG being productive so I just let them do their thing" is not useful. For months I've been asking for people's commitments, where they are making the commitment to implement or not implement something. If you are running on the Solid brand show me ... People who want to chair, how they engaged in favour of their own affiliation, for example Solid Notification. There were a lot of specs like ACP, WebSockets that haven't been touched. I don't believe that Team decisions being made are necessarily objective. I'm not expecting an essay or line-by-line answer. There is a good number of questions in the list I proposed, e.g., . diff --git a/meetings/2024-05-01.md b/meetings/2024-05-01.md index e9f7cfba..d2de2dae 100644 --- a/meetings/2024-05-01.md +++ b/meetings/2024-05-01.md @@ -12,7 +12,7 @@ * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * Aaron Coburn * [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) -* TimBL +* [Tim Berners-Lee](https://timbl.inrupt.net/profile/card#me) ## Announcements @@ -40,7 +40,7 @@ ## Topics ### Special Topic Meetings -URL: https://github.com/orgs/solid/projects/16/views/1 +URL: https://github.com/orgs/solid/projects/16/views/1 * HZ: spoke with Tim about use cases. Many types, including technical and governance related (e.g., migrating pods between providers) * ...: interested in proposing an API for interacting with a Pod provider (e.g., create/delete/list/archive Pods) @@ -97,7 +97,7 @@ ACTION: HZ will create a [HackMD document for use cases](https://hackmd.io/@soli * HZ: a search function * eP: what is the process for getting listed on that page? * HZ: PR via github, but the process gets in the way -* TBL: the Solid process needs to be improved +* TBL: the Solid process needs to be improved ### WG Charter @@ -125,5 +125,3 @@ ACTION: HZ will reach out to PA to get a status of the WG charter ACTION: eP will contact the CSS developers to find out when they might be available to discuss ACTION: HZ (or AC) will reach out to Nic - - diff --git a/meetings/2024-05-15.md b/meetings/2024-05-15.md index aecb008f..a19553af 100644 --- a/meetings/2024-05-15.md +++ b/meetings/2024-05-15.md @@ -9,11 +9,11 @@ ## Present * [Michiel de Jong](https://michielbdejong.com) -* [elf Pavlik](https://elf-pavlik.hackers4peace.net) +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) * [Virginia Balseiro](https://virginiabalseiro.com/#me) * Hadrian Zbarcea * Tim Berners-Lee -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) ## Announcements @@ -34,45 +34,45 @@ ### Scribes * Virginia Balseiro - + ### Introductions -* +* --- ## Topics ### WG Status -* VB: Skipped until we have PAC in the call. -* HZ: Is there anything blocking that PAC needs to wait for? -* RG: Drafts included in CG need to be changed to CG-DRAFTs. -* HZ: That is not a blocker. +* VB: Skipped until we have PAC in the call. +* HZ: Is there anything blocking that PAC needs to wait for? +* RG: Drafts included in CG need to be changed to CG-DRAFTs. +* HZ: That is not a blocker. * RG: No but W3C said nice to have.. The blocker has been sorted by Sarven's PR. * HZ: Nothing PAC expects from us? * MdJ: AFAIK, no. ### Strategy for making breaking changes -* VB (last week): Let's pick this up again next week. -* eP: Keep in mind we plan to hand work over to WG. WG has full mandate to make breaking changes. This is just CG findings. What will we do when breaking changes happen? Few approaches/experiences: Websockets, Solid-OIDC. We need a clear strategy and communicate to implementers. -* MdJ: For example, adding SAI to spec would be a breaking change and not too far into the future. -* TBL: Websockets example: any breaking change has a negative impact on the ecosystem. They should be implemented rarely, and when they are ??? need a way to make sure we are backwards-compatible. Working with SAI is very different. -* eP: See with implementers and deployments β€” communication loop to be more aware of actual adoption. Harmful for the ecosystem, but an argument is the ecosystem is slow, so, if need to make breaking changes, now is the best time. Good to have strategy to be able to make breaking changes later; now is a good time to test drive deprecating or sunsetting parts of the protocol. -* MdJ: We already have a mechanism. Introduce the new one, say the insecure one is deprecated. I don't think that's really your question, Pavlik? -* TBL: If there's a breaking change, number before dot should change. So we should use semver >= 1.0. -* MdJ: I think eP's question is not how do we number, how do we sunset. It's more we have all these different implementations, side-by-side. which are not compatible with each other. How do we keep having a single spec even with contradictions? Some people work on WAC, some on ACP, some on SAI, some on Inrupt's access requests, etc. We have different ways of doing policy registries, how can we move to a spec that includes SAI? -* eP: For example, what if slash semantics go away? what's the strategy? Looking at things we'd like to anticipate changes on, how to communicate. -* MdJ: With Websockets we all agreed ??? We cannot say to make a breaking change without excluding ??? -* eP: I think it's a good exercise to say if a breaking change needs to happen, how to approach. -* MdJ: The WG will be very different from CG. WG will need to arrive at one protocol, and CG is an incubator. If someone in the CG still wants to do X (e.g., use slash semantics), I don't think we should deprecate it. +* VB (last week): Let's pick this up again next week. +* eP: Keep in mind we plan to hand work over to WG. WG has full mandate to make breaking changes. This is just CG findings. What will we do when breaking changes happen? Few approaches/experiences: Websockets, Solid-OIDC. We need a clear strategy and communicate to implementers. +* MdJ: For example, adding SAI to spec would be a breaking change and not too far into the future. +* TBL: Websockets example: any breaking change has a negative impact on the ecosystem. They should be implemented rarely, and when they are ??? need a way to make sure we are backwards-compatible. Working with SAI is very different. +* eP: See with implementers and deployments β€” communication loop to be more aware of actual adoption. Harmful for the ecosystem, but an argument is the ecosystem is slow, so, if need to make breaking changes, now is the best time. Good to have strategy to be able to make breaking changes later; now is a good time to test drive deprecating or sunsetting parts of the protocol. +* MdJ: We already have a mechanism. Introduce the new one, say the insecure one is deprecated. I don't think that's really your question, Pavlik? +* TBL: If there's a breaking change, number before dot should change. So we should use semver >= 1.0. +* MdJ: I think eP's question is not how do we number, how do we sunset. It's more we have all these different implementations, side-by-side. which are not compatible with each other. How do we keep having a single spec even with contradictions? Some people work on WAC, some on ACP, some on SAI, some on Inrupt's access requests, etc. We have different ways of doing policy registries, how can we move to a spec that includes SAI? +* eP: For example, what if slash semantics go away? what's the strategy? Looking at things we'd like to anticipate changes on, how to communicate. +* MdJ: With Websockets we all agreed ??? We cannot say to make a breaking change without excluding ??? +* eP: I think it's a good exercise to say if a breaking change needs to happen, how to approach. +* MdJ: The WG will be very different from CG. WG will need to arrive at one protocol, and CG is an incubator. If someone in the CG still wants to do X (e.g., use slash semantics), I don't think we should deprecate it. * TBL: If people want to deprecate slash semantics, there would be a fork. If you wanted to make a spec that included ??? you'd have different levels of ??? that you can negotiate between client and server. * eP: We should clarify the difference between fork and next version with breaking changes. All specs in CG are CG drafts. More important for WG. WG publishes the actual recommendations. We need to clarify fork, breaking changes, CG drafts, recommendations from WG, etc. Those can have breaking changes, assuming everything would be a fork? We need a clear strategy. * RG: TBL you're breaking up. * MdJ: TBLs and my answer, maybe you have clarification/answer to your question if you add them together. -* eP: We can move on. +* eP: We can move on. * MdJ: To summarize, if the CG were to pick one of five parallel experiments as the next version of Solid, then it'd be up to the experiment to say they're excluded. Because in 2 years, there will be a version published by WG anyway, there's no use trying to converge before that happens. Let's stick with multiple options. -* RG: Can we have the answwer written down so people know what to expect? +* RG: Can we have the answwer written down so people know what to expect? * TBL: Cost of breaking changs to the community is huge. We should not do it. Exercise for this group would be to re-introduce ACP and suppose they wanted a different version of WAC. That could be done in a way that was much more interoperable. WAC 1.0 and 2.0 for example. Look at what ACP spec would look as an extension of WAC. About slash semantics: you don't have to use. ### Add Solid Application Interoperability (SAI) as a mechanism for authorising access to protected resources @@ -88,23 +88,23 @@ URL: https://github.com/solid/specification/issues/650 * eP: I have one access management client, so it wouldn't affect most apps. 99% of clients should implements WAC/ACP. * MdJ: So which Policy Registries would you say the spec should mention? * TBL: I disagree that you should have separate apps for managing access control. When I share stuff on macOS, that is done by the app (for example, photo app). I would worry that, as an app developer, I need control of that ??? to guarantee the integrity of the data. -* VB: +1. -* eP: TBL, is your assumption that an app developer will require the user to let the app edit the access policies to use the app? +* VB: +1. +* eP: TBL, is your assumption that an app developer will require the user to let the app edit the access policies to use the app? * TBL: When you set up something (meeting, access ??? tracker) app gets ability to set access control on ??? When app has resposibility for one folder, it works well. They don't have to have control access to rest of pod. * MdJ: We have people who want both. We should allow people; they're both valid use cases. Whether there's an authorization agent or apps edit directly, should we mention just one policy registry (WAC, would be overruled by WG)? Should we have the two we have now and ignore eP's work on it and Inrupt's work on access grants? OIDC spec already mentions UMA. Lots of separate efforts happening in the community. Do we want to update the spec to acknowledge all the things? -* eP: I dont think SAI should be included for personal/sentimental reaons. ACP/WAC don't meet certain requirements. +* eP: I dont think SAI should be included for personal/sentimental reaons. ACP/WAC don't meet certain requirements. * VB: I will post my thoughts on the issue; this is a big change. Introduction of ACP already created many issues for front end developers. We should actively involve Practitioners in this discussion. -* MdJ: Can we agree as the CG that this is a missing part of functionality? There are currently 6 different ways that are being explored. +* MdJ: Can we agree as the CG that this is a missing part of functionality? There are currently 6 different ways that are being explored. * TBL: No, we shouldn't say that there are 6 different ways of doing something. The only thing that actually works is WAC. There was a push to move the community to ACP but ??? we don't see a way to have ??? Implementers have to choose ACP/WAC, and clients have to implement both. This is not "the cat is in the bag". We have kittens. But there's only one cat. SAI has ??? lots of issues with SAI. I can see SolidOS moving from WAC to ACP or WAC to WAC 2.0... * eP: If we have UCRs and proposals that meet them, we can say expected behavior are met in this way. When we say WAC works, I haven't seen how the requirement I mentioned is met. -* RG: We need to get ??? we need an STM. +* RG: We need to get ??? we need an STM. * VB: More implementation feedback would be useful, so that we have more insight into potential issues, security concerns, and so on, that we should be aware of before requiring it in the spec. -* eP: It'd be useful to have UCR so that they can select the work that addresses their requirements. +* eP: It'd be useful to have UCR so that they can select the work that addresses their requirements. * TBL: Useful to have different use cases. Before we go down into lots of micro use cases, we focus on high level use cases. -* VB: +1. +* VB: +1. * MdJ: We already gave SAI more visibility through hackathon. At CG level, we could inform of use cases and present SAI. So people know where to find it, keep protocol as it is, make sure people know where SAI is. * eP: It's not about SAI. Do you clearly describe references between the 6 different approaches you have mentioned? Would be good to have a way to find a way to evaluate all of them. -* RG: Having some discussion (STM) to bring us closer, even if not to a conclusion. So much info that needs to be digested. +* RG: Having some discussion (STM) to bring us closer, even if not to a conclusion. So much info that needs to be digested. ### CG-DRAFTs PRs * VB: Please review: https://github.com/solid/specification/pull/651 and https://github.com/solid/specification/pull/652 @@ -119,7 +119,7 @@ URL: https://virginiabalseiro.github.io/solid-ecosystem-monitor/ * eP: I started a simple prototoype which I would like to use to track my participation: https://github.com/janeirodigital/sai-js/tree/main/examples/plenary#readme * eP: In short, minutes are managed as an external attachment, meeting description links to them, all the rest can be managed based on shapes, shapetrees, etc. * eP: An interesting case for role-based permissions! For example, chair can make more changes than a regular CG participant. -* VB: Postponed to next week. +* VB: Postponed to next week. ### User Profile and Contacts @@ -130,4 +130,4 @@ URL: https://github.com/solid/contacts * https://www.w3.org/TR/contact-picker/#contact-property * https://github.com/fedidcg/FedCM/issues/559#issuecomment-2057657128 > Beyond name/email/picture which is currently supported, some of the most commonly asked extensions are allowing RPs to request the user's phone number (as opposed to email addresses) or the user's language preferences. It is not clear where we could go from there, but we expect a subset of the OIDC's Standard Claims or HTML's autocomplete to be things that the browser could potentially mediate in a constructive way (e.g., organization, country, websites). -* VB: Postponed to next week. +* VB: Postponed to next week. diff --git a/meetings/2024-06-05.md b/meetings/2024-06-05.md index 92f9851a..5be4ce0d 100644 --- a/meetings/2024-06-05.md +++ b/meetings/2024-06-05.md @@ -15,9 +15,9 @@ * Hadrian Zbarcea * Gioberto C * Jeff Zucker -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) -* Sungpil Shin +* Sungpil Shin * John Kirkwood * Jesse Wright @@ -50,9 +50,9 @@ ### Solid CG meeting at TPAC -> ACTION: VB to respond to request with earliest time on Tuesday. +> ACTION: VB to respond to request with earliest time on Tuesday. -* VB: Some people have conflicts for Tuesday. Would Monday 23 September: 09:00 - 10:30 PDT (16:00 - 17:30 UTC) work for everyone? +* VB: Some people have conflicts for Tuesday. Would Monday 23 September: 09:00 - 10:30 PDT (16:00 - 17:30 UTC) work for everyone? * VB: Will send out request by Friday. * VB: Probably a hybrid event. * VB: If no objections, will submit request for 2024-09-23T16:00:00Z with estimate of 25 people attending. @@ -84,46 +84,46 @@ URL: https://github.com/solid/specification/blob/main/meetings/2024-05-29.md#sol ### Please review CG Report requirements URL: https://github.com/solid/specification/issues/587 -* SC: There's an issue Ian created. In the context of W3C CG, W3C has only one way of communicating these reports. They're called CG-DRAFT / CG-FINAL. +* SC: There's an issue Ian created. In the context of W3C CG, W3C has only one way of communicating these reports. They're called CG-DRAFT / CG-FINAL. * SC: https://www.w3.org/standards/types/#reports -* SC: Table has types of documents for different groups, etc. CG can only publish CG-DRAFT. Not clear at W3C (not just about Solid), groups use different tools and sometimes use Editor's Draft, Unofficial Draft, etc., based on tool configs. Part of the confusion as to why we have different documents like ED. Raised it to W3C Team, asking for clarification on what we're allowed to use. Somewhat clear that we cannot use ED, because ED belongs to certain types of groups called "W3C Group", which does not include "W3C Community Groups". Asked for clarification in [the issue](https://github.com/w3c/tr-pages/issues/102) and created PR, they will have to follow up. +* SC: Table has types of documents for different groups, etc. CG can only publish CG-DRAFT. Not clear at W3C (not just about Solid), groups use different tools and sometimes use Editor's Draft, Unofficial Draft, etc., based on tool configs. Part of the confusion as to why we have different documents like ED. Raised it to W3C Team, asking for clarification on what we're allowed to use. Somewhat clear that we cannot use ED, because ED belongs to certain types of groups called "W3C Group", which does not include "W3C Community Groups". Asked for clarification in [the issue](https://github.com/w3c/tr-pages/issues/102) and created PR, they will have to follow up. * SC: We have to either express documents as CG-DRAFT, or we say these documents should not say they are produced by W3C CG. Downplay, remove logo, say it's prepared by the CG. They seem okay with the idea we have a CG-DRAFT, ED pushed out there removes all W3C markings. As long as that's okay, they are happy with that. For all our reports, we need to shift toward CG draft or something not implying CG. Solid QA and WebID Profile in particular only have one version. We don't have one version for CG-DRAFT and one for ED. But Solid Notificatons, Solid Protocol, WAC, have both things: CG-DRAFT and working right now on ED. We need to decide if we need these two other documents (WebID Profile and QA) to also have ED, or commit to CG-DRAFT. * RG: Thanks for raising this. Asked last week. Reading from the definitions why W3C Group excludes CG. Nice that you raised it. Having "W3C" being removed from the CG work seems strange, I do not agree with complete removal of W3C branding. * eP: https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fsolidproject.org%2FTR%2Fprotocol&doc2=https%3A%2F%2Fsolidproject.org%2FED%2Fprotocol . I think this is unnecessary complexity. The way I'd like to work on drafts I'm working on. So everything is CG-DRAFT. Later we can talk about CG-FINAL. The Editor's Draft is informal way of working / referring to the HEAD of the branch. Other than that, it doesn't change anything. We don't cut a release. This one is just the current version and the latest published version is pretty much showing that. I'd just like to use the CG-DRAFT and don't touch the version numbers. * SC: The CG-DRAFT could be anywhere. CG-FINAL would have a copy on w3.org. * eP: Timestamps we could publish on solidproject. * SC: Can you share two different links? Distinguishing between CG-DRAFT and the one pointing at the head of the branch -* eP: Looks the same, just different URLs. +* eP: Looks the same, just different URLs. * SC: That's what we have right now with ED/qa and Solid WebID Profile. Historical reason: TR pages was the only thing out there that was "published" and versioned. * JK: My understanding was that the WG charter that needs potentially approval by the AC to become a WG. -* SC: There's a W3C community and that includes AC as one group that needs to review. The WG would take the Solid protocol as one of the input documents, and other specs. If deliverables change it might need another set of reviews. If the group wants to work on other specs, they can be proposed. In CG we incubate this work and put it out there for WG to continue some parts of the work. There's tst suites, exit criteria.. etc. +* SC: There's a W3C community and that includes AC as one group that needs to review. The WG would take the Solid protocol as one of the input documents, and other specs. If deliverables change it might need another set of reviews. If the group wants to work on other specs, they can be proposed. In CG we incubate this work and put it out there for WG to continue some parts of the work. There's tst suites, exit criteria.. etc. * JZ: Want some clarity on the two drafts situation. If I understand eP, there'd be an HTML version of the CG-DRAFT. That wouldn't gt PRs. PRs would go to the head of the branch. And that this would be ready to push up to WG. Is that what you're proposing? * eP: No, everything is worked under CG. The current main branch on a repo is the CG-DRAFT. Every now and then we have a tag release. Everything is being worked on as CG work and auto-versioning. * JZ: I'm asking how many versions there are going to be and which would get a PR. If I want to change the WebID Profile, there is one document, and submit a PR if accepted it gets changed. This is now ready to become as labelled as CG-DRAFT, it'd then automatically generated? -* eP: Workflow is the same. We make PRs against main branch of the repo. I'd like to use same boilerplate for both. +* eP: Workflow is the same. We make PRs against main branch of the repo. I'd like to use same boilerplate for both. * RG: To eP's suggestion, my understanding from the definitions is that ED has a label, and it may not involve everyone's agreement. Is that after the process. Are we good to release as a versioned thing? Therefore that distinction makes sense to me. * SC: W3C ED is not for CGs. We should not say it's a W3C ED. We can of course call it an ED in ED/ .. but ED should not use the graphics, labels etc. saying it's a W3C things. -* SC: We canot have a document saying it's a CG report and ??? how many times it gets published is not important. We can do what eP says and keep updating. As long as we have consensus. In contributingguidelines there's a section about decisions. Leans on W3C process around what kind of correction class is being made. Some things are editorial changes, some are subtantial changes. There are guidelines for each category: use best judgement for editorial, for substantial must make a PR and regular process like getting approval, etc. I wouldn't worry too much about things getting through PR and updated. We don't need a special ceremony to ake a new release. W3C does not expect it. If you make a PR in Solid WebID profile and we agree to merge, just update version number in the PR and that's enough. -* JZ: In both version? GH and action would change CG-DRAFT? +* SC: We canot have a document saying it's a CG report and ??? how many times it gets published is not important. We can do what eP says and keep updating. As long as we have consensus. In contributingguidelines there's a section about decisions. Leans on W3C process around what kind of correction class is being made. Some things are editorial changes, some are subtantial changes. There are guidelines for each category: use best judgement for editorial, for substantial must make a PR and regular process like getting approval, etc. I wouldn't worry too much about things getting through PR and updated. We don't need a special ceremony to ake a new release. W3C does not expect it. If you make a PR in Solid WebID profile and we agree to merge, just update version number in the PR and that's enough. +* JZ: In both version? GH and action would change CG-DRAFT? * SC: Yes. -* eP: My suggestion is to completely avoid ED terminology. +* eP: My suggestion is to completely avoid ED terminology. * SC: That can work, but we have snapshots so we can refer to them. What you describe is a latest living standard and it's versioned but there wouldn't be a clear way for any impleentation to refer to the published document. -* eP: We should make a tagged release which are snapshots. +* eP: We should make a tagged release which are snapshots. * SC: Separate HTML document? -* eP: Yes, separate URL, timestamped, etc. +* eP: Yes, separate URL, timestamped, etc. * TT: Historically speaking ED exists because editor take suggestions for changes and produces a document for review. Not through PRs. Right now even though things are called ED, we have PRs and similar. When as a group we decide, this is a line in the sand and we don't want to go back, and want to refer to this version, then we say "make a timestamped copy in w3c archives". We can still do whatever we want in the github world, that's fine. Often we go in the wrong direction and have to turn back β€” that's normal. Either we are a W3C CG or we are not. It is okay to decide not to be, but that should be the question. Not timestamps, etc., as the discussion. Everyone should review the existing W3C processes. If that's going to break something that we want to do, raise such breakages as concerns. * VB: I think we are not trying to redefine and looking for W3C guidance. * JZ: I think we need some clarification. -* VB: Let's postpone this to next week. +* VB: Let's postpone this to next week. ### i18n (internationalization) and n11n (normalization) of resource identifiers URL: https://github.com/solid/specification/pull/575 * VB: We still need implementation feedback. We said we'd wait for WT and SC on this in the past. We can actively ask for implementation feedback as a way to move this forward. * eP: AFAIK, WT is working on it but not participating in the CG. -* SC: We need implementation feedback. Who really needs the feature, should give feedback. If others want it, it needs to be shown to be working and not breaking things. I haven't seen anything on records on any server of this being implemented of commitment to implement. Nor from applications. This is of interest, but we don't want to throw random stuff. -* eP: Do we have a test in test suite that this PR would affect / change tests or add tests? -* SC: Good question. Had to do with who wants to look into those tests. Some people are aware of the implications. +* SC: We need implementation feedback. Who really needs the feature, should give feedback. If others want it, it needs to be shown to be working and not breaking things. I haven't seen anything on records on any server of this being implemented of commitment to implement. Nor from applications. This is of interest, but we don't want to throw random stuff. +* eP: Do we have a test in test suite that this PR would affect / change tests or add tests? +* SC: Good question. Had to do with who wants to look into those tests. Some people are aware of the implications. ### STM meeting time change * VB: Any objections to moving the meeting to one hour later? So, Tuesday's at 15:00 UTC. diff --git a/meetings/2024-06-12.md b/meetings/2024-06-12.md index 004f40a7..5f9a7009 100644 --- a/meetings/2024-06-12.md +++ b/meetings/2024-06-12.md @@ -12,10 +12,10 @@ * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * [Matthias Evering](https://solidweb.me/testpro/) * [Pierre-Antoine Champin](https://champin.net/#pa) -* Erich Bremer, Stony Brook University +* Erich Bremer, Stony Brook University * Grace Elcock * Jeff Zucker -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) ## Announcements @@ -53,7 +53,7 @@ ### TPAC Meeting -* VB: Our selected slot was not available so the meeting was moved to [Thursday September 26th at 18:00 UTC](https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024&month=9&day=26&hour=18&min=0&sec=0&p1=783&p2=37) +* VB: Our selected slot was not available so the meeting was moved to [Thursday September 26th at 18:00 UTC](https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024&month=9&day=26&hour=18&min=0&sec=0&p1=783&p2=37) * eP: can we add it to the Solid Calendar * PAC: I think it'll be added automatically @@ -68,12 +68,12 @@ ACTION: PAC to create a doodle. * PAC: do we put all slots, or filter first? * eP: prefer to add all and filter later * PAC: maybe give a deadline. -* VB: (following minutes but cannot join): Our options are limited to what's available. Event will be added automatically to our calendar. Our first option of Monday was not available. Tuesday was not good for some people. Feel free to add all slots and we can ask what's possible but deadline was June 10th to submit, so our choices might no longer be available at this point. Let me know and I'll check. +* VB: (following minutes but cannot join): Our options are limited to what's available. Event will be added automatically to our calendar. Our first option of Monday was not available. Tuesday was not good for some people. Feel free to add all slots and we can ask what's possible but deadline was June 10th to submit, so our choices might no longer be available at this point. Let me know and I'll check. * eP: sharing with the group what VB is writing. * PAC: we're past the deadline anyway * eP: 48 hour should suffice. we cand send list mail and @room mention on matrix (any chair can do it) -* HZ: agreed -* VB: Perhaps focus on Thu and Fri, since we already know Mon and Tue don't work. +* HZ: agreed +* VB: Perhaps focus on Thu and Fri, since we already know Mon and Tue don't work. ### initial WebID Document considerations @@ -92,7 +92,7 @@ URL: https://github.com/solid/security-considerations/pull/9 * TT: DIDs certainly are a possibility. Security concerns should go againt WebID, not against Solid. * eP: It's not explicit to WebID; it's related to Solid's reliance on WebID. An attacker could inject something into the WebID Document and thereby get access to your data. * TT: bad connection. -* TT: there is a circular reference. +* TT: there is a circular reference. * HZ: I agree that it should be a priority, but we are also deviating from the topic. I also understand Jeff and it is also a priority. I also agree with Pavlik that what Jeff requests shouldn't block that PR. How do we move forward? * HZ: Jeff, Is it a strong objection or preference? * JZ: I think Sarven and Virginia should be present. Some concerns need to be addressed. @@ -101,13 +101,13 @@ URL: https://github.com/solid/security-considerations/pull/9 * HZ: From architecture point of view I agree with Pavlik. If you store WebID document on the Solid Pod, if pod is not available the webid document is also not available. But I'm not going to die on that hill. * JZ: There are 50k pods on solidcommunity.net those people and those pods I'm concern about. It is not orthogonal. There is an existing situation of knowledgable people having WebIDs out of the Solid server. At minimum Sarven and Virginia need to be present. * HZ: I agree with all of you, let's take it offline. -* Ted: One of the challenges I had in PR9, the structure of the document needs to be more consumable and actionable. There is a blur between weaknesses and how to address them. The countermeasures are at the same level as the weaknesses. One is a theft of the token, there is another with theft of the credentials. There should be weakenss, attack and countermeasure that prevents it. And considerationsa about that weakenss. +* Ted: One of the challenges I had in PR9, the structure of the document needs to be more consumable and actionable. There is a blur between weaknesses and how to address them. The countermeasures are at the same level as the weaknesses. One is a theft of the token, there is another with theft of the credentials. There should be weakenss, attack and countermeasure that prevents it. And considerationsa about that weakenss. * eP: It will be easier to structure based on more than one weakness. * HZ: I see more thought about infrastructure and not only focus on p2p --- -* VB (following minutes but cannot join): Voting does not necessarily help with consensus. The issues with the PR are not objecting to the security consideration per se, but more seeking to add considerations with the approach. I am not opposed to hosting webid outside solid storage (obviously), but this PR seems to advocate for *not* hosting it on Solid storage, which is a strong message. I think we should look into how to securely allow to host. Happy to discuss next week / in another meeting. +* VB (following minutes but cannot join): Voting does not necessarily help with consensus. The issues with the PR are not objecting to the security consideration per se, but more seeking to add considerations with the approach. I am not opposed to hosting webid outside solid storage (obviously), but this PR seems to advocate for *not* hosting it on Solid storage, which is a strong message. I think we should look into how to securely allow to host. Happy to discuss next week / in another meeting. * VB: See: https://github.com/solid/security-considerations/pull/9#issuecomment-2155333752 on how to move forward. @@ -148,10 +148,9 @@ URL: https://github.com/solid/specification/discussions/557#discussioncomment-68 * SC: So, I'd recommend putting energy into improving data quality (and structure/semantics) at *source*, and building applications using that data. * SC: Some of the technical reports can already be serialized in RDF, so they can be consumed/reused in a variety of ways. (That's partly what Solid QA is doing.) * SC: Information on verifiable implementations have to do with Solid QA. -* SC: See SPARQL queries demonstrating what can be gleaned at the snap of a finger from source: +* SC: See SPARQL queries demonstrating what can be gleaned at the snap of a finger from source: * https://lists.w3.org/Archives/Public/public-solid/2024Jun/0002.html * https://lists.w3.org/Archives/Public/public-solid/2024Jun/0007.html ### STM new meeting time -* VB: I can no longer join on Tuesdays before 17:00 CET. Would be nice to change to another time, but not sure what's suitable. Options? - +* VB: I can no longer join on Tuesdays before 17:00 CET. Would be nice to change to another time, but not sure what's suitable. Options? diff --git a/meetings/2024-06-19.md b/meetings/2024-06-19.md index 5565b237..0b659b07 100644 --- a/meetings/2024-06-19.md +++ b/meetings/2024-06-19.md @@ -14,7 +14,7 @@ * [Pierre-Antoine Champin](https://champin.net/#pa) * Jeff Zucker * Grace Elcock -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * Maxime Lecoq-Gaillard ## Announcements @@ -58,7 +58,7 @@ URL: https://github.com/solid/security-considerations/pull/9 * eP: This PR was created 2 weeks ago. Some things need a little more protection. There was a lot of discussion. Maybe only describe the attack, not the counter-measure? Ready to merge? -### Add advisement on applicability of security policy based on authentication state and resource semantics +### Add advisement on applicability of security policy based on authentication state and resource semantics URL: https://github.com/solid/security-considerations/pull/8 @@ -109,7 +109,7 @@ URL: https://github.com/solid/security-considerations/issues/12 * Jeff: The majority of developers ignore both SAI and Type Indexes. A few of them use one or the other. "It's not a standard, it's not something I can depend on, why should I use it?" The longer we are in that period of ambivalence, the worse it's going to be in the long run. If we're going to have client-to-client interop, we need to give that consideration. Placing all of this on the server is a different view. * PA: And yet, they use Solid. * eP: I will start writing use cases that show the behaviour we're aiming for with SAI. -* MdJ: I don't think there's a lack of arguments for why SAI is better than Type Indexes. Maybe we should acknowledge that different people use Solid differently. There is a single storage protocol, but it doesn't have fine-grained access control. +* MdJ: I don't think there's a lack of arguments for why SAI is better than Type Indexes. Maybe we should acknowledge that different people use Solid differently. There is a single storage protocol, but it doesn't have fine-grained access control. * eP: But how do app devs know which to choose? * MdJ: App devs just publish their apps and their data needs; the rest is out of scope for them. * eP: But what about data discovery by the app. diff --git a/meetings/2024-06-26.md b/meetings/2024-06-26.md index bfa42c5e..68531396 100644 --- a/meetings/2024-06-26.md +++ b/meetings/2024-06-26.md @@ -11,7 +11,7 @@ * [Michiel de Jong](https://michielbdejong.com) * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * Grace Elcock -* Jesse +* [Jesse Wright](https://www.jeswr.org/#me) (jeswr) * Maxime Lecoq-Gaillard * [Rahul Gupta](https://cxres.pages.dev/profile#i) * Rui Zhao diff --git a/meetings/2024-08-28.md b/meetings/2024-08-28.md index b32210fb..f93675b1 100644 --- a/meetings/2024-08-28.md +++ b/meetings/2024-08-28.md @@ -14,7 +14,7 @@ * Fred Gibson * Grace Elcock * Hadrian Zbarcea -* [Rahul Gupta] +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * Ted Thibodeau (he/him) * Willem Datema * Tim Berners-Lee @@ -57,7 +57,7 @@ #### 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 @@ -69,7 +69,7 @@ URL: https://github.com/solid/specification/pull/678 ### 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: [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 @@ -79,7 +79,7 @@ URL: https://github.com/solid/specification/pull/678 * 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. +* 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 @@ -90,15 +90,15 @@ URL: https://github.com/solid/specification/pull/678 * 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. +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. +* 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. +* 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. diff --git a/meetings/2024-09-11.md b/meetings/2024-09-11.md index 1d2b5f36..37feb68c 100644 --- a/meetings/2024-09-11.md +++ b/meetings/2024-09-11.md @@ -9,7 +9,7 @@ ## Present * [Michiel de Jong](https://michieldejong.com) -* Rahul +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * [Pierre-Antoine Champin](https://champin.net/#pa) * Grace Elcock @@ -48,7 +48,7 @@ * Maxime Lecoq-Gaillard (lecoqlibre): I would like to make a quick demo of Semantizer, a TypeScript library I'm working on to make Solid apps. (It could be used to create non-Solid apps, too.) Semantizer is based on the RDFJS interfaces and uses mixins. Users can define their own mixins very easily to add methods to manipulate their data. Some mixins already exist, like the WebId, SolidWebId and TypeIndex ones. I will also add a Comunica mixin soon, to run SPARQL queries directly on the data. * MLG: The demo will be in the domain of agriculture. Let's start by taking a look at the datasets in my pod. All start from the WebId profile of a person (representing a food producer). In its profile, the producer is affiliated with some enterprises. Enterprises have their own profiles, in which they list catalogs which are linked to some products (catalog items). The demo will show the catalogs of the producer being fetched from its WebId. The demo will also make use of extended profiles (linked in the person and enterprise profiles). * MLG: First, we can see the React-Admin app, and later the code. We can see in the network console of the browser that the app is fetching my WebId, then the extended profile, then the enterprise and its extended profile, where it finds links to the catalogs. On the interface of the app, we can see the list of catalogs of the producer. We can click on a catalog to see the contained catalog-items. In the code, it is really simple; we load the documents (datasets) in the order explained above. -* MLG: Once I fetch/load the first dataset (profile), I can use mixins. With mixins, I have access to methods I can call on the dataset to access to data in an easy way. With only few lines, I can easily query the pod. I can also show you another example. A bit of code I'm working on for Startin'Blox which shows the usage of the TypeIndex mixin: I can get the TypeIndex by simply calling the `getPublicTypeIndex` method. Then I can directly access a registration instance with the dedicated method `getRegistratedInstanceForClass`. +* MLG: Once I fetch/load the first dataset (profile), I can use mixins. With mixins, I have access to methods I can call on the dataset to access to data in an easy way. With only few lines, I can easily query the pod. I can also show you another example. A bit of code I'm working on for Startin'Blox which shows the usage of the TypeIndex mixin: I can get the TypeIndex by simply calling the `getPublicTypeIndex` method. Then I can directly access a registration instance with the dedicated method `getRegistratedInstanceForClass`. * eP: Can you show us how you define those mixins. * MLG: Mixins are very easy to define. It is just a mixin function in TS, in which you define some methods you want to add to your dataset. You also have to export a factory to create and load instances of your mixin. (A helper is available.) * eP: Do you have an example of using multiple mixins on the same resource? @@ -78,7 +78,7 @@ * PAC: We haven't planned it yet but I was already asked. * eP: There are quite few project funded via NLnet working on Solid, is there a channel that we could announce creation of the WG there? * MdJ: I announced WG on the Unhosted mailing list. I didn't also post on the Solid forum. Thinking that WG chairs might want to announce it. -* PAC: We still need to pick the date for the first WG meeting. +* PAC: We still need to pick the date for the first WG meeting. * MdJ: I'll put it on LinkedIn as well. It would make sense if either PAC or the WG chairs announced something. * PAC: I will coordinate it with them. * eP: prepare to start handing off the proposed reports there. diff --git a/meetings/2024-10-09.md b/meetings/2024-10-09.md index 4e977db3..cc0d9a81 100644 --- a/meetings/2024-10-09.md +++ b/meetings/2024-10-09.md @@ -10,9 +10,9 @@ ## Present * Hadrian Zbarcea * [elf Pavlik](https://elf-pavlik.hackers4peace.net) -* Niko from NextGraph.org +* Niko (from NextGraph.org) * Tim Berners-Lee -* Grace +* Grace Elcock * [Rahul Gupta](https://cxres.pages.dev/profile#i) * Jesse Wright * Damon @@ -58,7 +58,7 @@ URL: https://docs.nextgraph.org/en/introduction/ * ...: Peer to Peer semantic web collaboration * ...: NextGraph is doing the same as Solid but differently * ...: RDF, Linked Data, SPARQL -* ...: Local-first CRDT of RDF β€” you can edit offline and data gets synchronized once you get online and without conflicts. I developed CRDTs for RDF, there are already formats for JSON. I added compatibility with automerge and yjs. This way one can mix all kinds of data. +* ...: Local-first CRDT of RDF β€” you can edit offline and data gets synchronized once you get online and without conflicts. I developed CRDTs for RDF, there are already formats for JSON. I added compatibility with automerge and yjs. This way one can mix all kinds of data. * ...: end-to-end encrypted * ...: decentralized β€” 2 tier. Not peer-to-peer; we have servers which act as brokers. It is based on pub/sub where replicas subscribe. All the changes are propageted. Brokers are constantly exchanging updates in anticipation of the devices that subscribe to them. Local replica offers SPARQL locally to the applications. * ...: also binary data @@ -85,13 +85,13 @@ URL: https://docs.nextgraph.org/en/introduction/ * ...: demo! * ...: we have web version on left and native linux on the right. there are three stores, one is private which user can only share across devices. there is also the shared space, where one can interact with other users. There is also a public space, like a website. * ...: I will create a new document, we can select from different primary classes. As you see it synchronized. I can change the title, it also updated in the other app. I can do a SPARQL update. -* ...: you can see `did:ng:o:.....` the last part has a public key. -* ...: let's do another update, now in the other app we see the whole history of the document, creation, signature, adding first triple, then adding another triple. I will add another one on the left and we can see another commit on the right. +* ...: you can see `did:ng:o:.....` the last part has a public key. +* ...: let's do another update, now in the other app we see the whole history of the document, creation, signature, adding first triple, then adding another triple. I will add another one on the left and we can see another commit on the right. * ...: Now I will disable connection in the web app, I can still edit the document. And in the other ap I will make a different update. No sync yet since the webapp is offline. Now we go backonline and we see on the right a fork. As soon as I make another commit we can see the automatic merge. So it has the automerge without conflicts, it also work on data deletion. * Rui: what does the `o` mean in the DID identifier? * Niko: We are registering the `did:ng` method; the rest is specific to NextGraph, and `o` means a document. You can find it in the DID section of NextGraph docs. * Rahul: Are you aware of Georges m-ld? How does it compare. Also what transport are you using? Are you aware of CRDTs algorithms developed by braid? -* Niko: Good remarks, I'm familiar with m-ld. I still need to talk with George. m-ld is not end-to-end encrypted but we need to discuss details. We use websockets for now on every clients, also between brokers we use websockets for practical reasons. As for braid, I met them a week ago, I will join them again in the week. A lot of common grounds and interest to work together. +* Niko: Good remarks, I'm familiar with m-ld. I still need to talk with George. m-ld is not end-to-end encrypted but we need to discuss details. We use websockets for now on every clients, also between brokers we use websockets for practical reasons. As for braid, I met them a week ago, I will join them again in the week. A lot of common grounds and interest to work together. * Tim: Does it use UDP or TCP * Niko: it uses WebSockets so TCP. For now it's good. * Tim: This is very exciting, it has a lot of things we want in Solid. We want local-first. Where are you based and who do you work for, why did you start NextCloud. @@ -105,7 +105,7 @@ URL: https://docs.nextgraph.org/en/introduction/ URL: https://github.com/solid-contrib/practitioners?tab=readme-ov-file#communication-channels -* eP: I would like to propose adding the bi-weekly meeting to the CG calendar +* eP: I would like to propose adding the bi-weekly meeting to the CG calendar * ep: Practitioners are meeting every other Thursday. Proposal to move it to the CG. The Solid CG calendar would be a good place. * Hadrian: no objection from me, this is related to the direction of Solid CG, are Practicioners open to that? * Rahul: Jeff wanted CG involved from the very beggining, adding to the CG calendar would be the minimum involvement. @@ -114,7 +114,7 @@ URL: https://github.com/solid-contrib/practitioners?tab=readme-ov-file#communica ACTION: Hadrian to coordinate with other chairs and then Jeff -### Special Topic Meeting scheduling +### Special Topic Meeting scheduling * CRDT * E2EE @@ -127,15 +127,15 @@ ACTION: Hadrian to coordinate with other chairs and then Jeff * Tim: You could coordinate with different priority on different weeks. * eP: We had this slot and didn't really use it. It clearly doesn't work. For me, it conflicts. Suggest we start with online slots. After a few months, we can decide whether to use the same slot. If all experts are using the same slot, we can continue that way. * Hadrian: We have proposal for a poll and for fixed slots. -* eP: I don't think the two proposals are mutually exclusive. Especially if we want to reach out to experts who are not Solid CG regulars. +* eP: I don't think the two proposals are mutually exclusive. Especially if we want to reach out to experts who are not Solid CG regulars. * Hadrain: I'm propose reducing STM meetings to one hour, and having multiple slots in the week which would be empty to start. Anyone can become a champion of a meeting, reserve a slot, and ensure experts are present. * eP: We need to do the poll first. -* Hadrian: You can do it in any order you like. +* Hadrian: You can do it in any order you like. ACTION: Pavlik to create a poll for CRDTs ### Use cases (continue from last week) - * eP: eating one's own cat food ☝️ + * eP: eating one's own cat food ☝️ * eP: https://github.com/janeirodigital/sai-js/blob/main/examples%2Fplenary%2FREADME.md * eP: example apps that could be adapted to solid * https://www.discourse.org/ (forum) @@ -146,4 +146,3 @@ ACTION: Pavlik to create a poll for CRDTs * https://framadate.org/abc/en/ (scheduling polls) * https://apps.nextcloud.com/ (misc apps) * https://apps.nextcloud.com/apps/polls (polls) - diff --git a/meetings/2024-10-23.md b/meetings/2024-10-23.md index 3d60fb57..fe989d18 100644 --- a/meetings/2024-10-23.md +++ b/meetings/2024-10-23.md @@ -9,16 +9,16 @@ ## Present * [Michiel de Jong](https://michielbdejong.com) -* Grace -* Rahul +* Grace Elcock +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * [Michal](https://id.mrkvon.org) -* Tim +* [Tim Berners-Lee](https://timbl.inrupt.net/profile/card#me) * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * [Pierre-Antoine Champin](https://champin.net/#pa) * Maxime Lecoq-Gaillard * Jeff Zucker * Erich Bremer -* Jesse +* [Jesse Wright](https://www.jeswr.org/#me) (jeswr) --- @@ -77,14 +77,14 @@ Maxime: At DFC, we are working on c2c specs about farming, but in fact it's even larger –> ERP systems. I would like to propose some work item next. Michiel: I think you can just create a PR on [the work items list](https://github.com/solid/specification/blob/df7cee6c4225b9cab5eedba3aec51074aeb7c067/index.html#L122) - + TBL: Shall we discuss it today? Maxime: Not today ### Error Notifications - + https://github.com/solid/notifications/issues/198 @@ -123,7 +123,7 @@ URL: https://wickie.invisible.college/solid-crdt * eP: I proposed creation of **CRDT for RDF CG** please support β€” https://www.w3.org/community/groups/proposed/#crdt4rdf * ep: Have discussed. Michiel, myself, Tim, Rahul, Niko from Nextgraph, Michael from Braid were present. Discussed CRDTS specifically toward RDF, and then other things (e.g., text, JSON, etc.). For this community, have followed up with people already experience with RDF CRDTs; need to follow up with people with experience with other CRDTs. Also need to prioritise which formats we want to work with beyond RDF. There will be more expertise from other efforts as well, as lots of communities have interest. -* +* #### Reminder of E2EE meeting on Nov 5th @@ -151,4 +151,4 @@ URL: https://communitysolidserver.github.io/CommunitySolidServer/latest/usage/no * eP: Possibly should have created it in `/ns/solid/notifications` instead of `/ns/solid/terms`. We can leave it under `solid:`, or I could PR it as a breaking change for CSS v8.0.0. * eP: I'm going to make PRs to the `StreamingHTTPChannel2023` and `solid/vocab` once we decide on the final namespace -* eP: I don't have a PR yet, but in my implementation for CSS, I have a new IRI for ??? which links to ???. One doesn't have to link to notification channel since one can stream straight from HTTP. I used this relation, but maybe should have been defined in Solid notifications (`/ns/solid/notifications`) rather than Solid terms.(`/ns/solid/terms`). There will be CSS v8 which could incorporate that breaking change. +* eP: I don't have a PR yet, but in my implementation for CSS, I have a new IRI for ??? which links to ???. One doesn't have to link to notification channel since one can stream straight from HTTP. I used this relation, but maybe should have been defined in Solid notifications (`/ns/solid/notifications`) rather than Solid terms.(`/ns/solid/terms`). There will be CSS v8 which could incorporate that breaking change. diff --git a/meetings/2024-11-06.md b/meetings/2024-11-06.md index 082c6102..56153ef2 100644 --- a/meetings/2024-11-06.md +++ b/meetings/2024-11-06.md @@ -13,7 +13,7 @@ * [Sarven Capadisli](https://csarven.ca/#i) * Tim Berners-Lee * Erich Bremer -* Jessie Wright +* [Jesse Wright](https://www.jeswr.org/#me) (jeswr) * [Rahul Gupta](https://cxres.pages.dev/profile#i) (since 14:30 UTC) --- @@ -62,7 +62,7 @@ Proposed by eP Proposed by eP * eP: Last week were discussing. Some people work on DIDs, e.g., did:web, maybe nostr too. We were thinking of using DIDs in Solid again in an organised way. -* SC: If people want to see the suitability of Solid DID method that is still there: https://solid.github.io/did-method-solid/ . Repo: https://github.com/solid/did-method-solid/ +* SC: If people want to see the suitability of Solid DID method that is still there: https://solid.github.io/did-method-solid/ . Repo: https://github.com/solid/did-method-solid/ * eP: Since ActivityPods using Solid + NextGraph, ... we could have some mapping for HTTP and DID. They want to have interop to switch between them, e.g., Solid / NextGraph interface. * SC: We should know the use case to know what people see limited in Solid protocol where people want DIDs. Also which of the methods or part of the system is useful. We did the solid method to have that mapping between http and did. People should bring those use cases forward. * eP: Does it rely on DNS? @@ -80,7 +80,7 @@ Proposed by eP * eP: Also in Social Web CG. * SC: LOLA: https://swicg.github.io/activitypub-data-portability/lola.html * SC: We didn't evealuate some of the spec proposals well or on time in the past, like PDS interop which implemented a Solid migrator. If we are going to look into migration we should evaluate those proposals. -* TBL: Nod. We need open source software to do it. We don't have to write big specs for those operations. +* TBL: Nod. We need open source software to do it. We don't have to write big specs for those operations. * SC: We looked at using HTTP COPY and archive packages and there is other stuff that we could revisit. * RG: I didn't quite catch the migration/hosting. * SC: It was about changing hosting providers and maintaining the URIs. @@ -98,9 +98,9 @@ URL: https://github.com/solid/security-considerations/pull/8 * eP: I suggest closing the PR, it can be reopened by providing requested example(s). The question is whether there is an example or not. * VB: I'd like to review again. -* SC: Different layers with the concern. If there's a general consideration that needs to be expressed doesn't mean it is applicable to every section in the document. There is some text that doesn't belong, needs to be moved or expressed as a general consideration. -* eP: I am not saying it should apply to all, but for each consideration there should be an example. For this we have zero. -* SC: The first example was what's ??? The point is when reading this document people should not blindly put the considerations in place because there are scenarios where it does not apply. For example, if you're unauthenticated you won't be able to perform write operations. What security measures will the server be adding about write operations if the user can't perform them in the first place? The point is you don't need to. Cuts through the whole document. As editor if you can find a place where it applies that's fine. +* SC: Different layers with the concern. If there's a general consideration that needs to be expressed doesn't mean it is applicable to every section in the document. There is some text that doesn't belong, needs to be moved or expressed as a general consideration. +* eP: I am not saying it should apply to all, but for each consideration there should be an example. For this we have zero. +* SC: The first example was what's ??? The point is when reading this document people should not blindly put the considerations in place because there are scenarios where it does not apply. For example, if you're unauthenticated you won't be able to perform write operations. What security measures will the server be adding about write operations if the user can't perform them in the first place? The point is you don't need to. Cuts through the whole document. As editor if you can find a place where it applies that's fine. * eP: My initial understanding you were proposing in relation to the example of ??? This does not apply to that example because initial request is not authenticated but execution of javascript opens up that possibility. @@ -130,4 +130,4 @@ URL: https://hackmd.io/zg2zvBafSauNydofOJY2Zw Proposed by eP -* eP: \ No newline at end of file +* eP: diff --git a/meetings/2024-11-13.md b/meetings/2024-11-13.md index 5e654997..f5e35b25 100644 --- a/meetings/2024-11-13.md +++ b/meetings/2024-11-13.md @@ -14,9 +14,9 @@ * Maxime Lecoq-Gaillard * [Pierre-Antoine Champin](https://champin.net/#pa) * Tim Berners-Lee -* Rahul +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * [Michal](https://id.mrkvon.org) -* Ted +* [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) --- @@ -71,10 +71,10 @@ * MdJ: Would it make sense to introduce 'community-level requirements' on Solid servers for things like [Turtle syntax preservation](https://github.com/solid/specification/issues/342)? * MdJ: Let's assume community level requirements. Can we entertain them in next two years? Can we even write down some kind of best practice in Solid CG? * eP: I think we can document use cases and include both Turtle and JSON-LD formatting nuances. -* TBL: ... When you put pods into VCS (version control system) repositories, then you will have stable pretty printing. Unless you have RDF-based version control system. +* TBL: ... When you put pods into VCS (version control system) repositories, then you will have stable pretty printing. Unless you have RDF-based version control system. * eP: To my understanding, NextGraph with CRDTs has RDF-based versioning of the graph. * RG: We can think about accommodating both RDF and TEXT in some way. -* eP: The use case should +* eP: The use case should * PAC: I want to bring forward another UC; I will submit it to the WG. Consider Verifiable Credentials, which are datasets, but that's another tricky part. They are defined with JSON-LD. The argument is that the format is strict enough to use it as plain JSON, and that was an important vector for people to accept JSON-LD and process it as JSON. In this scenario, the formatting should be preserved. ### farm/ERP client-client protocols diff --git a/meetings/2024-11-20.md b/meetings/2024-11-20.md index 4d9b1e18..0147993f 100644 --- a/meetings/2024-11-20.md +++ b/meetings/2024-11-20.md @@ -11,10 +11,10 @@ * Hadrian Zbarcea * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * [Rahul Gupta](https://cxres.pages.dev/profile#i) -* TimBL +* [Tim Berners-Lee](https://timbl.inrupt.net/profile/card#me) * Grace Elcock * [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) -* Maxime +* Maxime Lecoq-Gillard * Jesse Wright --- @@ -68,13 +68,13 @@ ACTION: Hadrian to clarify that with Virginia * RG: Reading the charter β€” 'at any given time there may be up to 3 co-chairs; each cycle defines a 2 year service. In first year, all seats will be up for election, then election for any vacancies', i.e., suggest a regular election cycle for one seat. * Continues reading... 'the remaiming chairs may nominate a co-chair for the remaining seat... If the chairs do not take any action, then the seat will be up for election in the next cycle...' * TBL: So two remaining co-chairs could agree on a co-chair. -* HZ: Would nominate EP as was next to be co-chair previously. +* HZ: Would nominate EP as was next to be co-chair previously. * MdJ joined β€” HZ updated on conversation and candidates for co-chair (Jesse and Pavlik) * JW: EP would you be interested in taking on role of co-chair? * EP: Thank you HZ for trust and confidence. Always happy to help but my situation is less stable. We need stability and continuation. Just finished a project with NLnet Foundation β€” unsure on future project and how much time can dedicate to Solid. * MdJ: First thought would be JZ as he is doing Solid practitioners and now core spec gone to WG anyway. Would make sense to move CG closer to practitioners. * HZ: Likes that idea. -* EP: Jeff would be second person I would think of β€” the CG call would need to join later (to allow JZ to join) +* EP: Jeff would be second person I would think of β€” the CG call would need to join later (to allow JZ to join) * HZ: JW, would you be willing to take on interim role as Co-chair? * JW: Yes, happy to take on interim role, but would endorse JZ or EP for the role * TBL: When this chair was up for election and after the election closed, he then started to chair/facilitate Solid practitioners so may feel that would take up chairing energy @@ -85,14 +85,14 @@ ACTION: Hadrian to clarify that with Virginia * MdJ: Can start to seek nominations, etc., now, and if soon, would reduce need for an interim * MdJ: Just means we chair a meeting every 2 or 3 weeks. Wouldn't want to do it for a year, but if just for next few weeks then fine. Preference would therefore be no interim co-chair and other preference to hold elections now vs waiting * RG: Last election ended Dec 15th (i.e., when appointments were made) β€” people don't have to rotate annually; just if there is a slot, then election would be annual. Suggest can start nomination now, with vote Dec 7–8, then result Dec 15 -* EP: Think it takes some time, e.g., 1 rep per facilitation β€” last time took 2 months, so need to start today +* EP: Think it takes some time, e.g., 1 rep per facilitation β€” last time took 2 months, so need to start today * MdJ: HZ and I can do this quickly -* EP: Likely to take less time and have fewer candidates. +* EP: Likely to take less time and have fewer candidates. * HZ: Perhaps can be more flexible with election process. Is there a need for secret ballot? * RG: 1. if more than one person is nominated, then would like a proper election to happen. When we had a nomination call, 5 people put up their hands. 2. One concern is use of W3C STV β€” when analysed results and why EP didn't get elected, it was selecting 3 best candidates from top choices vs selecting best 3 candidates from top 3 choices. Suggest having the process revised. * HZ: Definitely not in favour of heavy process but if community wants that then will do it * Ted joined β€” HZ updated we are discussing process for elections -* EP: While important to have process, it could be light-weight. If we stick to charter, that will prevent people having an issue. Anyone interested in taking responsibility can put candidates all in call with minutes, etc., and then can agree who the best person is for the community. +* EP: While important to have process, it could be light-weight. If we stick to charter, that will prevent people having an issue. Anyone interested in taking responsibility can put candidates all in call with minutes, etc., and then can agree who the best person is for the community. * HZ: Would be happy with this. * MdJ: Agree with EP β€” let's today start a nomination period for two weeks; during that time, anyone can make a public post to the mailing list to nominate themselves; then, efficient election after that. Don't want to count on only one person self-selecting. Also see RG's point about only looking at first choice. In other contexts, have ranked candidates and points based on ranking. Two weeks for nomination, plus two weeks for election. * HZ: Suggest discussing process next week after starting two week nomination process @@ -101,7 +101,7 @@ ACTION: Hadrian to clarify that with Virginia * JW: 1. assume HZ or MdJ will put email out to public mailing list (yes); 2. rather than separate call, is it possible for Solid CG call to give 15 mins to this discussion (think in following week and week after when we know more)? * HZ: Think we have consensus -ACTION: Nomination period to be opened via email today; talk next week re process +ACTION: Nomination period to be opened via email today; talk next week re process * HZ: Based on conversation, will skip interim as only a few weeks. Can revisit but as of now decided not go to interim chair β€” any objections? (none) @@ -116,14 +116,14 @@ URL: https://github.com/w3c/lws-ucs/blob/main/.github/ISSUE_TEMPLATE/use-case.md * EP: Would start with 1 variant and then can pull out into separate ones. Can take it and work from there. Activity Pub may have some. Will work with them to ensure they are submitted. * HZ: Don't worry about duplicates β€” will take care of it * TBL: Now we have some issues, I can look at them. Should be able to do strava, linkedin, strava β€” should be able to do NHS application. Basically, a lot of exercises with a lot of functionality, etc., but should all be able to work on a solid pod. Does that work for a use-case? As editor of use-cases, HZ, do you want things at lots of different levels? -* HZ: We discussed we want to close the first round of use cases by end-of-year, so can process and use them. That does not mean we will then no longer accept use cases. LWS will use requirements to create the spec. There is no use case doc yet, so use issues for now to create new use cases. In Mon meeting, PA suggested compiling use case doc early and often. -* TBL: The fact that requirements will be developed from use cases means question is answered. +* HZ: We discussed we want to close the first round of use cases by end-of-year, so can process and use them. That does not mean we will then no longer accept use cases. LWS will use requirements to create the spec. There is no use case doc yet, so use issues for now to create new use cases. In Mon meeting, PA suggested compiling use case doc early and often. +* TBL: The fact that requirements will be developed from use cases means question is answered. * HZ: Want to have first draft of use cases to allow group to continue with requirements * RG: Take TBL question further β€” there are use cases where want to use something with Solid or patterns which serve a family of use-cases. There is one template and not clear how to communicate patterns (e.g., notifications is a pattern useful for many use cases) * HZ: Difference between user stories and use cases. User stories might be more diverse but will be distilled into use cases β€” that is planned * EP: My POV, use cases should describe the problem, but should not use terms like 'web sockets' β€” can talk about real time updates. The context can be important here. - 1. app on a web server and low frequency updates (here webhooks would be an answer) - 2. app on user device running behind nat etc (websockets or streaming http responses) + 1. app on a web server and low frequency updates (here webhooks would be an answer) + 2. app on user device running behind nat etc (websockets or streaming http responses) 3. app on mobile device which gets suspended for battery saving (pretty much only webpush) * MdJ: The term "requirements" can be used as product requirements but also used for spec requirements. Need to be aware of two meanings of "requirements". * HZ: Agree, we mean protocol requirements. We want to future proof the protocol to be able to seamlessly support other protocols developed in the future (e.g. for identity) @@ -132,4 +132,3 @@ URL: https://github.com/w3c/lws-ucs/blob/main/.github/ISSUE_TEMPLATE/use-case.md ### Handling `xsd:string` and `rdf:langString` in shapes URL: https://github.com/solid/data-interoperability-panel/issues/322 - diff --git a/meetings/2024-11-27.md b/meetings/2024-11-27.md index 0a8c1e2b..a25c9323 100644 --- a/meetings/2024-11-27.md +++ b/meetings/2024-11-27.md @@ -38,7 +38,7 @@ ### Scribes * Michiel -* Hadrian +* Hadrian Zbarcea ### Introductions * @@ -67,8 +67,8 @@ * HZ: I won't be able to attend, but thanks PA for attending. * JZ: Sounds great, thanks * eP: I submitted one use case, but now await feedback on the format before submitting a few more -> https://github.com/w3c/lws-ucs/issues/17 -* HZ: I'll provide feedback today @elf-pavlik - +* HZ: I'll provide feedback today @elf-pavlik + ### Opportunity for co-chair candidates to present themselves and answer questions * eP: I don't recall crossing my paths with Han. I understand he works on a chat application. It would be interesting to get some collaboration. @@ -96,8 +96,8 @@ JZ: Uploaded the catalog to: * https://solidproject.solidcommunity.net/catalog/ -* https://github.com/solid/catalog/ -* https://github.com/solid-contrib/catalog +* https://github.com/solid/catalog/ +* https://github.com/solid-contrib/catalog * https://github.com/elf-pavlik/solid-efforts eP: I understand that we will use SHACL; since I use LDO, I would like to have ShEx available as well. JW: Yes, there is a converter. Also, I applied with Jackson for a grant to add SHACL support to LDO. I suggest writing shapes using [SHACL Compact syntax](https://w3c.github.io/shacl/shacl-compact-syntax/). For SHACL 1.2, I'm pushing to make the compact syntax a standard. I suggest using that compact syntax for all the shapes. @@ -116,4 +116,4 @@ JW: Yes the mapping is imperfect; depending on the converter, it might error or * PA: +1 * eP: At the same time, I don't think we discussed that well to the rest of the ecosystem, and there might be some expectation in the community that the current protocol is more stable than it really is. * MdJ: Yes, and the current spec mentions both WAC and ACP, so there is not even a single current protocol. -* PA: Yes eP, we are in agreement, the suggestion of backward compatibity with the ecosystem was one of the objections to the initial WG charter proposal; WGs are here to standardize things that have been incubated. Until it's a standard, it's not a standard. +* PA: Yes eP, we are in agreement, the suggestion of backward compatibity with the ecosystem was one of the objections to the initial WG charter proposal; WGs are here to standardize things that have been incubated. Until it's a standard, it's not a standard. diff --git a/meetings/2024-12-04.md b/meetings/2024-12-04.md index 6828703c..7ca9efd0 100644 --- a/meetings/2024-12-04.md +++ b/meetings/2024-12-04.md @@ -12,14 +12,14 @@ * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * [Michiel de Jong](https://michielbdejong.com) * Maxime Lecoq-Gaillard -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) --- ## Announcements -* [Solid World](https://www.eventbrite.co.uk/e/solid-world-2024-tickets-827616191307) this Wednesday. +* [Solid World](https://www.eventbrite.co.uk/e/solid-world-2024-tickets-827616191307) this Wednesday. * Solid Practitioners [presents ActivityPods](https://forum.solidproject.org/t/come-learn-about-activitypods/8317) Thursday. * Solid Wallets [Hackathon](https://www.inrupt.com/event/solid-hackathon/home) sponsored by Inrupt starts next Monday. * [FOSDEM](https://fosdem.org/2025/) Feb. 1-2 @@ -135,4 +135,3 @@ ACTION: Continue c2c discussion next week. Admin: HZ: Happy holidays, some calls may cancelled in coming weeks eP: Solid World in 1hr. - diff --git a/meetings/2024-12-11.md b/meetings/2024-12-11.md index 05e80aa7..0a6d2975 100644 --- a/meetings/2024-12-11.md +++ b/meetings/2024-12-11.md @@ -9,12 +9,12 @@ ## Present * [Michiel de Jong](https://michielbdejong.com) -* Niko - NextGraph.org -* Hadrian -* Rahul +* Niko (NextGraph.org) +* Hadrian Zbarcea +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * Alain Bourgeois -* [TallTed](https://github.com/TallTed/) // Ted Thibodeau (he/him) (OpenLinkSw.com) +* [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) --- @@ -35,7 +35,7 @@ ### Scribes -* +* ### Introductions * @@ -54,11 +54,11 @@ * MdJ: The call for nominations should beeen phrased in a more specific manner. * RG: Unfortunately, the way the charter reads, fixed 2 year terms was also the interpretation of Social CG (who picked up Solid CG Charter), much like the US Congress. * MdJ: I think we have consensus that we all thought it would be staggered and were surprised by Sarven's comments, we think staggered is better. We could vote on it on this call and then add a sentence to the charter to make it clear. -* Ted (chat): Staggered terms is common practice in W3C itself as well as long-lived groups. I recommend it. +* Ted (chat): Staggered terms is common practice in W3C itself as well as long-lived groups. I recommend it. * Ted (chat): Filling a vacancy that arises mid-term usually but not always runs thru that term's end, not a fresh 2 years from election. * RG: I would wait a week and publish it to the community forum and on matrix. ACTION: next week to vote on the clarification on the charter. -* eP: Propose making a pull request on the charter and once the conversations is settled put an item on the agenda. +* eP: Propose making a pull request on the charter and once the conversations is settled put an item on the agenda. ACTION: MdJ to open the pull request and we'll vote on it next week. eP volunteers to help. @@ -116,7 +116,7 @@ URL: https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$GTTvQgauz8PY6ky2bRSMwyFV - ... The special thing is that the client ID matches the domain of the redirect URL from OAuth. * eP: If that uses ACL origin but not as the origin header, I think it's not currently defined that way in WAC. - ... In Solid OIDC, we have 2 options currently. [...] - - ... There is no global identifier such as WebID. + - ... There is no global identifier such as WebID. - ... We can pick it up at one of the next meetings. * MdJ: We should check the WAC spec to make sure it's clear. I don't think we should move away from dynamic registrations, because you might trust a random app, even if the server never saw that app before. * eP: If you use URLs as client IDs, you don't need to do dynamic registrations. https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/ @@ -125,7 +125,7 @@ URL: https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$GTTvQgauz8PY6ky2bRSMwyFV - ... [from chat]: https://github.com/solid-contrib/pivot/pull/38 * eP: I don't think r/w that data, but all the data you have access to. If you're in a social graph, interacting with other users, that's a problem. * Niko: Yes, that's the main reason I came today, this subject is very interesting to me. I am local-first oriented. URLs are tied to servers, but local-first does not involve a server [...] - - ... I am very interested in identifying applications. I am thinking of taking a hash on the binary. + - ... I am very interested in identifying applications. I am thinking of taking a hash on the binary. * MdJ: There is also the concept of an instance of an app running on a specific device. - ... Because there is no point of entry, as there is in a normal web server, the permissions should probably travel with the data. I am giving access to this data, and here's how to request it in the future. * eP: E2EE comes into play, too. Should we put this on next week's agenda? How do we follow up? diff --git a/meetings/2024-12-18.md b/meetings/2024-12-18.md index ef75bb95..d1dcdc91 100644 --- a/meetings/2024-12-18.md +++ b/meetings/2024-12-18.md @@ -99,7 +99,7 @@ URL: https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$GTTvQgauz8PY6ky2bRSMwyFV * eP: My point last week was to name it after the goal or promise of what they should acomplish. * RG: We want interop with evolvability * HZ: There seems to be consensus that C2C needs to be changed, we need to wait for Tim's feedback, ... -* JW: I would propose to set up a task force to work with developers and converge on the ways of doing that. Having a coordinated environment would help. +* JW: I would propose to set up a task force to work with developers and converge on the ways of doing that. Having a coordinated environment would help. * JZ: Isn't it the data modules group? They have been going through various domains and coming up with specs. Maybe it is more focused on the libraries. * HZ: It is not a specific implementation, but what the spec should look like. * JZ: It wouldn't be to develop those specs, but to come up with methodology. @@ -116,7 +116,7 @@ URL: https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$GTTvQgauz8PY6ky2bRSMwyFV * HZ: Do you have someone in mind? * eP: I will participate but don't want to lead since I'm editor of SAI and that could create tensions. * HZ: You already clarified that you don't want to push SAI. -* JZ: I want to second that, I wouldn't question Pavlik's ability to separate SAI from whatever we will come up with. +* JZ: I want to second that, I wouldn't question Pavlik's ability to separate SAI from whatever we will come up with. * RG: I wanted to check with Jesse; you had an application for NLnet, how would that overlap? * JW: We applied with Jeff and Jackson Morgan, Tim also signed off on it. We wanted focus on help with publishing shapes, specificaslly SHACL, as well as to improve DX with LDO. However, NLnet haven't accepted it, and modified it. They would like to support Solid. I need to do that in next few days. * ...: If we could focus on defining interop-patterns/best-practices/meta-specification. As a work item, name individuals that would work on implementing it in specific domains. We are effectively submitting a new appliation that they will help us fast-track. diff --git a/meetings/2025-01-15.md b/meetings/2025-01-15.md index aab7d909..6ece6047 100644 --- a/meetings/2025-01-15.md +++ b/meetings/2025-01-15.md @@ -11,7 +11,7 @@ * [Michiel de Jong](https://michielbdejong.com) * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * [Rahul Gupta](https://cxres.pages.dev/profile#i) -* Hadrian Zbaracea +* Hadrian Zbarcea * [Erich Bremer](https://ebremer.com/profile#me) * [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) (OpenLinkSw.com) @@ -37,7 +37,7 @@ https://cxres.inrupt.net/public/SoSy25/solid-together/ + RG: The [Solid Together](https://cxres.inrupt.net/public/SoSy25/solid-together/) session, organized by Solid Practitioners, aims to highlight the various projects around the world that use Solid to serve the greater good in society. -+ RG: Contributions Welcome! ++ RG: Contributions Welcome! ### Scribes @@ -54,7 +54,7 @@ https://github.com/w3c-cg/solid/pull/21 * RG: For instance, during the summer vacation. * MdJ: I don't see that much use for that mechanism. It would be tricky to specify what a valid reason for not holding elections would be. * RG: This is meant only for an interim election. -* HZ: Let's not overcomplicate it; this situation already happened, and the existing two chairs were able to handle responsibilities. +* HZ: Let's not overcomplicate it; this situation already happened, and the existing two chairs were able to handle responsibilities. * RG: It's only for interim appointments. * eP: Is this is comment or an objection to the current phrasing? * RG: I only want to remove the word 'election'. @@ -73,7 +73,7 @@ https://github.com/w3c-cg/solid/pull/21 * MdJ: Are you making an objection? * RG: I will make a principled objection. * MdJ: It's not helping. -* HZ: Rahul, please add the comment and then we can have a vote. We are spending more time on process than work in the last year. +* HZ: Rahul, please add the comment and then we can have a vote. We are spending more time on process than work in the last year. * eP: I think I understand your approach. It feels a bit like defensive programming, where one tries to anticipate and handle all possible error cases. At the same time, it feels to me like premature optimization. Let's go with this, and if we have a real problem in the future, we can address it in the future. I don't think it will happen. * MdJ: https://github.com/w3c-cg/solid/pull/21/commits/8b13eb8481e478d206c4877f4694dcd518768b02 * TT: I don't think it solves the staggered requirement. @@ -111,7 +111,7 @@ RG: Congratulations! * RG: Can we have someone understand us the blank nodes better? * JW: What do you want to know? * RG: We need a diff format for the solid notifications. It is unclear how to handle blank nodes. I'm pretty confused about them. -* JW: Blank nodes don't have unique global identifier, by design. There is some entity, we don't have an identifier for it. If you want to do diffs, where you need to identify the blank node in other context, my suggestion is to skolemize the blank node and give it an IRI. We may want to look at Linked Data Event Streams (LDES) +* JW: Blank nodes don't have unique global identifier, by design. There is some entity, we don't have an identifier for it. If you want to do diffs, where you need to identify the blank node in other context, my suggestion is to skolemize the blank node and give it an IRI. We may want to look at Linked Data Event Streams (LDES) **. TT (Chat): Think of blank nodes like pronouns. diff --git a/meetings/2025-01-29.md b/meetings/2025-01-29.md index fd7b23da..2289d514 100644 --- a/meetings/2025-01-29.md +++ b/meetings/2025-01-29.md @@ -14,7 +14,7 @@ * [Rahul Gupta](https://cxres.pages.dev/profile#i) * Theo * Michal -* [TallTed // Ted (he/him) Thibodeau Jr](https://github.com/TallTed/) (OpenLinkSw.com) +* [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) @@ -45,12 +45,12 @@ https://github.com/solid/specification/issues/708 * eP: It is just an announcement. Next week I hope to bring it up for a vote. -* PAC: It is important to have people from Social Web CG also involved. We need consistent story about Solid and Activity Pub. +* PAC: It is important to have people from Social Web CG also involved. We need consistent story about Solid and Activity Pub. * HZ: Question to PAC: Isn't it more important to bring it to LWS WG? * PAC: The charter mentions Social Web CG as a contact that we will synchronize with. There is no active Social Web WG. WGs have active scope; they need to sync. What we are discussing isn't directly in the scope of the LWS WG. * HZ: What is the best path forward to bring it to LWS? * PAC: This is less urgent for the WG; at this moment, the WG is focused on use cases. I don't expect strong coupling with Social Web CG. This work item should be a joint work, in my opinion. Hopefully it will progress in CGs, and we will have better understanding how to progress. -* RG: The way we were discussing it yesterday, it will be a layer on top of Solid, not something in the Solid spec. Everything should be workable as a layer on top of solid. +* RG: The way we were discussing it yesterday, it will be a layer on top of Solid, not something in the Solid spec. Everything should be workable as a layer on top of solid. ### State of CG reports @@ -80,7 +80,7 @@ https://hackmd.io/8g6Lh81STPiXRInv8fBL_g * RG: I was approached by NDN. They are writing a paper which has a write-up on Solid. I found it dated; for example, term `pod` is not official. Can we have a cohesive explanation of Solid which is more technical than advertisement on solidproject.org? We can then point people to it to get an overview of Solid. * eP: Something like ? * RG: Maybe, but more detailed. -* RG: Also the client-client standards are inadequately discussed in documents. +* RG: Also the client-client standards are inadequately discussed in documents. ACTION: eP follow up on client client / interop effort. diff --git a/meetings/2025-02-12.md b/meetings/2025-02-12.md index 8a020ac6..1441165c 100644 --- a/meetings/2025-02-12.md +++ b/meetings/2025-02-12.md @@ -14,7 +14,7 @@ * [Joshua Cornejo](https://www.linkedin.com/in/joshuacornejo/) * Hadrian Zbarcea * Jesse Wright -* TimBL +* [Tim Berners-Lee](https://timbl.inrupt.net/profile/card#me) * [Rahul Gupta](https://cxres.pages.dev/profile#i) * [Erich Bremer](https://ebremer.com/profile#me) * [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) (OpenLinkSw.com) @@ -56,8 +56,8 @@ #### Update from FedID CG+WG * eP: Shopify presented their FedCM implementation -* eP: Among discussed issues, this proposal seems very relevant to adopting FedCM in Solid: [OAuth profile for FedCM](https://github.com/w3c-fedid/FedCM/issues/599) -* MdJ: I understand that we are not adding it to solidcommunity.net due to cookies issue. +* eP: Among discussed issues, this proposal seems very relevant to adopting FedCM in Solid: [OAuth profile for FedCM](https://github.com/w3c-fedid/FedCM/issues/599) +* MdJ: I understand that we are not adding it to solidcommunity.net due to cookies issue. * eP: Not sure about that; Theo also created a discussion in oidc-provider. #### Update from SWI CG @@ -82,23 +82,23 @@ * MC: Some people think of Solid as Social Linked Data which originally was using FOAF profile. The superclass of `foaf:Person` is `foaf:Agent`. With current take off of AIs, many peple are interested in exploring this space. I mostly want to coordinate efforts. * MC: Should we do a Work Item, a task force? * TimBL: Melvin, can you specify this work? What would be the objective? -* MC: There are different people who would like to achieve different objectives. I would like people to deploy agents to Solid pods; for example, the way you have TimBL bot. We should define what "agent" means. My peronal thought would be to document how to describe agents. +* MC: There are different people who would like to achieve different objectives. I would like people to deploy agents to Solid pods; for example, the way you have TimBL bot. We should define what "agent" means. My peronal thought would be to document how to describe agents. * TimBL: You may want to know who is responsible for the agent. * MC: Should every agent have an owner? * TimBL: RRSAagent, for example, works for W3C * Josh: https://www.w3.org/groups/cg/webagents/ * MC: There will be coordination with that CG, but also reuse what is already in Solid. -* Josh: I'm doing a presentation to the WebAgents group on the 24th +* Josh: I'm doing a presentation to the WebAgents group on the 24th **Title:** Wall-E wants to do what? Future authorisation challenges with agents - **Abstract:** Traditional access control mechanisms β€” Role-Based, Policy-Based, and Attribute-Based β€” all function effectively when an agent operates under a single, well-defined persona. Modern agents are increasingly fragmented, performing discrete tasks within specific personas and processes before transitioning to new ones. In such dynamic environments, static role, policy, or attribute assignments become ineffective. Instead, access must be granted precisely at the moment of task allocation and revoked immediately upon completion to ensure security and compliance. + **Abstract:** Traditional access control mechanisms β€” Role-Based, Policy-Based, and Attribute-Based β€” all function effectively when an agent operates under a single, well-defined persona. Modern agents are increasingly fragmented, performing discrete tasks within specific personas and processes before transitioning to new ones. In such dynamic environments, static role, policy, or attribute assignments become ineffective. Instead, access must be granted precisely at the moment of task allocation and revoked immediately upon completion to ensure security and compliance. * eP: ... * MdJ: explaining STMs * JW: It seems mostly about identifying and authorizing agents. In the paper, they take similar approach to what Tim discussed, where agent is owned by a legal entity. - [Delegated Authority paper from LLM Agent folks](https://arxiv.org/html/2501.09674v1) - [Access Delegation in LWS Use Cases](https://github.com/w3c/lws-ucs/issues/104) * MC: I don't want to influence group too heavily, but I can keep loose structure and put it out there. -* JW: There are talks about how to describe delegation to agents. It helps when people bring concrete proposals. -* Josh: FYI β€” delegation of authority in OIDC is not the same as authorisation to do things. OIDC acknowledges there's a "gap" that is uncharted at the moment. +* JW: There are talks about how to describe delegation to agents. It helps when people bring concrete proposals. +* Josh: FYI β€” delegation of authority in OIDC is not the same as authorisation to do things. OIDC acknowledges there's a "gap" that is uncharted at the moment. * eP: I see delegation as very important and would like to learn more about all the work mentioned. * MC: People say agents are the new applications @@ -107,7 +107,7 @@ See ML thread "[Who writes the ACLs on your pod?](https://lists.w3.org/Archives/ * MdJ: I call it data portabilty but it might be more interoperability. First is when you stop using one pod provider and start using another one; second is using multiple apps at the same time on the same data. The app uses bookmarks. Demo restricts the pod to only allow app launcher to access it; once you install the app with the launcher, it will modify the ACR to allow the app access to specific type(s) of data. I was happy to come back to it after 6 years. - I see it as better than consent dialog, which misleads that user only authenticates but doesn't authorize any data scopes. + I see it as better than consent dialog, which misleads that user only authenticates but doesn't authorize any data scopes. * eP: I plan to follow up on Security Considerations issue [Lack of client identification in Solid-OIDC + WAC](https://github.com/solid/security-considerations/issues/22) * eP: Security Considerations vs. unmet requirements from use cases * MdJ: I don't think we have a good understanding of requirements which Solid spec covers. And that makes it a security consideration if requirements say that Solid is not designed for chess, bookmarks, and other big number of apps. Given that we list those apps, and given that there is no way to do that, it makes it a security consideration. diff --git a/meetings/2025-02-19.md b/meetings/2025-02-19.md index 379783fc..4034d161 100644 --- a/meetings/2025-02-19.md +++ b/meetings/2025-02-19.md @@ -10,7 +10,7 @@ * [Matthias Evering](https://solidweb.me/testpro/) * [Pierre-Antoine Champin](https://champin.net/#pa) * [Areeba Aziz](https://areeba.ca/) -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) ### Meeting Guidelines * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). @@ -28,7 +28,7 @@ ### Scribes -* +* ## Topics diff --git a/meetings/2025-03-05.md b/meetings/2025-03-05.md index ac4ca859..13a48b79 100644 --- a/meetings/2025-03-05.md +++ b/meetings/2025-03-05.md @@ -10,7 +10,7 @@ ## Present * [Michiel de Jong](https://michielbdejong.com) * [elf Pavlik](https://elf-pavlik.hackers4peace.net) -* Rahul Gupta +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * Hadrian Zbarcea * Jesse Wright * Rui Zhao @@ -54,7 +54,7 @@ * MdJ: I think it is pretty related. AFAIK Credentials CG is about interfacing wallets with the web. You could have a boarding pass or driver's license on your phone, and CG describes how it could be shared in the browser to the website. You share it either with the QR code or with NFC to some device, similar to payments. They also add how to present it via JS API. What I'm doing is about wallets, but not necessarly adding interfaces and web page, but between them and storage servers. * HZ: The wallet API, the backend, is documented and open. Did you take a look at it, and would it be useful in your project? It could be useful to have multiple implementations. There is also ane from South American company which is doing attachments on VCs. * eP: In the case you're describing, connecting to storage, how is the user involved? -* MdJ: The user would not see much of a difference between sharing a credential on their device vs sharing one in their storage. You could have them in both location. It could be transparent to the user. The Verifiers would not receive the whole thing in the QR code or NFC interaction. They could receive a read capability, for example. +* MdJ: The user would not see much of a difference between sharing a credential on their device vs sharing one in their storage. You could have them in both location. It could be transparent to the user. The Verifiers would not receive the whole thing in the QR code or NFC interaction. They could receive a read capability, for example. * eP: So where the wallet is makes the main difference, device vs pod. * MdJ: ... There might be a big overlap with organizational wallets. What I will build will be a combination of a mobile app with pod. * eP: It would be interesting to see how it plays in local-first setup. Where VCs would be replicated. @@ -83,7 +83,7 @@ * eP: +1 to extract it as a separate draft report. * JW: That sounds reasonable. * MdJ: Can we make that change in Pivot. -* JW: I don't have time at this moment. I can look into it at some point. +* JW: I don't have time at this moment. I can look into it at some point. * MdJ: Since NSS already does it, we should also do it in Pivot. * HZ: Sounds good. * MdJ: We are just incubating here as CG ... @@ -115,7 +115,7 @@ * JW: There will be a separate droplet and a different domain. Ideally, we will wipe it every 24h, to make clear we just use it for testing. * RG: It is useful to have a place to test things. * JW: What prevents you from experimenting on localhost? -* RG: You do that first, but sometimes you need to implement things on a remote server. For example, notifications. +* RG: You do that first, but sometimes you need to implement things on a remote server. For example, notifications. * eP: +1 to separate it. * MdJ: I have a droplet which I just switch on and off, paying per hour of using it. * RG: I hope that we will keep a common account. We want an infrastructure that all contributors could use without having to pay for their own servers. I find it very convenient to have something like Alain's previous setup. diff --git a/meetings/2025-03-12.md b/meetings/2025-03-12.md index 3452deaa..4ac98672 100644 --- a/meetings/2025-03-12.md +++ b/meetings/2025-03-12.md @@ -8,12 +8,12 @@ ## Present * [elf Pavlik](https://elf-pavlik.hackers4peace.net) * [SΓ©bastien Rosset](https://activitypods.org) -* Hadrian +* Hadrian Zbarcea * Jesse Wright * [Erich Bremer](https://ebremer.com) * [Marc Haddle](marc.haddle@datasolids.com) -* Grace -* Rahul +* Grace Elcock +* [Rahul Gupta](https://cxres.pages.dev/profile#i) * [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) (OpenLinkSw.com) * Alain Bourgeois @@ -33,7 +33,7 @@ ### Scribes -* Hadrian +* Hadrian Zbarcea * elf Pavlik ## Topics @@ -52,7 +52,7 @@ Scheduling poll: https://app.rallly.co/invite/2FC5mr4PtLuC * SR: Theo (thhck) and Michal (mrkvon) are going to work on an agent and/or CSS extension. I'll help with the ActivityPub spec compliance. We have created a channel to discuss this. * SR: I created issues https://github.com/solid/activitypub-interop/issues -* ... we created this repository to discuss activitypub interoperability. +* ... we created this repository to discuss activitypub interoperability. * ... Theo and Michal started private conversations whether to do an agent or a CSS extension. Best would be an external agent, but there may be a lot of difficulty with that because we'd need to change a few things in Solid. * ... In the repo, I created issues. * JW: Just to clarify, is the goal to get activitypub implemented in CSS? @@ -61,7 +61,7 @@ Scheduling poll: https://app.rallly.co/invite/2FC5mr4PtLuC * SR: I will discuss with others and will create another channel. * JW: Only Jeff and myself have the permission to create new channels. * HZ: I prefer to have minimum permissions and I can request someone who has them to do it. -* eP: in general, with chat channels, I think of them as a scratch pad. +* eP: in general, with chat channels, I think of them as a scratch pad. ### Is the ActivityPub interop spec for Pod providers or agents? @@ -70,9 +70,9 @@ https://github.com/solid/activitypub-interop/issues/2 * SR: * eP: In specs, we define product classes, and then requirements are for a specific product class. -* ... At this time, each spec defines its own product class. I am trying to capture what product classes are needed in Solid. +* ... At this time, each spec defines its own product class. I am trying to capture what product classes are needed in Solid. * ... If we use agents, we need to define agents as a product class. -* SR: If it becomes clear that we could do that with an agent, there will have to be a spec for that. +* SR: If it becomes clear that we could do that with an agent, there will have to be a spec for that. * eP: I think we need to do a bit of a mapping. Need to look at concrete examples. * SR: I am not sure what a product class is, maybe provide an example? * HZ: We need notion of infrastructure. I don't think we can define today. @@ -89,7 +89,7 @@ https://github.com/solid/contacts/issues/8 * SR: I am the one who first raised the issue in the channel. I have a small document: https://pad.lescommuns.org/ZB36czLASgCGwSNAtYClmg?both * ... Still a draft. I am not satisfied with how it's currently done in Solid. -* HZ: Those standards come and go. We should support any standard and provide mapping. +* HZ: Those standards come and go. We should support any standard and provide mapping. * eP: https://github.com/solid/contacts/issues/5 * ... Very related to shapeTree meeting. * ... How to share a specific resource? If someone has multiple email, for example. @@ -97,7 +97,7 @@ https://pad.lescommuns.org/ZB36czLASgCGwSNAtYClmg?both * SR: I think this is a different subject. For me, it's just about WebID. What you are talking about is a Profile. It is needed to have more fine-grained profile. * eP: I was raising an issue that WebID Profile and Contact address book is not aligned at this moment. * SR: In an addressbook, do we want the information a person has on their profile, or just contact info? On a phone, you can put info on contact list yourself. -* eP: in SAI, you can add information. In a relation, one end can add infromation on the relation. Don't know who should lead the contact spec. Maybe we need to take action to see who can champion this spec. +* eP: in SAI, you can add information. In a relation, one end can add infromation on the relation. Don't know who should lead the contact spec. Maybe we need to take action to see who can champion this spec. * AB: Just to remember, there is a contact app in SolidOS. * eP: Is it fully reflecting what is defined in solid/contacts repo? * AB: In SolidOS, you have an address book that is not the profile, but you have a link to the profile. It works with people that have a WebID and those who don't. @@ -106,20 +106,20 @@ https://pad.lescommuns.org/ZB36czLASgCGwSNAtYClmg?both ### Selection process for Operations Advisory Comittee * JW: There are proposals for how to select how one can (1) self-nominate and (2) vote per the discussion [here](https://github.com/solid/odi-governance/pull/20#discussion_r1989956669). -* JW: Who is eligible to vote for the AC? It's a group of 3 people who give advice on solidcommunity.net, NSS-to-CSS migration, roadmap on infra.... ODI should prioritise. +* JW: Who is eligible to vote for the AC? It's a group of 3 people who give advice on solidcommunity.net, NSS-to-CSS migration, roadmap on infra.... ODI should prioritise. ... The draft of the selection process is that the CG are the people who can vote [...] ... Some people noted this what not appropriate so wanted to ask here who can vote and nominate: ...People who can self-nominate are people who have contributed to the infra in some way. Should we do something different? ( silence taken as a no ) * JW: Are there any objections to the use of a [broda count](https://github.com/solid/odi-governance/pull/20#discussion_r1987117784) for voting. * Rahul: [explain how broda count works] -* Rahul: Based on the feedback of nomination last time and CG, important to see the critera for nominating ourselves. "Substantial contribution" can be hard to define. +* Rahul: Based on the feedback of nomination last time and CG, important to see the critera for nominating ourselves. "Substantial contribution" can be hard to define. * JW: Greatly appriciate. ## FedCG update and Demo * eP: I had remote meetings with Theo and he made good progress -* ... wasn't able to join yesterday, but I believe Theo presented his work. I think he was using the Inrupt client libraries. +* ... wasn't able to join yesterday, but I believe Theo presented his work. I think he was using the Inrupt client libraries. * ... Theo implemented something similar to Solid OIDC, looks like we're close to using FedCM with Solid OIDC. I have to check to see how stable his code is. * ... Last week, during the FedCM meeting, there was a discussion about what part is the "core" and what are "extensions". Just to clarify, IdP registration is something we need for Solid; otherwise, the RP is deciding what IdPs to use. In Solid, we want the user to bring on IdP, so the registration is necessary. * ... If we get better collaboration with Social CG, maybe they'll create a working group.