# Solid Editorial Session

## Present

- Justin B
- Dmitri Z
- Kjetil K
- Sarven C
- TimBL

## Agenda

* Where to store minutes
* Weekly time
* Notifications panel revival
* Current month milestone

## Minutes

### Where to store minutes

JB: Can we agree on a place to store minutes

TBL: Can we host on solidcommunity.net?

SC: There is https://specs.solidcommunity.net/ (currently used for WAC ED inboxb)

JB: If we keep specs and minutes close to eachother (e.g. github), use PR on solid/specification/meetings/ but then automatically publish to sp.org (along with spec), and if sp.org runs off of solid, then we can accomplish both together? SC +1 TBL +1

SC: Ensure that the meeting minutes do not substantively change the discussion - only to ensure that they are accurate of exactly of what was discussed. JB +1, TBL +1

https://gitter.im/solid/specification?at=609265f3f7e4221825bae33d

### Weekly Time

JB: Moving forward I will have some issues with this time slot, and also Dmitri has issues as it stands. Propose to find a new slot that works for everyone if thats OK? TBL +1, KK +1, Sarven +1, Dmitri +1

### Issue Review

KK: Notifications panel restart and two issues related to container descriptions. Also open a nomination period where community can bring their issues to bear.

TBL: Need to ensure that secure websockets is prioritized

### Notifications

JB: Notifications panel restart *ideally* will allow us to resolve the shortfall in websockets with a design that we can live with long-term - since we're gotten implementors to commit to participate and work in conjunction on the draft + supporting implementations (client and server side).

SC: Need to ensure that there is viable upgrade path

TBL: Should be sure to look at the solution that has been provided and shared from inrupt at https://github.com/solid/specification/blob/feature/notification-protocol-data-flows/notification-protocol-data-flows.md

SC: Does it patch things up or replace them

TBL: It is a change and reimplementation. I am OK with that.

SC: Are you OK with the design / architecture as proposed

TBL: Fastest way to a good resolution is to use the changed / proposed protocol

KK: I believe that we can move this from our monthly editorial panel and pick it up when the panel returns it in Q4 - +1 JB

SC: Doesn't matter to me where it is taken up.. but whether it needs to wait for a complete solution (eg. discovery+negotiation+syntax/model) resolved before we have the prioritised secure websockets..

### Current Month Milestone

Regarding: [Current Month Milestone](https://github.com/solid/specification/projects/1?card_filter_query=milestone%3A%22current+month%22)

#### [Specify Container Description](https://github.com/solid/specification/issues/227)

KK: https://github.com/solid/specification/issue/227
SC: https://github.com/solid/specification/pull/228 . Currently in Protocol:
>Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.

Follow up issue in NSS:
https://github.com/solid/node-solid-server/issues/1567

JB: There are a lot of paths to provide efficiency and optimization, but you cannot un-expose data once you've exposed it. I think the protocol should only provide containment triples, and then we can separately look at ways to make access to metadata for resources more efficient.

SC: Protocol should only provide containment triples

KK: Provide in the issue the reasoning that containment triples should not provide any information that would require any permissions on the resource

## Action Items

- Add meetings/ under solid/specification and move historical hackmds there (JB)
- Find a weekly recurring time that works for all editors due to constraints from Justin and Dmitri (JB)
- Await submission from notifications panel to resolve websocket gap
- Follow up discussion #227