# W3C Solid Community Group: Notifications Panel

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

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

---

## 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
* Sarven Capadisli

https://github.com/o-development/solid-webhook-client

---

## Topics

### Daylight saving time changes

* SC: DST starts in North America this weekend. Europe is later. No preference for which one to stay with.
* eP: It would be good to be consistence across panels
* SC: Posted a related message in solid/specification gitter channel
* SC: If we're going to make a decision, it should be made on the solid specification panel
* SC: Are most people in the US in this panel? Looks like it today..
* SC: Proposal: stay with US time for this panel, will work out the rest separately

### 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?
* SC: last weeks conversation is in the minutes. Are there other contributions on this topic?
* eP: on GitHub, there is a [project from Jackson](https://github.com/o-development/solid-webhook-client), which appears to be a WebHook implementation.

### Incorporate resource-centric discovery of notifications
* SC: Intention was to allow the simple/classic version of subscribing to resource updates - which was previously used for WebSockets.
* SC: Talked with Tim and agreed that we can postpone work on the "simple" version of Secure WebSockets. It can be revisited at a later date. The panel can focus on existing work - what we have in the Editor's Draft - and bring a stable version forward to solid/specification so that it can be referenced in the next release of the Solid Protocol.
* The previous version of WebSockets included the use of the `Updates-Via` response header, but this was not secure.
* For the Solid Ecosystem / Solid Protocol, we need a stable version of the Notifications Protocol and WebSockets. The next release of the Solid Protocol will link to a ~CR equivalent version of the Notifications Protocol and WebSockets.
* This applies to other specifications in the Solid ecosystem
* Based on the charter of the Notification Protocol, we need two implementations that are interoperable
* Just saying "here is a library" is not sufficient. A full application would be more compelling, one that makes use of the features.
* eP: We don't have an issue tracking the resource-centric design, but the HTTP Streaming Fetch option may be a good option here, because the URL for the subscription can use the same header as with ordinary resource requests.
* SC: does this pattern apply to other subscription types? Does this depend on solid-oidc [ADD LINK]?
* eP: This is somewhat particular to this particular subscription mechanism because it uses regular HTTP headers in the client request. (E.g., EventSource and WebSocket do not allow a client to control headers)
* SC: there are some issues related to "why is there a separate subscription endpoint"? If there is a way to do this via HTTP Streaming Fetch, then perhaps you could respond to some of those issues
* SC: The focus for this panel is getting a secure websocket definition available
* eP: Where can I find these issues?
* SC: In the notification specification repository https://github.com/solid/notifications

### Publication of Notifications Protocol ~FPWD
* SC: Anything major outstanding besides working out discovery/description of notification channels.
* SC: Minor editorial: A resolution from an earlier meeting was to have subscription types be listed in a directory/index/registry document and have the spec link to it. The Notifications Protocol shouldn't repeat the requirements from subscriptoin type specs in any case.
* SC: Aaron and I are looking into discovery/description. I/We will propose an update that does not depend on the FPWD release.
* SC: 1.0 would be the ~REC for the Notifications Protocol, but something like 0.7 or 0.8 could be the ~FPWD
* SC: the next release of the Solid Protocol specification is planning to link to the ~CR version of the Notification Protocol version
* eP: Will this versioning scheme follow SemVer? So 0.9, 0.10, 0.11, etc., or is it aimed at 1.0 after 0.9?
* SC: We are going in the direction of using Semantic Versioning, but we may not have a 2.0 version. 1.0 is intented to entail "Stable". So long as there are no major changes to the protocol, there will not be a 2.0
* eP: I was more interested in whether there was a limit on the number of versions before 1.0 (e.g., 0.100)?
* SC: I was thinking: 0.8 could be ~Working Draft, 0.9 ~CR, 1.0 ~TR
* eP: My preference would be to keep iterating, possibly after 0.9, but not limit ourselves by stating that 1.0 will necessarily follow directly from 0.9
* SC: +0.5 to that. When we think the specs are mature, and there are no Formal Objections, we should call that 1.0. I do not have a strong opinion on the versioning before then. Mostly that 1.0 has implications
* RG: Why not add a ~~version number~~ label to the draft? Rather than using 0.12 or 0.13?
* SC: The spec will say "Version X.Y". We shouldn't use terminology from W3C Process / Rec track stuff.
* RG: I am saying that we could use 0.2-alpha or 0.9-working-draft or 0.25-cr
* TT: Labels like that needlessly complicates the matter
* TT: The changes that are made should be incremental
* TT: Any "roughly CR" or "roughly REC" should be part of the document
* SC: It would be good to have alignment across all the specs
* SC: Right now, the Solid Protocol is leading the way for how version numbers are used
* SC: I haven't seen "alpha" or "-beta" specs
* SC: Even outside Solid, there are other instances of versions. E.g., Fedora spec is at 1.0 [ADD LINK]
* SC: High level: we need to work out an editors draft
* SC: If we release a snapshot of the spec, can we label that as 0.7?
* eP: Why 0.7 and not 0.15? That seems to communicate that we are "close" to 1.0.
* SC: The idea is just that we are, in fact, close to 1.0
* SC: If there are alternative proposals, please make that
* eP: Let's just start with 0.1 and then, when ready, we move to 1.0 (even from 0.3)
* SC: Fine with me
* AC: no strong opinions
* SC: No objections, so Aaron and I will create a 0.1 release, when the specification is ready for that
* SC: There are some subtopics related to preparations for the 0.1 release.
* SC: There are some adjustments related to the description and discovery of the channels. Any substantial issues outstanding?
* AC: There is an issue related to "endpoint" to something else. I'd like to sort that out first. That'd be a change effectively to the data model. Changes to the data model are more cumbersome to implementers than other changes. If we can do that before 0.1, that'd be great. Happy to propose changes.
* eP: It would be good to answer the subscription container issue, that gives a good answer to this -- they are simply subscription resources. When it comes to sources, "notificationSource" makes sense to me
* SC: Want to avoid debating the solution here, but if the consensus is that this issue should be sorted out, then we should do that, but we also need to be mindful of the timeframe of our charter.
* SC: We are OK on the timeline at present, but we don't want to have this go on too long.
* SC: The ~FPWD should be a low bar. If these things will take more than 2 weeks, I suggest we hold off until after the ~FPWD
* SC: One item to reiterate: we will need a document that links to the available subscription types and allows people to keep this registry up-to-date.
* SC: Aaron and I are investigating the discovery description so that there is not a dependency on the Solid Protocol specification.
* eP: in other panels, it is useful for some people to take specific actions. In this panel, it seems we leave too much work for the meeting itself. If we more clearly identify the actions, that would help moving things forward more clearly
* SC: How can we identify this more clearly?
* eP: Less of a template, more of a habit. In mtgs I moderate, when people are invited, they often accept taking these actions

ACTION: AC and SC will look into notification discovery
ACTION: SC container definition / POST re Protocol
ACTION: eP Update subscription type for HTTP Streaming
ACTION: eP Add inline issues to HTTP Streaming
ACTION: AC to address the "endpoint" terminology
ACTION: AC publish an index of notification types and link protocol document to that
ACTION: eP add inline issues to webhooks spec
ACTION: AC and SC add inline issues for other documents (protocol, WebSocket, LDN, EventSource)

### Is the "Solid Notifications Protocol" spec title too broad?
* SC: The spec mainly focuses on subscription. Should "subscription" be part of the title? Or can the spec potentially cover areas besides subscription?
* eP: WebSub (formerly PubSubHubbub) https://www.w3.org/TR/websub/
* SC: There is not much to do with WebSub, since that doesn't fit so well into the linked data stack
* SC: Let's look at the connection with WebSub next week.
* AC: We can circle back to it.

### Other Topics

* RG: Can you clarify the difference b/t Notification and Subscription
* eP: There are two different steps: first you create a subscription, and then you define how that subscription is delivered (notification)
* TT: A subscription is a request to receive notifications and the notification is the delivery of those messages