Skip to content

Latest commit

 

History

History
96 lines (73 loc) · 6.39 KB

2022-06-01.md

File metadata and controls

96 lines (73 loc) · 6.39 KB
Raw

W3C Solid Community Group: Solid Editors

Present

Announcements

Meeting Recordings and Transcripts

  • 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.

Participation and Code of Conduct

Scribes

  • Sarven Capadisli

Introductions

  • name: text

Topics

Access Control Policy authorization mechanism, version 0.9

URL: #408

Requirement levels for Notifications

Roadmap

Storage description

URL: #355

  • SC: Implementation feedback: #355 (comment)
  • TBL: Two designs 1) where each resource points to the space or every folder or 2) resources don't but folders do or 3) you have to search for the storage because nothing points to it.
  • TBL: I thought we agreed on 2nd. 3rd was too slow.
  • SC: I don't recall 2nd as an option. We discussed 1 and 3.
  • RV: Either can be implemented they can all work. No help in breaking ties.
  • SC: We could rule out 3rd.
  • TBL: Right. Do one GET on storage space itself and hten get information whether it supports SPARQL queries and things like that.
  • SC: re 2) why not resource?
  • TBL: Buy me vegan food every week for every link header. The folders are part of a folder hierarchy so logical to say this is the top folder. You find its contents and from the breadcrumbs these are the ancestors. That's useful information to know.
  • TBL: Instead of in the header you can put it in the data of the folder.
  • TBL: Another thing I thoguht about puting in the folder is the parent folder.
  • RV: I think we have an opportunity that's orthogonal. To work in an non-LDP environment.
  • TBL: LDP contains in rev. when folder a contains folder b, the triple, a ldp:contains b is in both a and b.
  • SC: Makes sense. Useful for anything that can read the container. But because we require slash semantics, that can still be determined.
  • TBL: That idea of having it in both a and b may be an bad idea so only have it in a. Current practice with ldp:contains.
  • RV: back to original 355. Discovery is good.. without description required, can't use it.
  • SC: solid:owner is one candidate that can be expected there.
  • TBL: Don't need it until coded.
  • SC: notify:notificationChannel info is also needed here.
  • RV: Got to go. Have to follow up via comments.
  • TBL: Leave the description state where it is a design but put in a status where we need actual practical cases to arrive. Has to write code for it. And protocol doesn't get more complicated / pods don't get more complicated.
  • SC: Agreed.
  • TBL: you're not interested random apps but only within the spec the functionality needed. implementation feedback on
  • TBL: What you're looking for other protocols needing it.
  • SC: Solid Protocol requires.. Notifications Protocol and that requires notificationChannel.
  • TBL: At the moment we have fast async websocket.. and some people want slow webhooks etc.. the architecture can be created for diff channels but people need to come up with other stuff.. like for organising a party.. or deliver people when need to be able to kick people's through their pods.. so then you get more requirements - advertising more functionality on the pod.
  • SC: What do you think of something like this for discovery for starters. We can deal with description later:

The server MUST include the Link header with rel="http://www.w3.org/ns/solid/terms#storageDescription" targeting the URI of the storage description resource in the response of HTTP HEAD or GET requests.

  • TBL: Is it okay to have a situation where there is no storage description.
  • SC: It could just simply empty. Is there a cost?
  • TBL: Every time you add to the Solid Protocol there is a cost.
  • TBL: Available of websockets is put on every resource.
  • SC: The current/old/insecure websockets yes
  • SC: This storageDescription is about as close as it gets to that unless resource header includes the subscription URL for each notification channel - websocket's being one. But that then introduces new link relations in HTTP header.
  • TBL: This whole discussions of some sort of a Storage Description is not needed for or called for by Secure WS protcol, which has its own disovery meethod which is realively fast. We should get the SWS protocol sepcd before spending time discussing Storage Descriptions, unless some other urgent need for them arises
  • TBL: When that need arises then the requiremts on the Storage Description will be cllear from that need, and so save us all wondering possible designed in the bsence of that clear need.
  • SC: But without making this feature available it makes it difficult to provide a solution for a number of use cases, e.g., storage description, contact information, policies, communication channels.
  • TBL: Contact info we already do withg the profile of the owner. Storage -> owner -> owner's profile includes contacts
  • SC: Sure. but those are one off link relations per use case right?
  • TBL: Maybe it'll be a function of a folder. we don't have all the use cases yet so can't let it drive the whole thing / generalisation.