This issue can be used to track progress and discussion related to the notification feature within LWS.

There are several areas of prior art to consider for this feature:

• Solid WebSockets - this is a WebSocket-based model for receiving live updates to resources. This has been superseded by the Solid Notifications Protocol and the WebSocket Channel.
• Solid Notifications Protocol - this defines a protocol that clients can use to negotiate for and manage subscriptions to particular resources. The transport layer is defined by individual notification channel types, such as Streaming HTTP and WebHook.
• Fedora Notifications - this makes use of W3C Activity Streams 2.0 for message serialization. The transport layer is left to the discretion of an implementation; the reference implementation used an internal ActiveMQ broker for message processing and did not incorporate resource-level authorization into message routing and handling.

Some of the more challenging aspects of this feature will relate to authentication and authorization, and we may want to separate notifications into two categories:

• Browser-based "live updates" that make use of an active access token provided by a client
• Non-browser-based "offline updates" that use tokens that are issued by a storage server (or delegate)

An example of a live-update feature might use WebSockets, Server-Sent Events or Streaming Fetch. An "offline update" feature may use WebHooks or similar patterns.