Skip to content

Commit ae5a33a

Browse files
michielbdejongelf-pavlik
michielbdejong
authored and
elf-pavlik
committed
Create 2025-06-11.md
1 parent a5d7d61 commit ae5a33a

File tree

1 file changed

+178
-0
lines changed

1 file changed

+178
-0
lines changed

‎meetings/2025-06-11.md‎

Lines changed: 178 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,178 @@
1+
# W3C Solid Community Group: Weekly
2+
3+
* Date: 2025-06-11T14:00:00Z
4+
* Call: https://meet.jit.si/solid-cg
5+
* Chat: https://matrix.to/#/#solid_specification:gitter.im
6+
* Repository: https://github.com/solid/specification
7+
8+
## Present
9+
* elf Pavlik
10+
* Hadrian Zbarcea
11+
* Michiel de Jong
12+
* Erich Bremer
13+
* Jeff Zucker
14+
* [TallTed // Ted Thibodeau Jr](https://github.com/TallTed) (he/him)
15+
- mastodon:[@TallTed](https://mastodon.social/@TallTed) (OpenLinkSw.com)
16+
- (lurking via hackmd.io; double booked)
17+
18+
## Regrets
19+
---
20+
21+
## Announcements
22+
23+
### Meeting Guidelines
24+
* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
25+
* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
26+
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
27+
* Join queue to talk.
28+
* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.
29+
30+
### Participation and Code of Conduct
31+
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
32+
* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Conduct](https://www.w3.org/policies/code-of-conduct/)
33+
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
34+
* If this is your first time, welcome! please introduce yourself.
35+
36+
### Scribes
37+
* Hadrian Zbarcea
38+
39+
---
40+
41+
## Topics
42+
43+
### Solid Catalog — describing software and deployments
44+
45+
https://github.com/solid/catalog/issues/22
46+
47+
* eP: Jeff and I would like feedback on conflating software with its deployment
48+
* eP: Talking to Jeff mostly about service implementations. There is a class 'product', and also deployments of servers
49+
* ... I took 2 examples of deployments: Penny (describing metadata), there is a product section and the service section, which is distinct. There is a 'lauchAt' predicate. Another deployment is Discourse, similar metadata described by eP. There is a 'forum' deployment (lost connection)...
50+
* JZ: It is intended to be Solid's public registry. People may want to use some of the apps. It's more aimed at the general public. Something like a 'service' or a 'product' is critical, but for the users at large it should be described in terms of what it does. That's a different approach than dividing by product/service. I am looking at a way to do both, by having a direct link from the 'product' to the author's presentation of the product.
51+
* ... There wouldn't be a direct link from the product to the service. The SaaS is different from the product, but there may be links. You could use the interface to see if this is an author's deployment of a product.
52+
* MdJ: Good showcase of RDF.
53+
* eP: Do you want to link to the client-id or to the lauchAt.
54+
* JZ: Needs to be 3 records: product, client-id, and demo location.
55+
* eP: I created launchAt to see where you can load the app from. You can look at the client-id, but there is no guarantee that you can launch.
56+
* ... We mostly talk about deployed web applications. If you deploy on your machine, there is no reason to have it in a catalog.
57+
* MdJ: You want the 'product' to be in the catalog.
58+
* eP: The software is the product, and the executing process is the service.
59+
* JZ: I agree that there should be different records for the product and service. Once I saw eP's explanation, our views are aligned. I am ok with the way that's presented.
60+
* MdJ: One product may have more than one service and each of them may have their own 'launchAt'
61+
* JZ: It is not the product's responsibility to know where it's deployed. What I would like to do it differentate that case from when the author's says "this is where you can try it online"
62+
* eP: The catalog is structured like a big resource with all the data there. If we want to later separate into multiple resource, I think it'll be feasible.
63+
* ... The Solid ecosystem is still immature. In a year we may have multiple deployments of Penny with different terms of service.
64+
* ... Maybe we want to have a more specific predicate or sub-property; there could be value.
65+
* JZ: I said that eP's 'launchAt' satisfied the problem I raised, but it doesn't. Something like Penny is made to be deployed as many instances. I think it's valuable to go from the 'product' record to the 'author' deployment of it.
66+
* eP: I think we should separate a few concerns. There is no reasoning, no inference in this model. I also think we need to describe the scenarios. With the catalog, if you want to find if there is a deployment by the author, we can correlate if the developer and maintainer are the same.
67+
* ... Regarding finding the service from the product: of course you can find the service from the product, because in the end, we have a graph that can be queried. Direction is not a blocker.
68+
* JZ: Currently, the way it's done is exactly as eP described. You don't necessarily need a field in the 'product' record, but it could be displayed in the UI, based on results of querying the graph.
69+
* JZ: Every product has a status, which can be one of 4 values. Also, ODI is committed to this catalog. I hope that in the future somebody's duty will be to curate/maintain it. We cannot count on developers themselves to maintain the catalog; we need a process that's implemented on a regular basis.
70+
* eP: I prefer that the catalog be well curated. It is useful to know how well an app works with a specific Solid product or service. It is useful to be able to report security problems.
71+
* JW: For the wording of the PR, it is better to not say solidcommunity, as the service moved from NSS to Pivot.
72+
* MdJ: The spec changed a few times, last version mentions UMA, that nobody really implemented. Parts of the spec have not been maintained for a few years.
73+
* JW: I don't know about the authz implementation, for instance if Pivot uses WAC or ACP.
74+
* ... I think it would be more accurate to say: these are the apps that currently work against solidcommunity.net.
75+
* MdJ: That's fair. There are apps that work with other (trinpods), or multiple service providers.
76+
* eP: At some point, I hope we'll have some kind of bar, like: you need to link at least one deployment that works. I don't think we should make solidcommunity.net a special case.
77+
* MdJ: I agree with eP; I avoid mentioning solidcommunity.net specifically.
78+
* JZ: It's not fair to say that because an app was not formally tested with a specific provider, it doesn't work at all. I think it would be ODI's responsibility to collect public feedback.
79+
* MdJ: I consider myself a power user. If there's something I don't understand, it's fair to assume that it'll be hard to understand for a regular user.
80+
* JW: I agree with the pragmatism, I am just saying that we should be precise.
81+
* eP: I am proposing to mark those not touched in a long time as 'unmaintained'.
82+
83+
... discussion about the test harness
84+
* JW: does the test harness use a common manifest language?
85+
* eP: let's take a quick look.
86+
* JW: I think we shoud use it, I don't know who has the authority to maintain that.
87+
* ... at a first pass, I think we should ask Pete to maintain it.
88+
89+
---
90+
#### Jeff's version
91+
92+
I cede to Pavlik's point that the Product and Service records of a SaaS are two different things, we do not need to debate that. Two points which remain are a) do we differentiate between an author-mounted deployment (e.g., Vincent mounts a demo of Penny) and other kinds of deployment (e.g., ServiceX uses Penny as a front-end); and b) how do we make sure that a visitor to the record knows that it is not necessary to download and build Penny in order to use it. There should be a clear indication on the Product record that you can go to URL X and use Penny for yourself. This is different from saying here are ten services which include Penny in their software stacks.
93+
94+
To deal with those issues, I suggest we use a predicate in the Product shape something like hasWebApp or authorDeployment which points from the record of a Product to a SaaS mounting of it by its owner. The SaaS would stil need to be a record in itself, but there would be a clear link from the Product to the Service.
95+
96+
Something like this:
97+
```
98+
<urlOfPennyRepo>
99+
a ex:Product;
100+
ex:hasWebAppAt <urlOfPennyDemo>.
101+
102+
<urlOfPennyDemo> # <-- clientID
103+
a ex:Service;
104+
ex:softwareStackIncludes <urlOfPennyRepo>.
105+
106+
<urlOfServiceUsingPennyFrontend> # <-- clientID
107+
a ex:Service;
108+
ex:softwareStackIncludes <urlOfPennyRepo>.
109+
```
110+
111+
Unrelated — Discourse is not a Solid Resource by my definition. It is part of what is used to present a Solid Resource (the Solid Forum). Discourse should not have a record in the Solid Resources Catalog. I would simply list it as part of the Service stack with a URL pointing externally. If, at some point in the future, there becomes a (please, yes) Solid alternative to Discourse or Matrix, or those apps add Solid compliance, those would definitely be listed in the Catalog and would themselves have both Product and Service records.
112+
113+
---
114+
#### Pavlik's version
115+
116+
##### Discourse and Solid Project deployment
117+
118+
```
119+
<https://www.discourse.org/dist>
120+
a ex:Product ;
121+
ex:name "Discourse" ;
122+
ex:repository <https://github.com/discourse/discourse> ;
123+
ex:language "Ruby", "Javascript" ;
124+
ex:license "GPL-2.0" ;
125+
ex:developer <https://github.com/SamSaffron> .
126+
# more devs
127+
128+
<https://id.solidproject.org/forum> # <-- Client ID
129+
a ex:Service ;
130+
ex:name "Solid Forum" ;
131+
ex:launchAt <https://forum.solidproject.org/> ;
132+
ex:provider <https://id.solidproject.org/solid-oid> ;
133+
ex:softwareStackIncludes <https://www.discourse.org/dist> ;
134+
ex:termsOfService <https://tos.solidproject.org/forum> .
135+
```
136+
137+
##### Penny and demo deployment
138+
139+
```
140+
<https://id.vincenttunru.com/penny>
141+
a ex:Product ;
142+
ex:name "Penny" ;
143+
ex:repository <https://gitlab.com/vincenttunru/penny> ;
144+
ex:language "Typescript" ;
145+
ex:license "GNU AGPLv3" ;
146+
ex:developer <https://vincenttunru.com/> .
147+
148+
<https://penny.vincenttunru.com/clientid.json> # <-- Client ID
149+
a ex:Service ;
150+
ex:name "Penny (demo)" ;
151+
ex:launchAt <https://penny.vincenttunru.com/> ;
152+
ex:provider <https://vincenttunru.com/> ;
153+
ex:softwareStackIncludes <https://id.vincenttunru.com/penny> .
154+
```
155+
156+
#### Relations between Product(software) and Service(deployment)
157+
158+
```mermaid
159+
flowchart LR
160+
A(Penny) --showcase--> B(Penny Demo)
161+
B -- softwareStackIncludes --> A
162+
163+
```
164+
JZ comment - Yes but `C --softwareStackIncludes-> A` does not imply `A --webAppAt--> C`
165+
166+
##### screenshot showing Client ID of Penny demo deployment
167+
![image](https://hackmd.io/_uploads/ryrXF_fQgl.png")
168+
(See comment in the snippet pointing at where that Client ID is used. The same case as WebID for a Person.)
169+
170+
### Auth as Data
171+
https://youtu.be/iLp2xBMud10
172+
173+
* MdJ: does auth-as-data imply e2ee?
174+
175+
#### Test suite
176+
177+
https://github.com/solid-contrib/specification-tests
178+
https://github.com/solid-contrib/conformance-test-harness

0 commit comments

Comments
 (0)