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

[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.

[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!

[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.

[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...