Solid StreamingHTTPChannel2023

1. Introduction

This section is non-normative.

The [Solid.Notifications.Protocol] describes a general pattern by which agents can be notified when a Solid Resource changes. In the context of a Web Browser, the Streaming HTTP Channel provides a convenient mechanism for a Solid Storage to alert a subscribing client of these changes.

This document describes a Solid Notifications channel type that makes use of the Fetch API.

This specification is for:

• Resource server developers who wish to enable clients to listen for updates to particular resources.

• Application developers who wish to implement a client to listen for updates to particular resources.

1.1. Terminology

This section is non-normative.

This specification uses terms from the [Solid.Notifications.Protocol] specification. When Solid Notifications Protocol terminology is used it is linked directly to that specification.

2. StreamingHTTPChannel2023 Type

This specification defines the StreamingHTTPChannel2023 type for use with Solid Notifications channels. that use the Fetch API.

An StreamingHTTPChannel2023 MUST conform to the Solid Notifications Protocol.

An StreamingHTTPChannel2023 SHOULD support the Solid Notifications Features.

The StreamingHTTPChannel2023 type further constrains following properties properties:

receiveFrom

The receiveFrom property is used in the body of the subscription response. The value of source property MUST be a URI, using the https scheme.

A client establishes a subscription using the StreamingHTTPChannel2023 type by sending an authenticated subscription request to the Subscription Resource retrieved via Solid Notifications discovery.

For StreamingHTTPChannel2023 interactions, the client sends a JSON-LD payload to the appropriate Subscription Resource via POST. The only required fields in this interaction are type and topic. The type field MUST contain the type of channel being requested: StreamingHTTPChannel2023 The topic field MUST contain the URL of the resource a client wishes to subscribe to changes.

2.1. Subscription Example

This section is non-normative.

An example POST request using a DPoP bound access token is below:

POST /subscription
Authorization: DPoP <token>
DPoP: <proof>
Content-Type: application/ld+json

{
  "@context": ["https://www.w3.org/ns/solid/notification/v1"],
  "type": "StreamingHTTPChannel2023",
  "topic": "https://storage.example/resource",
  "state": "opaque-state",
  "endAt": "2023-12-23T12:37:15Z",
  "rate": "PT10s"
}

POST request including type and topic targeting the Notification Subscription Resource.

A successful response will contain a URL to the subscription Resource that can be used directly with a JavaScript client.

Content-Type: application/ld+json

{
  "@context": "https://www.w3.org/ns/solid/notification/v1",
  "type": "StreamingHTTPChannel2023",
  "receiveFrom": "https://fetch.example/aca3cb0a-fb0a-4091-b9f8-8117d2cdb392"
}

Response to the POST request, including channel type and the receiveFrom URL.

In JavaScript, a client can use the data in the response to establish a connection to the Fetch API. And define how to handle notifications

const response = await fetch('https://fetch.example/aca3cb0a-fb0a-4091-b9f8-8117d2cdb392')
const textStream = response.body.pipeThrough(new TextDecoderStream());
for await (const notificationText of textStream) {
  parseAndHandle(notificationText)
}

3. Authentication and Authorization

Streaming HTTP Channel has the advantage of being able to authenticate with the Subscription Resource as well as the notifications receiveFrom. The same access token can be used with both resources. This doesn’t just rely on the notifications source being a Capability URL as many other channel types do.

As described by the Solid Notifications Protocol section on Authorization, the Streaming HTTP Channel requires authorization and follows the guidance of the Solid Protocol sections on Authentication and Authorization [Solid.Protocol].

It is beyond the scope of this document to describe how a client fetches an access token. Solid-OIDC is one example of an authentication mechanism that could be used with Solid Notifications [Solid.OIDC].