feat(notifications): Add WebSocket and Server-Sent Event channels#162
feat(notifications): Add WebSocket and Server-Sent Event channels#162laurensdeb wants to merge 14 commits into
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.
Introduce client-server streaming notification channels: - WebSocket: persistent bidirectional connection for real-time events - Server-Sent Events (EventSource): persistent HTTP stream for real-time events Both channels use capability URLs for connection establishment and share the common notification envelope defined in the base specification.
|
See preview |
|
@laurensdeb I think this one needs a rebase |
|
I see three main options here, two of them are included in this PR
Each one comes with some trade-offs. One of main limiting factor is how currently subscription is defined in https://w3c.github.io/lws-protocol/lws10-notifications/#subscriptions Websockets👍
👎
SSE👍
👎
Streaming HTTP👍
👎
With Streaming HTTP I only implemented streams with a single topic via GET, where URL can be discovered via link header and it doesn't use subscription step thanks to @CxRes has more experience with |
|
FYI, for those who might be insisting to live in the stone ages: |
The above is offensive in several ways. Please adjust your tone to be more positive and more appropriate for collaborative efforts among peers. |
|
@TallTed Thanks for your comment. But I stand by the essence of what I have said. Take it as my little act of rebellion! I am not sure if you are aware of the disruption, false complaints and censorship that I have had to face in Solid community over my constructive suggestions to merely evaluate QUERY when it was progressing through IETF (and this has held back CG progress for 1+ years). I have taken the matter to W3C Advisory Board, to the Solid Ombuds and TimBL himself privately, with no remedial action. The evidence that I have submitted is unequivocal and undeniable. The then W3C Advisory Board member concerned expressed their own frustration with W3C publicly on GitHub. It seems to me that certain sections of the Solid ecosystem are allowed to be offended (and I am not speaking of you) and others are to put a finger on our lips when attempting to engage constructively and exhausting all options. I received snarky comments just last week but have kept quiet. This is the truth and many Solid participants (including multiple former CG chairs and TAG members amongst others) will confirm this to you privately. As a community elder, I have respect for you. But I have done a lot for the Solid community as well. It is easy for you to issue selective reprimand for tone without context from your position of privilege, without recognizing the helplessness of people who have been at the receiving end of unethical and CoC violative actions that only serves to crush the spirit of genuine contributors (and I am not even an LWS contributor, but I keep getting pinged for contributions that afaict the community as a whole has never had genuine interest in considering, even when it is already being adopted in other spaces). The rules must be applied with equity and not just equality. Feel free to act against me if you must, it will only re-enforce the double standards that exist in the W3C. At least do me the courtesy of asking around before reprimanding me again. I would prefer not to argue with you, so I am bowing out of this discussion! |
|
I added link to RFC 10008: The HTTP QUERY Method at the end of my comment. To stay focused on the technical matter of this draft PR I would like to suggest that the last three comments, and mine comment here are all marked as off-topic. Let's keep in mind that hopefully more people will review this PR and contribute to the proposed feature. |
|
@CxRes in your example https://cxres.github.io/eq-ld/protocol/#example I also understand that this approach is intended to have one response per topic and doesn't try to have streams that aggregate notifications for multiple topics? To be clear I also implemented it this way in CSS for Solid StreamingHTTP channels. |
|
@BigBlueHat @bjdmeest Do you think LWS could reuse some of this work for steams of notifications?
|
5 participants
This is a class 4 change to the protocol. It will need discussion and a WG vote before merging.
This PR adds client-server streaming notification channels on top of the base notifications specification (#161):
Both channels use capability URLs for connection establishment and share the common notification envelope defined in the base specification.
Depends on #161
Preview | Diff