W3C Solid Community Group: Notifications Panel

# W3C Solid Community Group: Notifications Panel * Date: 2021-10-14T14:00:00Z * Call: https://meet.jit.si/solid-notifications * Chat: https://gitter.im/solid/notifications-panel * Repository: https://github.com/solid/notifications-panel * License: MIT License ## Present * [Sarven Capadisli](https://csarven.ca/#i) (Chair) * elf Pavlik * Aaron Coburn * Pete Edwards * Justin B * Rahul Gupta * Ángel A --- ## 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/) * If this is your first time, welcome! please introduce yourself. ### Scribes * Aaron Coburn * elf Pavlik ### Introductions * Rahul: New here. Been using Solid, collaborated in the past with Jeff Zucker. Having some issues with the NSS impl of notifications --- ## Topics ### Updated Participation URL: https://github.com/solid/notifications-panel#participation * SC: Reminder that "[o]nline panel meetings occur monthly on the second and fourth Thursday, 14:00 UTC". We'll have to do some advanced mathematics when DST starts. Stay tuned. I'll announce an ical if necessary. * AC: JeffZucker or TallTed suggested, in addition to listing the time in UTC, having a worldclock to view the time in local time might help participation. * eP: understanding local timezone for participants might be useful to encourage people to add time in their timezonel ### Responses to Group Agreements * SC: Reminder that previous meeting minutes are available at https://github.com/solid/notifications-panel/blob/main/meetings/ * SC: Participants should first attempt to use chats and repositories to work out concerns about the minutes or group decisions before meetings. Specific responses, e.g., clarifications or objections to previous group decisions can be proposed as topics to the meeting agenda. ### Webhooks Proposal URL: https://github.com/solid/notifications-panel/pull/29 * SC: If @jaxoncreed is present, they can have the mic. Feedback from the others can follow. * SC: I prefer to hold off any decisions until Jackson is here * eP: Two things: (1) need a clear problem statement (2) motivation of specific proposal. It is important to emphasize here that the subscribing parties are also servers. The roles can be switched: the receiving and publishing roles can act as clients or servers. It would be good to be clear on those roles. * SC: There is existing terminology for this (WebSub, LDN) e.g., Sender, Receiver. The classic "server-client" arrangement doesn't work in all cases ### Notifications Protocol Repository * SC: May be preferable to move specs to their own repositories for long term. Did this with, e.g., `web-access-control-spec`, `solid-oidc`. * SC: PRE-PROPOSAL: Create `solid/solid-notifications` and move relevant issues from `solid/notifications-panel`. * eP: I think we should clarify what goes where. UCs go to panel repo and specs to spec repo. * AC: I just want to make sure that we are all aligned on timing. I know that WAC and OIDC took some time incubating in the panel. Are we moving to quickly by creating separate repository? I don't see problem with doing that, just wanted to raise the question. * SC: It shouldn't matter whether we do it now or next week. Editor's draft will need to be a GH pages document. Versioned editions will be published under the Solid specification. We can also hold off until we have an early version approved by the Panel and consider moving it at that point. * JB: what you proposed there might be the sweet spot. It incubated in the panel repo when there was the most change/discussion. We didn't have to worry about discussions/issues in the wrong repo. The only downside is when there are issues that get split because they are in different places. That said, it would be fine, but sweet spot might be keep here while everything is most active and move it later * eP: I understand the process, but we will lose the git history. What we could consider is to start with a separate repo and make use of `git sub-modules` to maintain that history * SC: git history is important, editor's draft has a provenance tracking for issues * RG: if the repos are split, will the meetings be split, too? * SC: only the spec will be split. That spec will be discussed in this meeting * AC: One reason to split it soon would be to have a consistent URL. Once we start linking to it, we know that those links will not break. With Solid-OIDC we moved it and github pages don't do well with redirects. * JB: +1 on URL consistency * SC: We are learning from experience in the different panels. We cannot have a cannonical link to the spec because we don't have a cannonical version yet. * eP: considering this conversation, it would be best to split ASAP. Either incubate it in panel or move it right away. Possibly agree in this mtg to split it now PRE-PROPOSAL: Create solid/solid-notifications and move relevant issues from solid/notifications-panel. AC: +1 eP: +1 SC: +1 PE: +1 JB: +1 AA: +1 RG: +1 ACTION: SC/AC (editors) to create repo and assign issues. Announcement will be made in gitter chat. ### Secure Web Sockets timing and implementations URL: https://github.com/solid/notifications-panel/blob/main/meetings/2021-09-23.md#secure-web-sockets-timing-and-implementations * SC: Two ACTIONs from 2021-09-23 meeting. Below as sub-topics: #### Discuss open/closed source implementation expectations * SC: Can we get a sense of the kind of implementations we can expect from panel participants? * SC: Notifications Panel Charter's Success Criteria: https://github.com/solid/process/blob/main/notifications-panel-charter.md#success-criteria * SC: >In order to advance to technical report, the specification is expected to have two independent interoperable implementations of each feature defined in the specification. Independent implementations are developed by different parties and cannot share, reuse, or be derived from code of another qualifying implementation which is directly pertinent to the implementation of this specification. * SC: Reminder that.. >Features that are not implemented due to time constraints can be put into a non-normative "roadmap" document for future work or described as "at risk". * AC: At Inrupt we will have closed source impl as described. We have version right now which is running in production with slight differences. Over the course of the winter we will align our impl with the proposal. * SC: Are we talking about server * AC: correct * JB: open source ref implementations of the interoperability spec including an "Authorization Agent" which would make use of notifications. We will be providing that implementation, but we will depend on some open source impl. We will likely be compatible with Pod Spaces, but we anticipate that CSS will also implement this * eP: to clarify: the Auth Agent would use the WebHook style; the regular application would use the WebSocket or StreamingFetch protocol. We are looking to implement both of those. * SC: I made a comment in the past about implementing an application (dokieli). We have a closed source impl that informed the draft specification. The commonality is WebSocket but not limited to that * RG: wondering if the ref client would be an open source impl? Can we see what the client is doing? * JB: The [interop impl](https://github.com/janeirodigital/sai-js) is open. The implementation may not come from this library; there may be another repository that uses this library. That repo will have these notification workflows. This isn't available at present, but once it is, there will be pointers to it. * SC: worth mentioning that we're talking about implementations of the specs; we're not just talking about libraries... real-world applications are even more important because they can address the specific use cases we have defined for this work. * JB: should have mentioned: Janeiro Digital's "transform" software (closed source) will also have implementations and use of this software * SC: 1 open library, 1 open server, 1 closed server, 1 open application * eP: to clarify: I would expect WebSockets would have JavaScript/TypeScript. For WebHook/others, I would expect more languages to implement client libraries. #### Implementations date * SC: PRE-PROPOSAL: Implementations by yyyy-mm-dd. * SC: for FPWD, we would target end of Nov for notifications protocol. How can we coordinate between implementations and spec? I'm sensing that there is code under development, and that we just keep coordinating. Two more meetings until date of FPWD, so let's use that time to check in on implementation status. This doesn't need to be a strict date for implementations, but it might be good to get a sense. Would people like a date? * AC: I'd love to see this happen immediately, for ESS early spring is realistic. * SC: we don't actually need any implementations before FPWD. It is the CR stage that needs implementations. From the Solid Protocol perspective, there is a requirement for Secure WebSockets. This is a bigger concern for those outside of this group; those project teams may have a different timeline * JB: for implementation date, for "transform" around early spring 2022. For the interop code, we are working on that jointly and that can happen sooner i.e. Q1, but that depends on the existence of an open source server (e.g., CSS). * SC: we can revisit dates later ### State of UCs URL: https://github.com/solid/notifications-panel/issues/5 * SC: "Deliver UCR by 2021-10-28" is marked as a "~FPWD" milestone on GitHub as per https://github.com/solid/notifications-panel/blob/main/meetings/2021-09-16.md . That'd be next scheduled panel meeting. * SC: [Activity Subscriptions](https://github.com/solid/notifications-panel/issues/1), [Solid-Notifications: Use cases](https://github.com/solid/notifications-panel/blob/main/proposals/solid-notifications.md#use-cases) , [Interop Panel Scenarios](https://github.com/solid/notifications-panel/issues/30) * SC: can we agree to create that document and populate it with the unique use cases from these sources. If you have comments on the UCs listed there, please queue here * SC: UCs should be really concise * RG: With the UCs, is there a set format? Specifically, how a UC is written down. Is there an expectation of pseudo-code. * SC: Simple language, one sentence ideally. * eP: w.r.t keeping UCs short. For interop UCs, there is a very specific context. It is important to keep UCs concrete and not too abstract. * SC: Who would like to create a document that describes these UCs? Start with these UCs. The UCs should not overlap. Everyone is welcome to contribute * JB: How much do we care about the format of the document for now. Is Markdown OK? * SC: Yes * JB: We can start with a PR with those that eP started with. We can review UCs as they are added * SC: to clarify, are you suggesting taking issue [#30](https://github.com/solid/notifications-panel/issues/30) and turn it into a PR? * JB: yes, there will likely be feedback that would improve that UC * SC: I'm less concerned about the source of the UCs. Are there UCs in [#30](https://github.com/solid/notifications-panel/issues/30) that are not covered in [#1](https://github.com/solid/notifications-panel/issues/1) and the other UC references * JB: will look into this offline * SC: Issue [#1](https://github.com/solid/notifications-panel/issues/1) is grounded in Solid use cases, and the UCs are simple. By next meeting can we have a draft? * eP: those [use cases](https://github.com/solid/notifications-panel/issues/1) don't take certain UCs into consideration * SC: those are detailed requirements. A supplemental document will identify the details ### Notifications Protocol Tests * SC: FPWD Secure Web Sockets spec is due by 2021-11-25 (that's an internal date/aim as opposed to charter's 2021-Q4). Are there people interested in making use of a test suite? When? * SC: Who will work on on the tests? * SC: Create `solid/solid-notifications-tests`? * SC: What should the initial tests covers, e.g., browser based? ACTION: Take it up next meeting. "Pete's: I expect to work on capability in CTH during Q1 2022 - sounds like it fits for starting to test implementations"