-
Notifications
You must be signed in to change notification settings - Fork 47
/
Copy path2024-03-06.md
142 lines (109 loc) · 13.9 KB
/
2024-03-06.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
# W3C Solid Community Group: Weekly
* Date: 2024-03-06T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://matrix.to/#/#solid_specification:gitter.im
* Repository: https://github.com/solid/specification
* Status: Published
## Present
* [Hadrian Zbarcea](Inrupt)
* Aaron Coburn (Inrupt)
* <a href="https://csarven.ca/#i" rel="schema:attendee">Sarven Capadisli</a>
* [Pierre-Antoine Champin](https://champin.net/#pa)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* Rahul Gupta
* [Matthias Evering](https://solidweb.me/testpro/)
* Alain Bourgeois
* Tim Berners-Lee
---
## Announcements
### Meeting Guidelines
* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Join queue to talk.
* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.
### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/).
* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
* If this is your first time, welcome! please introduce yourself.
### Scribes
* Sarven Capadisli
### Introductions
* name: text
### Co-chairs Rotation Schedule
URL: https://github.com/solid/specification/discussions/618
---
## Topics
### Status of the WG Charter
* HZ: PAC, any updates?
* PAC: The W3C Council that decides on FO's has started. Not sure how long it will take. The Council Process is relatively new. The Team's recommendation was to submit a new charter. Moving with the existing charter is inappropriate, and the TAG also raised some concerns. That tells us objections that can be addressed in the new charter. Some of them may be raised again. Not all objections are 'justified'. We can argue against those. If they come up again, we can go to the Council again. We knew some objections would come up. The hope is that the next Council will overrule them again if they come up again.
* TBL: I had back and forth with one of the objectors. Their issues could be resolvable. Changing the name of the group is larger.
* PAC: I wanted to bring this forward. I had this discussion with some people. You're going for a specific solution. THe Solid specification should be one input but not the predefined goal. As TBL mentioned, there was back and forth on addressing the problem space. My personal feeling is that, a sign of good to go is to keep the Solid name out of the Group name. We're not assuming that the recommendation will look exactly like the CG specification. I guess I would like to get a straw poll on whether this is a good or bad idea. Should we stick to a Solid WG or some other name — something more abstract or general?
* HZ: I'm understanding different themes. From TBL, there is no need for re-write but just minor changes. TBL?
* TBL: Changes are addressing some of the questions that they (AC?) had. One of them was about dependencies. Some are for the REC track and we need to prepare to move those things. Recognise them. The charter didn't call that out. I pushed back on one point, the CSS WG for example, where it was raised to charter a general problem. But, it is not called the "Style System Where the User Can Something Output" WG. They didn't want other systems to be in there. So, like with VC. It is a spec. You could say that ensuring the certain things by people and cryptographically, ??? to do that. One of the things is about the Mission, and I'm happy to change that. Maybe not easy to do. From "Fix the Solid Spec" to "World of Read-Write Authenticated Data" would be fine.
* PAC: TBL and I are saying the same thing. I think we change the charter and let the Council decide anyway. Please adjust and then you can go. Truly this is not TBL's recommendation but ???. I still have some changes to push to GitHub and submit to the CG. I'm currently re-writing the Mission. So, TBL, this WIP.
* TBL: Ok, thanks.
* eP: I do support some natural language on read-write protected data. Nasty contrast with open data. So here are more protected resources. I participated in the FedCM WG proposal. There is possible overlap. There is no problem with it but Solid WG was pointed out. Especially with things like Solid-OIDC. If FedCM WG goes ahead, we might have an alternative to Solid-OIDC. We should at least consider listing them as a possible Group to coordinate with.
* HZ: Do you still want to do the poll for changing the name?
* SC: Thinking about the name depends on the scope/mission. What do you want to get out of this poll?
* PAC: Whether people think it is important to stick to "Solid" or not. I agree that the name depends on the mission. At this point, do we feel we should stick with Solid or change?
* HZ: I'm neutral but biased towards keeping the name because people are familiar with it. I don't know if you find a name that reflects.
* SC: I don't have a strong opinion, I don't think it matters. In SocialWG, there was ActivityPub, AS2, LDN etc. Similarly this WG could publish a set of spec. In SocialWG some specs were overlaping. I don't think that the name has branding value to the working group. At some point it will be about sucess of the spec. I'm open to the idea to pick a different name. I think about Socially aware web, or talking about fixing the Web. I'm open to changing the name. Depends on the scope/mission/deliverables.
* AC: I'm interested in the scope/mission. Content coming out of the WG. If it helps us move the WG along, then happy to move. Basically neutral. Leaning slightly on changing the name.
* TBL: In principle on changing the name, as mentioned before with read-write protected/authenticated data. Even discussing in this group we have different opinions.
* eP: Sometimes branding can create tension especially in standards. To accomplish the mission of Solid, we need something more than what this Working Group can accomplish. Solid could push a storage spec, access control spec, etc. that other things approaches can also work with.. Thre are other projects in the same perimiter and don't worry about naming them because the Solid will build on them. There is more to Solid.
* AB: Neutral.
* 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
* 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.
* TBL: I think it is important that it is not just private data. A lot of it public, government data, maps. We need agreement in this group. These are not global. Some maybe restricted to the group. Most of the values on the Web is not just personal or completely private or public but in between. From the point of data spectrum, that's something Solid needs to address.
### Demo
### Special Topic Meetings
URL: https://github.com/orgs/solid/projects/16/views/1
* HZ: Solid Notifications discussed on 2024-03-05. If you have proposals for upcoming STMs we can add to schedule.
* RG: Can we have a slot for Solid Notifications?
* HZ: Yes.
* TBL: It has been awhile since we had an STM.
* HZ: We had them in last weeks
* SC: Was Solid Notifications discussed yesterday?
* 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.
### Release 0.11.0 Milestone issues
URL: https://github.com/solid/specification/milestone/7
* HZ: We have only 6 issues open. A lot are quite old. I'm curious if we can close or remove them from the release. IRI could be removed from scope. I'd like to close this.
* TBL: Fake 404 instead of a 403. It is a bit philosophical. I prefer not to lie 404 but to give 403.
* PAC: I want to make a more general remark. The solid Spec seems to override HTTP but I don't think that's the intent. Restating HTTP might be bad practice. There is some recommendation in the HTTP 7231.. do we have to respecify or override?
* SC: There is a lot here. There are some requirements that could be inherited from HTTP, but nothing should spec thing as new requirement. We may only increase SHOULD to MUST. Ruben raised a question, and I was trying to come up with an argument where `404` is useful, in many places Solid uses `403`. Currently we are consistent with `403` and sometimes `404` is allowed. There is a degree of freedom for the server to return appropriate status codes.
* SC: I do not support the idea of removing anything from the milestone. The milestone should include whatever is meaningful to release the new version. We could remove the milestone and just snapshot what we currently have. Implementation experience and other factors are taken into account for releasing new versions. This group should focus on the incubation aspect to give input/signal to the specification. It is a bit strange that the discussion should stop now.
* HZ: If that's the case, that's fine, but then we should focus on making progress on those if they are important for the next release. Thanks!
* eP: if we have an issue on a milesone, someone has to set it aside to move forward. There are two issues assigned to SC, and one to JB. We should make some criteria on moving them. Hard to handle without it.
* SC: Sometimes arguments are balanced enough that the design could go in either direction. If people are implementing one approach, it is a good signal for the spec. If there is not enough implementation experience, that's not adequate/sufficient input. Anyone can make a random call and the spec would be still consistent. We need to look at commitments and implementations to be more grounded. Some of that is expressed in "Success/Exit"-like Criteria.
* RG: On the issue of differences in HTTP and Solid spec — that's what I gathered from PAC and people at IETF. There aren't many but still need to address them. Have STM to get over the milestone hump.
* TBL: We don't have a WG. We have to make sure to make progress on the spec in good order. As a general point when it comes to HTTP, it was initially a Read-only protocol, and now we are doing read+write. Even if you get different formats, there are consistency requirements. Basically moreso than HTTP. Where HTTP specs didn't.
---
### Partial contact information sharing
URL: https://github.com/solid/contacts/issues/5
### Plans for publishing Client2Client shapes (and shapetrees)
URL: https://github.com/janeirodigital/sai-js/issues/80
URL: https://github.com/solid/data-interoperability-panel/issues/207
* SC: The Solid CG is using https://github.com/solid/shapes/
* eP: https://shaperepo.com/
* MdJ: https://pdsinterop.org/conventions/
From 2024-02-28:
>* MdJ: Leaving these topics for the next meeting:
### Update on ecosystem tests work
URL: https://github.com/solid-contrib/ecosystem-tests
* MdJ: We're starting ecosystem tests with headless browsers. Making progress on switch from launcher-exploration to SAI.
### ACP Tooling
URL: https://www.inrupt.com/blog/podbrowser-sunset
* MdJ: Does podbrowser sunset create a gap that needs filling?
### Meeting recording and publication
URL: https://github.com/w3c-cg/solid/issues/18