Quick Notifications

[CxRes]

Solid Quick Notifications is a proposal to use Accept-Events and Events header fields that I invented in PREP to allow Clients to negotiate subscriptions i.e. request a notification channel, using a mechanism identical to content negotiation in HTTP. With this one can request a notification channel in a single request, and given that a client will anyway start with a GET request to the topic, the subscription step is effectively free when using proactive negotiation. While not as efficient as PREP over a single topic, this would outperform it when requesting notifications for multiple topic resources.

For public channels, I am proposing to introduce a Notification-Channels header field to, well, advertise the channels.

I believe this proposal solves all the issues raised by @timbl in #110 as well as the concern he raised in the notification panel meeting on 12-01-2023 while remaining completely backwards compatible (apart from an extremely minor caveat) with Solid Notifications. One can even use it alongside the existing specification, providing clients a choice of mechanisms for discovery and subscription of notifications.

Updated HTML Preview | Diff with main branch | Diff with backported changes to SNP

[csarven]

Just a Quick Comment for now. Will leave a separate thorough review later once I understand the technicals. High level:

If possible, I'd much rather see how this work can either get incorporated into the current Solid Notifications Protocol or made possible to only extend it. If Solid Notifications Protocol doesn't make it clear how extension could occur, we can improve on that. Essentially, this kind of work should stand on its own as opposed to a "derived from" type of thing.

[CxRes]

@csarven This is to start a conversation. My long term suggestion (especially if such a work can get funded), is to reorganize Solid Notifications in a number of specifications:

• Solid Notifications: Discovery and Subscription
• Solid Notifications: Quick Discovery and Notifications
• Solid Notifications: Channels
• Solid Notifications: < Channel Type >
• Solid Notifications: Messages for RDF resources
• Solid Notifications: Messages for < content-type or content category >

Really, the bulk of work has to be done in the last two! It also makes it easier for someone entering Solid Notifications to work with more palatable chunks! This might be a good opportunity to rebrand as well, Since these notifications can easily be used outside Solid.

[elf-pavlik]

404 I would suggest to add that link once it gets published

[CxRes]

My intention was that when the PR gets accepted, it will be created.

Happy to comment it out if it is a problem...

[elf-pavlik]

Since this is an edit to the current notifications protocol document, I will need to go through the diff

[CxRes]

Use the diff I have created in the first comment. That compares with the latest SNP version!

[csarven]

w3c/htmldiff-ui#12

[csarven]

Can we take this up in an STM? I'd like to understand better whether this should be incorporated into SNP or being proposed as a new work item or what...

.. In addition to noting any early commitments for implementation.

[CxRes]

First and foremost, I would like for the reviewers to verify if my proposal is functionally correct!

We can decide then how to proceed, an extension, an independent work item or re-organization of notification specs. I think all three are viable, but it is really a question of resources and participation.

I would like an STM as well, perhaps after a first round of reviews!

[TallTed]

It's a start...

[TallTed]

Suggested change

	<li><code>Solid</code> as a List Item [<cite><a class="bibref" href="#bib-sf">STRUCTURED-FIELDS</a></cite>], and</li>
	<li>parameters of <a href="#notification-channel">notification channel</a> set according to the <a href="#notification-channel-data-model" rel="rdfs:seeAlso">Notification Channel Data Model</a>.</li>
	<li><code>Solid</code> as a List Item [<cite><a class="bibref" href="#bib-sf">STRUCTURED-FIELDS</a></cite>]</li>
	<li>parameters of <a href="#notification-channel">notification channel</a> set according to the <a href="#notification-channel-data-model" rel="rdfs:seeAlso">Notification Channel Data Model</a></li>

[CxRes]

Will revisit <li> punctuation later. My preferences are clearly inconsistent with the document!

[CxRes]

@TallTed Great Start!!! Thanks for detailed review. I have accepted (and backported) most of your suggestions. The only changes that I have not accepted have to do with <li> punctuation, which I will revisit later.

@csarven Can you please look at Conformance section suggestions made by Ted (since these are really fixes to SNP). If you agree, I will merge them in and backport them to protocol.html.

[TallTed]

Suggested change

	<figcaption property="schema:name">Solid Notifications Flow Receive From, where the a receiver establishes connection to a sender.</figcaption>
	<figcaption property="schema:name">Solid Notifications Flow Receive From, where a receiver establishes connection to a sender.</figcaption>

[TallTed]

or ...

Suggested change

	<figcaption property="schema:name">Solid Notifications Flow Receive From, where the a receiver establishes connection to a sender.</figcaption>
	<figcaption property="schema:name">Solid Notifications Flow Receive From, where the receiver establishes connection to a sender.</figcaption>

[TallTed]

should probably match line 459, a or the

Suggested change

	<figcaption property="schema:name">Solid Notifications Flow Send To, where the sender delivers notifications to a receiver.</figcaption>
	<figcaption property="schema:name">Solid Notifications Flow Send To, where a sender delivers notifications to a receiver.</figcaption>

[TallTed]

Suggested change

<p id="authentication-authorization">This specification does not require a specific authentication and/or authorization mechanisms to be used with the Solid Notification Protocol. Implementations are encouraged to use existing approaches, such as those described in the Solid Protocol sections on <cite><a href="https://solidproject.org/TR/protocol#authentication" rel="cito:discusses">Authentication</a></cite> and <cite><a href="https://solidproject.org/TR/protocol#authorization" rel="cito:discusses">Authorization</a></cite> [<cite><a class="bibref" href="#bib-solid-protocol">SOLID-PROTOCOL</a></cite>].</p>

<p id="authentication-authorization">This specification does not require a specific authentication and/or authorization mechanism to be used with the Solid Notification Protocol. Implementations are encouraged to use existing approaches, such as those described in the Solid Protocol sections on <cite><a href="https://solidproject.org/TR/protocol#authentication" rel="cito:discusses">Authentication</a></cite> and <cite><a href="https://solidproject.org/TR/protocol#authorization" rel="cito:discusses">Authorization</a></cite> [<cite><a class="bibref" href="#bib-solid-protocol">SOLID-PROTOCOL</a></cite>].</p>

[TallTed]

Again, should match earlier. I think a is better than the, throughout.

Suggested change

	<figcaption property="schema:name">Solid Quick Notifications Flow Receive From, where the receiver establishes a connection to a sender.</figcaption>
	<figcaption property="schema:name">Solid Quick Notifications Flow Receive From, where a receiver establishes a connection to a sender.</figcaption>

[TallTed]

Again...

Suggested change

	<figcaption property="schema:name">Solid Quick Notifications Flow Send To, where the sender delivers notifications to a receiver.</figcaption>
	<figcaption property="schema:name">Solid Quick Notifications Flow Send To, where a sender delivers notifications to a receiver.</figcaption>

[CxRes]

@TallTed Thanks again! These batch of changes I was (mostly) aware of, but did not make them because they apply to the main protocol itself!

Having said that, I will accept them and backport them to SNP (sometime, next week, though).

[elf-pavlik]

Given PREP and PREP-Solid, do you still plan to pursuit this proposal?

[CxRes]

Why not? The basic concept is still good...