# W3C Solid Community Group: Notifications Panel

* Date: 2022-03-03T15:00:00Z
* Call: https://meet.jit.si/solid-notifications
* Chat: https://gitter.im/solid/notifications-panel
* Repository: https://github.com/solid/notifications-panel
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* Aaron Coburn
* Rahul Gupta
* elf Pavlik

---

## 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
* Aaron Coburn

---

## Topics
* SC: Impl feedback doesn't need to be in notification panel charter.

### WIP Implementation Feedback
* SC: We'll allocate some time for implementation feedback going forward. Links to servers/applications welcome. What's everyone working on or plan to work on?
* AC: We are planning to implement, just waiting for little more stability in the spec. We implemented some of the features.
* eP: Are you refer to private or public impl.
* AC: It's a close source, proprietary impl.
* SC: I believe is server side
* eP: Interested in contributing (not whole effort) in implementing Streaming HTTP Fetch and WebHooks implementation in TypeScript. Not wanting to duplicate efforts w/ Jackson. It would be nice to structure the code so that a common core could underlie the various implementations (e.g., as a shared library)
* RG: Not implementing at present, but interested in the client applications that make use of these protocols
* eP: What programming language?
* RG: JavaScript
* SC: With available time, dokieli is being extended to add these features. Likely would start with WebSockets but may add other mechanisms, too. Will probably also support N3 patch; when sharing an article (e.g.), Dokieli loads the address book: if the user has control access to the document, the interface allows one to read and/or adjust ACL resource.
* eP: is the protocol recommending ETags and conditional requests?
* SC: that would be answered by the solid protocol, but perhaps we should discuss that as a separate topic
* eP: this is probably most useful when sending diff values, but we're not there yet

ACTION: create an agenda item about conditional requests and the notification protocol for the next meeting

* SC: the charter has mentioned the data model, so if there is a need to have a separate spec for the model, that is within scope of this panel. This would have something to say about whether the message would contain diffs
* RG: as we have different notification types, should we have AS2 as a canonical data model but also other data models if the server supports it?
* SC: the protocol could have a default, but since the protocol is pretty flexible, one could ask for different vocabularies
* eP: https://www.w3.org/TR/dx-prof-conneg/
* AC: part of the protocol we have in place allows for some kind of content negotiation for the data that returned in these messages. the basic idea there is json-ld or turtle can be asked.. but we can also extend that for thin/thick messages. a lot of things we can do with profile content negotiation. we can layer different json-ld contexts. different approaches.
* eP: it would be good to track this as an issue where we can discuss specific use cases. For instance, with streaming HTTP, you can use this directly with HTTP headers, but for other mechanisms (e.g., WebHook), it might look a bit different
* RG: I don't have a use case in mind, but this is generally more about how the protocol works. Coming at this more from a theoretical perspective than from a particular use case angle.
* SC: starting from use cases is a good way to go. At least we need space in the protocol to allow for these possibilities. E.g., use AS2 for certain cases and other models for other cases
* RG: Shall I create an issue for this?
* SC: Yes, but keep it scoped to particular use cases
* eP: Let's use existing issues. Before creating a new issue, see if this is a duplicate
* eP: diff - https://github.com/solid/notifications/issues/19
* eP: data model - https://www.w3.org/TR/dx-prof-conneg/

### replaced sequence diagrams format png -> mmd
URL: https://github.com/solid/notifications/pull/40
* SC: Please review.
* SC: one comment about the sequence diagrams: it mentions an authorization/access token or capabilities. We should make sure that the rest of the text reuses the same terms
* SC: for these diagrams, we should make sure that the diagram focus is on the core protocol to distinguish between those parts that are relevant to the Solid Notification protocol and those that are out of scope
* SC: this might involve including a rectangle around the relevant section
* eP: for this PR, it doesn't try to make the diagrams perfect, but it does make it easier to edit these files (it is iterative)
* SC: my comments above are more of a sub-topic, and for this PR, they are not required

### Requirements/Practice for minutes and quarum for significant decisions/actions
URL: https://github.com/solid/notifications-panel/pull/48#issuecomment-1050029195

* SC: There was a suggestion that meetings should have at least 5 people so that there was sufficient representation
* SC: Sometimes these meetings were informal and minutes were not kept
* SC: I think we can merge last week's meeting (provided we agree)
* SC: Should there be a minimum number of people? Is 5 the right number?
* eP: it is hard to get 5 ppl regularly. It is most important to work transparently, post minutes/agenda quickly. Some people have selective interests
* eP: small groups can be very productive, too. Async can be a good model, too
* eP: PRs usually take time before they are merged
* eP: I would encourage us to think more about transparency than a specific number
* AC: I'd echo what Pavlik said. Having a fixed number - if getting x people is hard, then having a transparent process is useful. Open issue. If significant, highlight in gitter channel. it could be discussed in the meeting. if there is a PR related, it doesn't have to be merged immediately, it can be longer. Some people may disagree but I think it is the right approach.
* SC: If there is a topic with a vote, is the suggestion that those in the meeting can vote and we give some time for others to chime in? How do others see that playing out?
* eP: Since we are writing a set of specs, we post the minutes, there will be an open issue, and finalize this with a Pull Request. Others will have multiple opportunities to chime in and/or object. Even if there are votes in certain steps.
* SC: We already have that. Anyone can respond to actions or PRs, and anyone can disagree with what was discussed in the minutes
* SC: If there is no fixed number for an action, that means that 2 people can have a meeting with actions. This opens up a new problem with trying to merge minutes
* AC: I'd say to when it comes to a spec it is just a document. And validity of that document how much trust people have in the way that document was crafted. I can publish a spec online and suspect that no one will take it seriously because there was probably no process. if we have a process - even if there are two people - it is more about having a clear and transparent process than trying to enforce limits. If anyone thinks that this panel needs to go in a different direction, then all those changes are in github. yes, we can in principle make these bizarre changes but that's going to undermine the confidence in the spec. ultimately we need to trust the people that are involved are doing a good job.
* RG: related to leaving the PR open: when a vote is open, perhaps putting that on Gitter, inviting people to comment
* RG: it is really important to have an open, welcoming process
* SC: not everything needs to be voted. The chair can get a sense of the meeting and there is a process if a vote is required. My comment is more about major items or tasks: e.g., a work item or major changes to the spec. The important thing is to get broad community consensus. When there are spec requirements, that text may not link to where that decision was made. That link should show that it wasn't just one person's decision for significant items.
* SC: seems we agree that meetings should be scribed, we should reach consensus for major actions
* AC: I think this has been a really good conversation. If people have a sense of minor vs major change, we know how to communicate those major ones - gitter, multiple meetings etc.
* AC: We should trust people over processes.
* SC: this just means removing the unwritten rule of a minimum of five people for meetings, so no real action
* AC: +1
* eP: +1
* RG: +1

### Next Agenda
ACTION: the resource-centric discovery topic should be top of the agenda for next week

_Note_ The following is an initial introduction of the next topics:
* SC: the first priority was to "solve insecure websockets", this involves negotiation and subscription
* SC: there is interest in figuring out if the "simple" approach from earlier could fit within this model, or at least with fewer HTTP interactions
* SC: is there a way to achieve that simplicity that could be part of the notifications protocol?
* SC: would it be limited to WebSockets?
* SC: would it work for other subscription mechanisms?
* eP: I wonder if this feedback is from an implementation: is it too complicated or non-performant? It seems that all the requests can be cached; it's just one extra request for each topic
* SC: part of the answer is that this comes from Tim as a way to evolve the current/broken approach to the notifications protocol defined here
* SC: can the payload be adjusted?
* SC: can the Updates-VIA be reused?
* SC: even if there is not a solution, it would be good for us to look into and provide an answer
* SC: this wouldn't compete with the existing notifications protocol (that will stay as-is)
* AC: I'm arguing that updates-via will not work and SC comes up with creative solutions
* eP: can this be in an issue?
* SC: yes. We can incorporate it into existing issues and/or share the notes.

### Incorporate resource-centric discovery of notifications
* SC: Intention is to allow the simple/classic version of subscribing to resource updates - which was previously used for WebSocket. Questions/Considerations (see subtopics):
* SC: To what extent can the Notifications Protocol incorporate both simple and negotiation-based (the current mechanism in the spec, eg. via storage description)?
* SC: To what extent would it be possible for all subscription types? For example, can the simple version leave out notification channel features?

#### Classic WebSocket with the Updates-Via header
* SC: Using JSON-LD payload (instead of the pub/sub one line) will be compatible with the Notifications Data Model (leaning towards AS2).

#### Issues/challenges for all subscription types
* SC: ...