changed 2 years ago  
Linked with GitHub

W3C Solid Community Group: Weekly

Present

  • Sarven Capadisli
  • elf Pavlik
  • April Daly
  • Alain Bourgeois
  • Jeff Z.
  • Hadrian Zbarcea
  • michal/mrkvon

Announcements

Meeting Guidelines

  • W3C Solid Community Group Calendar.
  • W3C Solid Community Group Meeting Guidelines.
  • 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

Scribes

  • April Daly

Introductions

  • name: text

Topics

CG Participation

URL: https://www.w3.org/community/solid/participants

  • HZ: is there a concept of non-binding vote for non-(yet-)members?
  • SC: This is a community group, hence the process is not as strict as a working group. Please refer to the contributing guidelines. Regarding voting, if there are strongly opposing views we can take a vote to help the group move towards reconciliation. Voting is less of a concern relative to operating under the community guidelines.

Implementation Feedback

  • SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
  • SC: Any updates to share regarding implementations? Quick demonstrations are welcome!
  • AB: NSS shall implement the latest notification/webhoook protocol https://github.com/nodeSolidServer/node-solid-server/issues/1722. Request for help/assistance. Notifications have changed in the spec (i.e., web sockets), so must be implemented in NSS. Need assistance to help move this forward.
  • SC: Is there a Issue logged for tracking this? if not it would helpful to do a call with implementors. We have an issue "Call for implementations": https://github.com/solid/notifications/issues/141
  • SC: we also have other looking at other aspects of the implementation. NSS will can fill more than one role: subscription server, notification server, etc.
  • SC: It would be great to update the table in the call for implementations.
  • AB: I will do that after the meeting.
  • SC: Great example - we have an intention and c all for help (e.g., we should create an issue)
  • eP: Can someone provide 1 min gist of reasoning for putting efforts in both CSS and NSS ?
  • JZ: CSS is not yet capable of delivering what NSS does?
  • eP: ok, thank you, is there a list of missing features available?
  • JZ: there issues in Solid Auth and related issues in other doc. More time is need to prepare to provide a more detailed answer.
  • SC: for the sake of accuracy - what features are in scope? (e.g., documentation, features list)
  • AB: there is a solidcommunity.net issue (https://github.com/solid/solidcommunity.net/issues/62)). There is no way to login with the user name but only with an email.
  • JF: that is not an issue of CSS but one of taking a large number of users (e.g., 50k) and migrating/creating in CSS. CSS server likely not capable to undertake this task.

Shapes repository

URL: https://github.com/solid/specification/issues/506

  • SC: There is some support for the proposal at the issue. If no objections, we can follow-up and close issue.
  • SC: Simple follow-up - we created a shapes repository and any shape that is described in a spec or work-item can be added to this repository. We want to avoid adding every implementation shape (it would be chaos!).
  • AB: where is this located?
  • SC: It will be located in the Solid Org - a repo called shapes.
  • AB: WHat about shapes that are under development. If they are not available under the shapes pain, it will be difficult (e.g., Solid Chat).
  • SC: Someone will make a PR to add a shape. Questions: Is there a spec that is requiring the shape or is this driven by an application. Encourage the creation of a spec that uses the shape.
  • AB: How can we share shapes that are being developed but are not in specs.
  • SC: Our focus is on shapes that "touch" or are mentioned in specs. The process may change.
  • eP: I strongly prefer that we separate efforts on core shapes (domain agnostic) and infinite number of domain specific shapes.
  • MK: Understand the need to focus on shapes that are "standardized", however it would be very helpful to have a way to share shapes being developed. How can we shares these easily between contributors?
  • SC: We have to be careful to manage what would likely be an infinite number of shapes versus the shapes that are aligned with specs. We could create an issue that calls for a repo or other process to assist develops with sharing/collaborating shape development. Propose consult with Jackson on how to open up the (shape) repo to support this emerging need.
  • eP: for later we also should connect it with app directory to know which app implements which shape (and shape tree): https://shaperepo.com/
  • eP: Michiel de Jong might do a project to help with domain specific shapes (and shape trees). I strongly prefer that we separate efforts on core shapes (domain agnostic) and infinite number of domain specific shapes for later we also should connect it with app directory to know which app implements which shape (and shape tree).
  • SC: Are we aligned on the purpose of the repo? Any objections/comments. There was call to have a repo on shapes. If that is not satisfactory, we can revisit this topic.
  • SC: No objections to creation of the shapes repo!

ACTION: SC to create solid/shapes repo.

AuthN and AuthZ Server side clients (apps)

URL: https://github.com/solid/specification/issues/504

  • SC: This is a follow-up/checkin on this issue as previous meetings have discussed this topic. I believe eP created this issue, can eP provide an status update? Jackson won't be able to work on it till later this week.
  • eP: The issue includes 3 specific design choices which so far received 0 feedback.
  • eP: the issue is currently inactive.
  • SC: Suggest we come back to the issue. If anyone in this meeting has processed the issue and has comments, please share your experience/comments.
  • SC: Since we do't have feedback, we';ll come back to this issue in the future. There is a lot of material to digest. When eP feels better, maybe he can provide a primer on the issue to help people understand where to start.
  • eP: It links back to another relevant issue about CLI clients: https://github.com/solid/data-interoperability-panel/issues/178
  • SC: Specify kind of actors and class of interactions: https://github.com/solid/specification/issues/36 (c. 2019)
  • SC: there has been wok on this topic over the past few years, but eP is helping to move this issue further. Question: will we look at server-to-server interoperability. Most conversations have been on client-server, but server-to-server interaction is increasingly important (as expected).

Auxiliary Resources with own Access Controls

URL: https://github.com/solid/specification/issues/501

  • SC: About time we have a closer look at this for a future milestone?
  • SC: This is a deep topic, probably can't get into too deeply today given the time remaining in this meeting. This topic touches upon access controls for profiles and resources (primary, auxiliary). Clarification is needed regarding what (specific) access is allowed, which depends on the type of resource
  • JZ: I recall you can have a ACL on a describedby resource. Is this still part of the discussion?
  • SC: This is a great example of this issue. So far that pattern has been in an implementation (e.g., NSS) but not spec'd. Along with ACLs having own ACLs. The WAC spec for example does not constrain which resources can have an ACL - so any resource can. We need to clarify in the Solid Protocol as there are cases in which separating the controls on the primary resource and the associated resource. See issue for some examples.
  • eP: I think we can't avoid paying attention to UX patters that might be required. If we expect end user to manage access policies we need to provide them with something that an average (non-geek) person can manage in responsible way.
  • AD: How complex is this going to be for users - with what Solid provides. Solid has many topics, .. so end user using some component, so is the complexity going to be too much for them or some abstraction that simplifies it for them. Especially using different applications that may not be uniform then it'd be difficult.
  • SC: WAC authorization model is designed to simplify (e.g., meant to be basic read/write/control). Users may also think in more of a workflow perspective, for example review of item.
  • eP: I'm happy to share some of the approach we took in the SAI spec. We could have short agenda point next week. SAI: https://solid.github.io/data-interoperability-panel/specification/
  • eP: One's notes can go in some notes resource rather in the auxiliary resource.
  • MK: now, with acp having landed into spec, we also need to address potential incompatibilities between the two… (for next time…)

Resource state changes and differences

  • SC: We can revisit the state of below issues (topics) and look at next steps.

Standardizing state changes in resources (history, undo, sync)

URL: https://github.com/solid/specification/issues/161

Evaluate existing RDF delta/diff formats

URL: https://github.com/solid/notifications/issues/157

  • SC: Move work to solid/specification?

Topic

URL:

  • Proposed by
Select a repo