feat(notifications): LWS Notifications base specification with Webhooks#161
Conversation
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.
|
See Preview |
|
This was discussed during the #lws meeting on 01 June 2026. View the transcriptNotifications vote #161<pchampin> w3c/lws-protocol#161 laurens: this PR replaces previous PR which introduced the base spec <gb> Pull Request 162 feat(notifications): Add WebSocket and Server-Sent Event channels (by laurensdeb) laurens: i haven't had that much feedback on those PRs <gb> Pull Request 161 feat(notifications): LWS Notifications base specification with Webhooks (by laurensdeb) elf-pavlik: if that's a direct import of the previous PR, I'm happy with it <laurens> PROPOSAL: To merge PR #161 as proposed <ericP> +1 <elf-pavlik> +1 <laurens> +1 <pchampin> +1 <acoburn> +1 <eBremer> +1 <gibsonf1> +1 <Rbreitman> +0 <termontwouter> +1 <jeswr> +1 RESOLUTION: To merge PR #161 as proposed <gb> Pull Request 161 feat(notifications): LWS Notifications base specification with Webhooks (by laurensdeb) I had conversation about streaming HTTP with Rahul in #103 <gb> Issue 103 LWS Notifications Feature (by acoburn) [work-item] |
6 participants
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:
Supersedes #129.
Preview | Diff