# W3C Solid Community Group: Weekly

* Date: 2022-11-30T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* [Wouter Termont](https://github.com/woutermont)
* [Matthieu Bosquet](https://github.com/matthieubosquet)
* [Osmar Olivo](https://id.inrupt.com/oz)
* [Tim Berners-Lee](https://timbl.solidcommunity.net/profile/card#me)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* [Stijn Taelemans](https://github.com/lem-onade)
* [Arthur Joppart](https://github.com/belgiannoise)
* Tom Haegemans (Digita)
* [April Daly](https://aprildaly.us)
* Maxime Lecoq
* Eric Jahn
* [Ted Thibodeau](https://github.com/TallTed)
* [Matthias Evering](https://solidweb.me/testpro/)
* dindy
* Sindhu

---

## 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
* [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
* Matthieu
* Virginia

### Introductions
* name: text

---

## Topics

### Previous Meeting Minutes
URL: https://github.com/solid/specification/blob/main/meetings/2022-11-23.md

* SC: This is an announcement. The previous notes are published.

### Clarify that the Storage resource MUST be discoverable
URL: https://github.com/solid/specification/pull/485

* SC: The current editor's draft indicates that storage resource discovery could be optional, the clarification indicates it must be.
* SC: It is a change in conformance. Now the `rel=type` `storage` header is required
* MB: It makes things very straightforward and easy to understand, so I approve.

### Last week follow-up

* HS: Last week we finished with Tim speaking about the W3C, could we add this topic on agenda?
* SC: I don't recall it being pushed to today.
* HS: It was squeezed in the last five minutes.
* SC: We can add this at the end as it wasn't added to the topics for this meeting before.

### Notifications Protocol
URL: https://github.com/solid/notifications/pulls

* SC: Last call for feedback:
<https://github.com/solid/notifications/pull/124>, <https://github.com/solid/notifications/pull/122>, <https://github.com/solid/notifications/pull/120>.
* SC: These three PRs are intended to resolve important issues towards the next release of the Notifications Protocol spec. There is an intended Last Call meeting tomorrow (???link???) to wrap up those PRs.
* SC: One is on the notifications data model ([124](https://github.com/solid/notifications/pull/124)); it has to do with emitted change updates. We're cleaning up requirements in there.
* SC: [Pull 122](https://github.com/solid/notifications/pull/122) is on the constraints we have on JSON-LD (specific context/compacted...), there are various opinions (controversial) on this, both in the Solid ecosystem and other specs. It would be good to have one or two other reviews before consensus.
* SC: [Pull 120](https://github.com/solid/notifications/pull/120) is similar to a PR on the solid protocol, highlighting the classes of products that are expected to implement the requirements. We could separate in more ways, but I think the three basic kinds proposed are sufficient for a start.
* SC: Notifications protocol is set to be finished this year.

### Too Slow: Please provide `Updates-Via` shortcut to secure web socket address
URL: https://github.com/solid/notifications/issues/110

* SC: The current protocol does not incorporate the feature or mechanism expected by TBL. Please do chime in on the issue.
* TBL: The way websockets work is that if you want to listen to something, you open a websocket, and the client gets a callback if anything changes.
* TBL: It is advertised via an HTTP header. If you want to watch something, you can subscribe.
* TBL: We should have an ontology to advertise different types of notifications.
* TBL: You do a `POST`, and you get back from that `POST` the websocket you want to listen to; all secured, authenticated. Going to a virtual conference room, for example, when I open it up, I want to watch it immediately, but there are a lot of network round trips involved currently, and if the server is on the other side of the world, it significantly slows everything down.
* TBL: I can see that on one side we have a beautiful, generic, and flexible architecture, but it is slow; so maybe we can come up with an optimisation.
* TBL: Is anyone involved in the design on the call?
* KK: Not involved, but is there anyone else wanting to contribute first?
* SC: The approach in the notification protocol was generic (not to cover specifically websockets), and all contributions were toward the current design. That is, there is no specific proposition put forward. It was left until Tim felt we should give it consideration before the charter is up.
* KK: I see there's a lot of back and forth (ping pong for obtaining authz), what I'm seeing now is the possibility of putting the token as a field in the `updates-via` header. So if we simply extend the protocol with this, would it provide sufficient security and reduce the number of roundtrips?
* SC: There are concerns about trust domain security.
* KK: That is probably the right thing, if it is assumed that you need a different authz for notifications than for the resource described by the notifications. Also, there might be concerns about time to live (e.g., how long is your notifications authz valid?).
* SC: It's not necessarily the case that you should have access to notification about resources created in a container; for example, if you have temporary access to the container.
* TBL: e.g., OIDC is a mess of sensitive URLs.
* KK: Seems orthogonal to whether we use this or other approach.
* TBL: I just wanted to explain to those here.
* SC: In order for Notifications panel or other groups to work on it, or for it to be brought to Solid specifications, there needs to be a proposal. We understand the issue, but we need a proposal to take action. You (TBL?) or someone else could take up that issue, currently unassigned.
* KK: Should go back into Notifications panel.
* SC: Would you like to extend charter for 5 years?
* SC: I suggest that once we have our deliverables PRed, we can take this up as separate proposal. Thoughts?
* TBL: If you want someone to write a proposal, you need someone who understands authentication.
* SC: Any existing implementors doing something close enough that could join a call or make the proposal? I don't have the bandwidth.
* OO: Is there an issue?
* SC: Yes. [Issue 110](https://github.com/solid/notifications/issues/110).
* OO: I can think of only two implementors of this protocol: CSS and ESS teams. We should assign that issue to someone from that group. I can't speak for CSS, but I can bring it up to ESS team at Inrupt. Performance standards that we set out to achieve ??? so we should address.
* TBL: Someone should reach out to CSS team.
* OO: This is why I asked earlier why is this being discussed here. Ideally, CSS/ESS are working with Notifications panel. Without those people, I don't know how far we will get. We need to pull in people who attend Ntoifications panel. If no one from CSS attends, we should reach out as well. Without those people here, we won't get far.
* TBL: Sounds good.
* ME: I am simply a server mantainer with a CSS instance running. I have many questions. I can give feedback, but cannot be of help.
* SC: CSS team would like to have you engaged in their PRs/issues, because you do have a live server running, so when this issue is picked up by any team, you can follow there. We can announce and make more obvious so you can be aware of it.

### Trust between owners on same origin with multiple storages
URL: https://github.com/solid/specification/pull/290

* SC: This is a clarification that we're trying to get from one of earlier PRs around storage, owners, and origin. Following up on [issue #267](https://github.com/solid/specification/issues/267). Brought it into the meeting to create awareness and more engagement because it's a change that is expected to be part of the next release. It is a consideration we're trying to take up, whether or not it makes it into the release.
* SC: The idea is that if a server offers multiple storages, should the owners of each storage have trust between them? There were no objections, one approval, but there were comments which requested clarity on the intention. I think we need better justification/language to clarify those concerns, or we don't include in next release.
* SC: This was worked on with TBL, KK, JB, and myself. Maybe others can offer more insight.
* TBL: Very obscure point, important but "trust between..." is ambiguous. Does it mean you should not build systems where there is no trust? Does it mean that there will be trust between ??? necessarily? The way it is stated is very confusing, not helpful.
* SC: Good self-review because we drafted together :)
* TBL: Yes, and I thought that when we did.
* SC: First part of this is a note. Second part is ??? That is the one where commenter felt it was unclear. If we focus on that we can move this forward. Line 904.
* TBL: ??? about web app security? If people have have webpages with JS on their pods, the issue ??? Solid doesn't use web origins, but when people use solid pods as ordinary blogs, for example..
* SC: Pre-proposal: would you (TBL) or anyone object to not including that statement at all?
* TBL: Happy to leave the whole PR out of next release.
* SC: No objections to the note and people find it useful. It is the second part. I can update PR to remove that. Would you approve?
* TBL: Yes.

ACTION: SC to update PR to reflect the discussion (remove second part, leave note).

### Agent-specific Discovery
URL: https://woutermont.github.io/solid/agent-specific-discovery.html

* WT: Proposal based on stuff already in SAI, but tries to take out a specific part that doesn't belong with the rest, and make it a separate specification. It is concerned about agents/client who want to discover info about some entity, can find not only public info available in identity document, but they can also find an easy way to know where the info specific to that client lives.
* WT: One approach would be a lot of `seeAlso`s in profile document and have client check all of them. ??? proposes to have a microservice/hub to which an entity points to within their profile doc, and client can ask the service for a pointer to the place where their specific data can be found.
* SC: How would you like to continue with this proposal?
* WT: I want to bring awareness. I'd like people to comment on it to see if it's valuable as a separate specification. Would like to invite SAI and WebID Profile editors to react as how they see it fits next to or in line with their proposals.
* VB: We can discuss next WebID-profile meeting. Will make sure to read thought and prepare questions/comments, so that it's productive.
* TBL: In the discovery space there are competing hopefully compatible mechanisms such as type indexes. ??? agent is more complicated. Some of your interventions in Gitter about this, you seem frustrated about the fact that we're not doing things that are compatible with interoperability spec first, but please be gentle about it. We are working first around working code, but we will discuss later on.
* SC: I want to make sure there is an editor behind this as a work item. First thing is collaborate with existing panels/specs and see how their proposal fits in, and then we can see whether it is part of existing work item or separate. If we can sync up after we have these initial sessions. Not an issue to work on it as work item, but before putting it into its own spec let's see how it fits in existing.
* WT: Will get in touch asap with people from interop. Thanks TBL, will do my best to be polite :)

### SolidOS topic in two hours
* ME: Want to talk about making ??? compatible with NSS. We will discuss later in SolidOS meeting.