Add Notifications Panel Charter. Update Panels

[csarven]

Based on interest to re-open the Notifications Panel in the W3C Solid CG ( #258 , https://github.com/solid/notifications-panel/ ), the following is a proposed charter that amends the original proposal: #116 , solid/data-interoperability-panel#13 (comment) .

Document status: Draft.
Proposed Teleconference: Recurring weekly, Thursdays at 14:00 UTC.

[kjetilk]

Sounds good, but I feel that one aspect could be mentioned. There was a sense of urgency behind https://github.com/solid/specification/issues/289 in which the issue was constrained to an upgrade of the WebSockets protocol to secure it. This made it to the Solid Editor's milestone because it was urgent and should be resolved within a couple of weeks.

I certainly recognize that a longer term work is needed in this area and that a very short focus can lead to long term problems. However, given the urgency recognized by the Solid Editors, I think it should be within the Panel's scope to find an upgrade path from the current deprecated insecure WebSockets, via a secured upgrade of WebSockets and to the broad Notifications API design, so that the secured solution can be deployed very soon.

[justinwb]

This made it to the Solid Editor's milestone because it was urgent and should be resolved within a couple of weeks.

My concern with this approach is that we're going to end up with something that is rushed, that needs to be replaced later, and that implementors may not support as a result. Personally, I'd rather see us focus in this panel on drafting, implementing, and testing something we can live with for a while in a timely, deliberate, and focused way - with active engagement from implementors.

[acoburn]

How is "Notification Protocol" being distinguished from "Notification API"? I would think that this group would define a "Notification Protocol" while a conforming implementation might deliver a "Notification API".

[csarven]

Originally intended to include the possibility of defining or extending APIs such as ActivityPub that describes client-server and server-server interactions. (Aside: a by-product of that work may partly address solid/specification#36 ).

I have pushed an update that removes "API". Updated/generalised the "Protocol" so that it could cover different specs - I don't expect it to be only about discovery and negotiation. Unless people want a tighter scope in the charter, I suggest that we leave it up to the Panel figure out the actual specs that's needed e.g., informed by use cases and open implementations.

[csarven]

I've updated the charter so that documenting catch-all "upgrade path" is while in scope, it may not be normative material. As for the work/discussion on WebSockets... it needs to be done somewhere - doesn't strictly matter where - by people interested in solving the problem. If people that want to address the challenge can't solve it without a panel, then that's completely fine. The issues on WebSockets have been around for ages, new ones are created/discussed, ... and since it is still not solved, that may be a good enough reason to do it through a panel. I suppose somehow a recurring (weekly?) call is what's really needed because everything else literally remains the same.

[emmettownsend]

What does this mean?
'in scope' but 'will not lead to a recommendation' ?

[csarven]

At this moment it is not clear if/what and to what detail we need to document upgrade paths. The only thing that's being roughly discussed is WebSockets but there can be other works. So we acknowledge that there are some works that's relevant to the CG/panel we can consider putting effort into - within "reason" - but what comes out of it may not be a normative document, like a spec. It could just be "Notes" / guidance to developers.

[emmettownsend]

Does this mean it cannot proceed if there are not two open source implementations?
What if there is one open and one closed?
For example ESS will have a closed source server implementation with open source client libraries.
CSS will likely have an open source server implementation.
Then a server like Trinpod could have another closed source implementation.
Does this mean there would still not be enough implementations to advance to technical report?

[csarven]

In order to publish a ~CR, the visibility of code plays a role in verifying and demonstrating adequate implementation experience of the work items towards an open standard.

I've pushed a commit replacing "open source" with "interoperable". While they have completely different meaning, it relaxes the requirement. Two implementations is a very low bar, and I would advise strongly against changing that. I'd propose even increasing that number especially if the CG is concerned about ensuring open source implementation experience for an open standard.

A closed source implementation could use open source code, and as far as I know, there is no reasonable way for the CG/public to catch that. Hence, it doesn't help towards showing maturity or wide use.

The specs can be informed by all (open and closed source) implementations nevertheless. "open source" is intended to keep one foot on... solid ground.

A full-blown Solid server is not required, or even a Solid server per se. What's assessed is whether "each feature defined in the specification" is implemented. What's not implemented gets reviewed by the panel e.g., to a consider whether an unimplemented feature should be removed from the spec or not.

[emmettownsend]

Should it specify that the specs need to contain rdf to enable test cases to link to the spec?

[csarven]

Good question. I think that level of detail need not be in the charter, but if people would like to, happy to add that in. I was planning on making very loud noises about it any way :) We have over arching issues such as solid/specification#6 ..

[emmettownsend]

What is the expectation of 10 or more participants is not met?
If this paragraph has no consequence then how is it relevant?
I agree the chair and editors need to contribute 1 to 2 days per week. That means we need to properly assess the time available for all that are nominated as chair?

[csarven]

Say 1 chair, 4 editors/authors, 1 test suiter, 4 implementers = 10.

I have no issue to remove this paragraph. It is there as an expectation for its success, but you're right about consequences. If there isn't sufficient activity / contributions, we don't meet our goal. There are dips in the course of the panel. Different contributors are more or less engaged at different times.

Noting that solid/process currently says at least 5 "members" - not even "participants" or "contributors"! But again, that number can be anything. As per process, we could have 5 or 500 people as members and zero can show up. It wouldn't matter if the charter said 1, 5, or 500. The point is if there aren't x number of people engaging in the panel, there is no need to have a panel.

[emmettownsend]

Should the charter also describe the weekly session on managing progress?

[csarven]

I think that's also low level detail for a charter. Weekly sessions are while common, it is not required. It could be monthly or whenever there are enough number of participants interested in the agenda - people need to RSVP. We can use GitHub to help us manage/track progress.

[emmettownsend]

"...consensus emerges with little formal voting being required". Is there a time limit to this? How do you prevent it going on indefinitely or for an unreasonable amount of time?

".....for voting within the group and record a decision". Do you need to specify how that vote works e.g. majority? does chair have veto? does chair decide if its 50/50? etc. In other words making sure its clear and decisions can be made.

[csarven]

First: voting is typically used to either re-check where we are on consensus (=straw poll) when new information is presented or as a last resort (=majority vote) when we can't reach (rough) consensus by other means e.g., objections are recorded and discussed, and if the issue is still unresolved (=commenter unsatisfied) in order to progress. The time limit is not fixed but we'll aim to resolve such issues within one meeting when all required participants are present. If still unresolved or there is an objection from a participant in a follow-up meeting when we are approving the prior meeting's minutes (in which the discussion or voting took place), they can present their case. Progress can't be blocked. Yes, the limit is determined by chair at some point in that they'll assess the situation, keep discussion DRY and focused, facilitate reaching consensus. If 50/50 (or even 51/49), then there definitely needs more discussion, demonstration of (open) implementation experience, using own tools, consider alternative proposals with less or weakest objections, implementation complexity, weigh participants' affiliations, break down the issue into smaller parts and re-vote to assess consensus... There is no one-size fits all factor when to wrap-up or what a representative majority may be. Depends on the issue and significance within a reasonable amount of time.

[timbl]

The Solid Protocol has included WebSocket-based live update for a long time. It is core to the functionality of the platform. Therefore, the solid spec must at all times define how the live update works.

Now a change from "Web Sockets" to "Secure Web Sockets" version has been forced by the security problems with the original protocol -- that the connection was not authenticated. There was agreement to move forward rapidly with this change. Here are some ways of going this.

1. Abandon the insecure version and immediately upgrade all code to the secure one , with a security-scramble urgency to get the new code (which involves adding a token somewhere in the web socket data or the URI of the web socket). Pick the first design a small group comes up with which looks good. Update NSS and CSS and ESS to the new spec. Add it to the test suite, add it to the spec. Release the spec Solid 1.0. Allow future notification architectures to evolve in good time, and later move to them in later releases.
2. Preserve the insecure version in the spec, and in NSS and CSS and ESS until the pane has come up with a well-thought out new design. Immediately release Solid 0.9 with insecure web sockets. Allow the panel time come up with a generic architecture and release Solid 1.0 with secure web sockets in due course.

I thought we were doing 1. That would mean that if we use the interop panel it should be authorized to work on the security fix only over the next few weeks and not work on any more generic deigns until that secure fix is out and Solid 1.0 contains it
(The Solid version numbers here used to illustrate these alternatives are a bit arbitrary as we do not have a released series of them yet)

[csarven]

I thought we were doing 1.

Right, that is the consensus reached by the Editors team, and an issue that we agreed to follow-up on: https://github.com/solid/specification/issues/289 .

It had no dependency on the notifications-panel.

I've proposed to re-open the panel because of other initiatives bubbling up in parallel and emphasised numerous times that it should not interfere with the priority and progress on Secure Web Sockets as we've originally agreed. As mentioned in #264 (comment) , if contributors want to resolve that through the notifications-panel (because they can't without it), so be it. The key thing being whether that's a "few weeks" or possibly end of 2021-Q4 (as per notifications-panel Charter) but as part of a broader design based on informal feedback.

[csarven]

All, please vote on the following straw-poll with -1, 0, +1. Optional: indicate reason for the vote. This is to get a sense on whether the notifications-panel actually takes on this work and can meet the goal. We can re-run the proposal (or a variation) in the notifications-panel to be "official" (FWIW) but I suspect that by that point we are all on the same page.

PROPOSAL: The notifications-panel works on the delivery of Secure Web Sockets by 2021-10-13.

[kjetilk]

I would have said +1, but since I will not be a part of this effort, I should say 0.

[justinwb]

PROPOSAL: The notifications-panel works on the delivery of Secure Web Sockets by 2021-10-13.

-1: my reason being unchanged from my previous response to essentially the same proposal (pasted again for convenience):

My concern with this approach is that we're going to end up with something that is rushed, that needs to be replaced later, and that implementors may not support as a result. Personally, I'd rather see us focus in this panel on drafting, implementing, and testing something we can live with for a while in a timely, deliberate, and focused way - with active engagement from implementors.

[RubenVerborgh]

I second @justinwb's objection. We cannot be expected to rush this.

[acoburn]

-1: I agree with @justinwb's comment

[csarven]

Based on my observation, we haven't been rushing - in fact we had all the time in the world - but I can understand why a proposal to have it done in a month can suddenly come across that way within the context of the panel. No one interested in getting WebSockets going properly came up and said they needed a panel for it either. My concern with the "rush" framing is that it is a gateway language to "let's solve everything related altogether from scratch" instead of isolating and focusing on the primary thing that we need the most. I don't mean to oversimplify the technical problems and hard work ahead but we've been down that road several times whether it is specs or implementations. Any way, I do have (some) faith in consensus and in those that make things. I have no strong preference on timing but it'd be great to have Solid "finished" before retirement :P

[csarven]

🔔 This charter in fact marks the second year anniversary of the initial proposal to open the notifications-panel. Let's make it so!

Please share any additional feedback or concerns about the charter in the panel: https://github.com/solid/notifications-panel . Changes to the charter will be followed up in this solid/process repository.