Skip to content

feat(notifications): LWS Notifications base specification with Webhooks#161

Open
laurensdeb wants to merge 11 commits into
mainfrom
notifications-base
Open

feat(notifications): LWS Notifications base specification with Webhooks#161
laurensdeb wants to merge 11 commits into
mainfrom
notifications-base

Conversation

@laurensdeb
Copy link
Copy Markdown
Contributor

@laurensdeb laurensdeb commented May 18, 2026

Resolves #103

This is a class 4 change to the protocol. It will need discussion and a WG vote before merging.

This PR introduces the base LWS Notifications specification, scoped to Webhook notifications only. Client-server streaming channels (WebSocket, Server-Sent Events) will be introduced in a follow-up PR (notifications-streaming) that targets this branch.

Changes:

  • Notification data model (envelope, activity properties, activity types, batching)
  • Discovery via storage description resource
  • Subscription lifecycle (request, scope, authorization, response)
  • Webhook channel: subscription, authentication (HTTP Message Signatures), delivery, management
  • Vocabulary additions

Supersedes #129.


Preview | Diff

Introduce a notifications subsystem for LWS with three channels:
Server-Sent Events, WebSocket, and Webhooks.

Key design decisions:
- Single NotificationService with subscriptionType array
- LWS-specific envelope wrapping Activity Streams 2.0 events
- phase property (post-commit) for future admission controller extensibility
- topic property for subscription targets (avoids items collision)
- Webhook authentication via HTTP Message Signatures (RFC 9421)
- inbox aligned with access-request-grant-proposal pattern

Files:
- lws10-notifications/index.html: New subspecification
- lws10-core/Discovery.html: Updated NotificationService example
- README.md: Added notifications to specs list
- Clarify MAY support / MUST advertise pattern for notifications
- Make phase OPTIONAL, use PascalCase (PostCommit)
- Remove forward references to future specifications
- Add Subscriber to terminology, use consistently throughout
- Add Subscription Scope section (recursive container subscriptions)
- Add Subscription Authorization section (delivery-time authz,
  subcontainer filtering, authorization change handling)
- Tighten object structure normatively (nested id/type requirements)
- Add authentication verification relationship per CID 1.0
- Add Activity Streams 2.0 terms to vocabulary table
- Add PostCommit as vocabulary term
- Source external terms from CID-1.0 instead of generic Security Vocab
Replace the Webhook Endpoint term with Inbox — a URL controlled by a
subscriber or other agent to which a server delivers notifications
via HTTP POST. This aligns with the inbox concept used in the
access-request-grant-proposal and makes the term reusable across
LWS subspecifications.
Reference the lws10-notifications specification with a summary of the
three notification channels (SSE, WebSocket, Webhooks) and shared data model.
Remove WebSocket and Server-Sent Event notification channels from the
base notifications specification. These client-server streaming channels
will be introduced in a separate specification.

Remove the phase property from the notification envelope and subscription
request. This concept may be re-introduced at a later point.
@laurensdeb
Copy link
Copy Markdown
Contributor Author

See Preview

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

LWS Notifications Feature

2 participants