[UC] Update Notifications

[CxRes]

status: DRAFT

As a user
I want to be able to receive real-time notifications
So that the information I see is always up-to-date

This is not a use-case, but a pattern that spans a family of use-cases.

This use pattern is also necessary infrastructure for real-time collaborative technologies such as CRDT/OTs and Local-First.

Preconditions:

What conditions must be in place or assumed before this use case can begin?

• A User is able to write data to some resource store.
• At least one user is able to read data from said resource.

Trigger:

What (user or system) event or action initiates this use case?

A client subscribing for notifications. Thereafter, any operation that modifies the state of the resource.

Actors:

Describe the primary actor, and any other relevant actors involved in this use case.

Resource Server: A server that hosts the resource to be sent.
Discovery Client: A client that discovers a resource's capability to send notifications.
Subscription Server: A server that processes subscription requests.
Subscription Client: A client that subscribes to receive notifications.
Notification Sender: The sender of a notification.
Notification Receiver: A recipient of a notification.

Distinction in roles are made explicit for the most general case. Roles on the server and on the client respectively may be combined within a single agent.

Distinction:

What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case?

Notification Negotiation

Updates can take various forms:

1. A notification indicating an update.
2. Actual changes to the resource.
3. Some processed subset of change to a resource (say, a friend request).

This means that we need to be able to support a wide variety of notification formats through a mechanism equivalent to content negotiation, which authors (those with write permissions) should be able to configure. Solid Notifications Protocol and PREP/Solid-PREP, the two notification protocols developed within the Solid Community, are the only ones that support this feature.

Access Control

Updates like fetches are subject to access control. Except in the case of notifications, access control might change when the subscription is still active. The implication here is that changes to access control must be designed in a manner that they need not be rechecked every time a notification needs to be sent, for the sake of efficiency and scalability. Instead, changes to access control to the resource should be propagated to its notification middleware.

Scenario:

Describe an ideal or happy-case scenario where this use case would play out as intended.

WIP

Alternative case(s):

What alternative flows or variations should the system handle for this use case?

Multiple protocols are available that can carry notifications, each meant to serve a different scenario. Ideally, LWS should support notifications for these diverse circumstances. Solid Notification Protocol already serves this with the use of channels.

Error scenario:

What unexpected issues or errors might arise, and how should the system handle them?

WIP

Acceptance Criteria:

What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable?

• Users are able to request notifications.
• Servers are able to send notifications in response to user request.

References:

List any relevant resources or examples that could inform this use case, possibly from other domains or solutions.

Solid Notification Protocol
Per Resource Events
Solid-PREP