Solid mini-series: 3. notification protocols
by Elf Pavlik
Solid Notifications Protocol and its different Notification Channel types, which are used to notify about changes in resources.
Video
Transcript
Let's continue with our example of Pumpkin Community Group and its issue tracker.
As a reminder, our standards organization provides a dedicated pod to each community group.
Each Community Group participant uses an application of their choice to access the tracker. They can also access other trackers hosted by different organizations and their personal trackers, which could even be self-hosted. Here, we will focus specifically on the data of the Pumpkin CG tracker.
We are going to follow a scenario focused on the Solid Notifications Protocol and its different Notification Channel types, which are used to notify all applications about changes in the tracker.
A streaming HTTP channel type can be used when an application, specifically its Notification Receiver, is able to maintain an open connection to the Notification Sender. A direct alternative based on the PREP draft at IETF is available. PREP stands for Per Resource Events Protocol, and Rahul, its author, prepared a dedicated short video explaining it.
WebSockets channel type is also available, which can be helpful in some scenarios.
A Webhook channel type can be used when an application, specifically its Notification Receiver, can receive HTTP requests. An LDN channel type offers an alternative with some additional features. LDN stands for Linked Data Notifications, a W3C standard produced by the Social Web Working Group.
A WebPush channel type can be used to take advantage of push notifications. This is extremely helpful on mobile devices where apps can't receive HTTP requests, and since the apps are often put in the background, they also can't maintain an open connection to the Notifications Sender.
They come with a caveat: Push Subscription requires the public key of the push sender, and service workers can only have one Push Subscription. If we create WebPush Notification Channel directly with a pod, we limit our application only to receive push notifications from that one pod. We will see how we can solve that problem by creating WebPush Notification Channels with user's SAI Agent, which in turn creates Webhook Notification Channels with all the corresponding pods.
Now, let's dive into our scenario: We start with one application, in that case Bob (Bobot), creating a Webhook channel to the pod.
Next, we have a mobile application which creates a Web push notification channel with SAI agent.
And the SAI agent creates a Webhook channel to the pod that hosts the topic resource.
A command line client which can maintain an open connection can connect to existing Streaming HTTP channel.
Similarly, a progressive web app, while it is in the foreground, can maintain an open connection and just listen to the Streaming response over the Streaming HTTP Notifications channel.
Now, let's imagine a scenario when one of the group's participant adds an issue to the Pumking Community Group tracker.
The application creates a new issue in the charter, adding a resource to the pod.
Now, following steps in practice would happen in parallel. But to explain, we will go over them one by one.
The Streaming HTTP notification channel just adds a chunk to the response.
And Progressive Web Application will receive a notification this way.
Similarly, the same will happen with the command line application.
The bot will receive a HTTP request over the Webhook channel, and can act accordingly.
For example, Bob is creating a copy of the issue since they want to have a copy of everything they are participating in.
Lastly, the SAI Agent used by the mobile application is receiving a Webhook notification.
As we can see, it has a Notifications Receiver for Webhooks and a Notifications Sender for WebPush.
Based on that Webhook notification, it will forward it over a WebPush channel to the application.
Here we should keep in mind, that there is a push service in between. Provided by the browser.
For example, Firebase by Chromium or Firefox has its own push service.
And that push service acts as the Notification Receiver, Solid Notifications end here.
From the Push Service to the application, it is a regular WebPush.
As we can see, some notification channel types are complementary, while others are alternatives. Solid Community Group is working on documenting best practices for using all the channel types that are available and defining new ones when needed.
