Present: Maria, Michiel, Mitzi (for some time), Sarven.


  1. Apply incremental changes  to CERN applications to make them Solid-compatible. Indico and CS3MESH are good candidates.
  2. Alternative approach would be for CERN to join W3C Working Groups who do Solid standardisation work. Maria wrote this proposal which includes Web Access Control (a Solid activity today). Maybe Maria to revive that proposal?...
  3. Indico  & C3MESH: Michiel drew this workflow for restricted data, when Web access control is needed via WebID. Candidate applications are Indico and C3MESH. Reasons and method (by Michiel):
    Solid is all about a three-way separation between identity, storage, and applications.
    Both CS3Mesh and Indico could benefit from exposing a storage API that Solid applications can access. The access control could be handled by a Web Access Control (WAC) proxy that sits in front of your system's data API. The Access Control Lists that drive the decisions of the WAC proxy would also be stored inside your system.
    What makes Solid Access Control Lists quite unique is that they refer to users with URIs that can live anywhere on the web, not necessarily within any particular walled garden.
  4. New CERN SSO: Michiel is interested in the new SSO internals (Maria will find a doc which requires no CERN login to access).
  5. Notifications: Sarven sent, after the meeting, the various Solid-specified notification protocols based on web sockets:
    In the Solid project, we are generally working with and looking into the interaction between different actors (servers and/or clients). It generally touches on the following protocols:
    1. Linked Data Notifications: Interaction between senders, receivers, and consumers. Sender sends to Receiver. Consumer pulls from Receiver. Part of the Solid specification.
    2. The WebSocket Protocol: Interaction between server and client. Client initiates communication. Bi-directional messaging while keeping connection open. In the process of being integrated into the Solid specification. These two protocols are not interchangeable. They address different needs. However, they can be interoperably combined to meet different scenarios. Authentication and Authorization remain orthogonal. One of the contributions of my PhD thesis is the Linked Data Notifications protocol: Have a glance at the sub-sections ( comparisons, interoperability, considerations..) as they situate LDN as part of a wider ecosystem. There is a Solid Notifications Panel: It is intended to tackle next steps - it may seem inactive but it is in our radar once we get through some of the other requirements in the Solid specification. See the use cases mentioned in this issue to get a glimpse:
      Solid is active in for anything pertaining to the Solid specifications.

    On the CERN side, Maria asked Eduardo, who inherited the notifications' project, after the meeting:

    1. for more recent status of the notifications project as this presentation  is out of date:

      Pablo Roncero has finished the first iteration implementation of the tentative notifications portal (aka the frontend), (only accessible within CERN network)

      We are now starting the investigation on backend options for the message pipeline and delivery at scale. We are a bit behind my expectations at this moment, so it's important to focus on having the prototype by summer with enough functionality to show the idea but without over complicate things.


    2. for confirmation that these are push notifications project something like this (info on service status pushed to all users, platform-agnostic):

      Indeed this use case could be also covered by the Notifications service (probably also mixed with Mattermost) I foresee indeed a set of official channels that users can subscribe to in order to receive news. These news can certainly be Service oriented ones, alarms, ... And the important difference here compared with Mail is the ability for the user to decide when and how they receive the information.

    3. Is it like (service status board - requires CERN login)?

      Certainly there are a lot of similar functionalities between both systems. Probably Notifications service will be more used for notifications, while Mattermost offers more a bi-directional communication. I think both systems should be linked and integrated together for a bigger success.

    4. Do we wish to archive the notifications content?

      Yes, I foresee users will be interested in access previous content sent through the notifications service. We foresee two levels of data. Live data kept up to X months (to be defined) to be stored directly on the backend system chosen. And archived notifications stored for long preservation on a different place (archive static web application) Probably something similar of what Emmanuel is implementing for the E-groups archive replacement for Sharepoint.

  6. Chat: Maria created on suggestion by Michiel. Reasons: We need a functional chat tool for the CERN-Solid project:
    1. Mattermost is out because it requires CERN login.
    2. One can see existing Solid chats groups on the right banner of the CERN-Solid Indico category that Maria created to facilitate newcomers to this collaboration. CERN developers may not join on-going chats. People will give time if it is inline with their own projects.
    3. Email is out, except for rare things like calling a meeting.