# W3C Solid Community Group: Notifications Panel

* Date: 2022-03-17T14: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)
* elf Pavlik
* Aaron Coburn
* Jackson Morgan
* Igor Jakovljevic

---

## 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
* Pavlik

### Introductions
* name: Igor Jakovljevic
* Igor: Maria@CERN recommended me to this group. I work at CERN where we develop notifications system. It also involves Open Data and privacy aware systems.
* Sarven: Can you tell more about your involvement in development of notifications
* Igor: I mostly review and manage the project with another person. At CERN we have a lot of communication tools and systems. We don't have a central point to keep track on it. We want to start aggregating notifications. We have a pilot system running at CERN, looking forward to switch all the services to participate in this system. Also trying to get some user information on how they consume information in their private life.

---

## Topics

### Is the "Solid Notifications Protocol" spec title too broad?
URL: https://github.com/solid/notifications-panel/blob/main/meetings/2022-03-10.md#is-the-solid-notifications-protocol-spec-title-too-broad

* SC: Let's continue here (for 5-10 minutes).
* SC: If this is to broad we can pick more specific name. Any comments recommendations?
* AC: I really don't have strong opinions, I'm open to other name if someone comes up with a better one.
* SC: Within the scope of panel, we have a charter, we do stuff around notifications. Current protocol seems to be focused on subscriptions. Maybe we need to come back to use cases and see if any of them don't fit under the current spec.
* eP: For me the preferred approach would be to open an issue and ask for suggestions

ACTION: SC - Create an issue for this

### Publication of Notifications Protocol ~FPWD
URL: https://github.com/solid/notifications-panel/blob/main/meetings/2022-03-10.md#publication-of-notifications-protocol-fpwd

* SC: I propose that we publish FPWD on 2022-03-31. We should be able to incorporate some (most?) of the ACTIONs we agreed. However, any outstanding action/todo should not block the publication. They can go into following drafts.
* SC: Anything that can go in by this date goes in, the rest just gets published later. It's just a FPWD

PROPOSAL: Publish FPWD by 2022-03-31 (we will have a meeting on that day)

* AC: +1
* SC: +1
* eP: +1

RESOLUTION: Publish FPWD by 2022-03-31

* eP: last week we discussed versioning, will that draft have the 0.1 version?
* eP: I feel that we should be able to have as many minor versions as we need, and not _necessarily_ go from 0.9 to 1.0
* SC: the understanding is that Solid Protocol will normatively reference Notifications Protocol 1.0 and WebSocketsSubscription2021

* SC: We have the following actions that we can take up ad-hoc as subtopics (if necessary):
* AC to address the "endpoint" terminology https://github.com/solid/notifications/pull/43
* AC publish an index of notification types and link protocol document to that
* AC and SC will look into notification discovery
* SC container definition / POST re Protocol
* eP Update subscription type for HTTP Streaming
* eP Add inline issues to HTTP Streaming
* eP add inline issues to webhooks spec
* AC and SC add inline issues for other documents (protocol, WebSocket, LDN, EventSource)

#### Replace endpoint terminology
URL: https://github.com/solid/notifications/pull/43

* AC: I went through this quickly, Pavlik had some improvements. I want to move this issue forward to have consistent use of terminology. Proposed changes align with how ActivityStreams work. The sooner we can come to consensus on what the terms are the better. I want to get it done before FPWD.
* eP: I'd like to remove sub types details from protocol spec, it just duplicates things.
* AC: I fully agree.
* SC: Didn't we have it as action last week?
* AC: We should just do it this week.
* SC: I have a question about terminology. When we use terms like source or target, if the context is clear. Is the *source* is the source where you need to subscribe to or is the source of the notification.
* AC: I think here JSON-LD types become very important. There is separate TODO on making sure that JSON-LD context is published. Being clear on definitions on what for example *source* means for specific subscription type.
* eP: Currently, all three subscription types (WS, ES, StreamingFetch) work by the subscriber connecting to the source URI, and that terminology makes a lot of sense to me
* SC: The type gives context to it.
* eP: I just wanted to be clear that conceptually, the use of `source` is exactly the same in these three types
* SC: LDN is completely different anyway.
* SC: I'll review the PR.

#### Update README with subscription types
URL: https://github.com/solid/notifications/pull/45

* SC: For now we can link to notification README

#### Update subscription type for HTTP Streaming
URL: https://github.com/solid/notifications/pull/47

* eP: It's just an example
* eP: I will make direct commit adding inline issues
* SC: As editor one basically makes the call on suggestions.
* SC: I don't think we need to put PR bar on non-normative changes by the editor of the spec.
* SC: PR also helps to raise alert

#### add inline issues to webhooks spec

* SC: Issue or discuss?
* eP: Discuss
* eP: Jackson, are you interested in doing the bikeshed boilerplate or markdown?
* JM: If needed, I can convert to bikeshed. I don't want to be a bottleneck for this.
* SC: Bikeshed is not a requirment, in other spec we use more RDFa and take advantage of it.
* SC: Test suite is extracting RDFa from the spec. All that gets fed into the test suite.

ACTION: add bikeshed boilerplate to WebHooks

#### Relation between storage and notifications source (or agent delivering notification to target)

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

* eP:
* JM: Can you give an example
* eP: e.g., in LNDSub type inbox is where notifications can be referenced.. the subscription response includes webid.. agent with webid sends the notification
* SC: What Pavlik said is accurate. Main LDN spec has a notion of sender, receiver, consumer. `webid` would be the agent who has (needs to) access to the inbox.
* SC: LDN ST 2021 requests subscription providing inbox IRI, response includes `webid` which will be used to deliver the notifications. There is no expectations there that RS / Storage will be sending those notificatsion. But we may need to consider (security) issues around this.
* JM: The `webid` will be associated with whatever system delivering the notification?
* SC: That's correct.
* JM: As Alice I'm authenticated with Solid-OIDC, I go through negotiation process to figure out what the subscription type is. Subscription returns to me all kind information including `webid` of what will be delivering them.
* JM: ...
* eP:
* JM: So the main changes to specifications would be updates to the name of the label. Currently the rest is similar. Upon subscription request, server would return in subscription response a `webid` that will be used. This would probably not include DPoP?
* SC: Notification Protocol and all the types don't explicitly require Solid-OIDC, they just refer to Solid Protocol.
* JM: I think it makes sense to give some mention how authentication would work, when it comes to server communicating with the WebHooks endpoint. This is not client application communicating with the pod.
* SC: We inherit some things from Solid Protocol. I think it is ok to reiterate some of the examples.
* eP: I would use https://github.com/solid/access-token-verifier/
* JM: I think DPoP is overkill here, I would trust server itself...
* JM: At minimum storage server would need to know what is delivering the notifications.
* eP: I think we could leave that part up to implementations, but at least allow them to be distinct parties.
* SC: I like the idea about tracking unsubscribing as well. There may be some binding between RS and agent sending the notifications. I think this is good issue to consider details of that binding.
* JM: There would also need to be a way for storage server to tell delivering party that this subscription was requested.
* JM: The productive way would be by saying how this can work in concrete example and then walk back to abstracting it.
* JM: I can update the md to reflect our conversation.