Discovery of Notification Subscription Metadata

[csarven]

The Notifications Protocol currently does not describe the discovery of the Notification Subscription Metadata Resource.

This issue is a follow-up on the discussion at #54 . Some options are mentioned there in addition to our earlier consideration to use Server/Storage Metadata: solid/specification#355

[csarven]

Some considerations:

To clarify, solid/specification#355 is of interest in the context of discovery of notification channels that's available for a given resource starts from a resource of interest, finds the storage the resource is included in, and that the resource server provides channel information for all of its resources in the storage description (wherever that's exactly materialised) - where the resource of interest for notifications will be covered by.

While that may be sufficient for most use - and completely okay to just stop there - it is worthwhile to clarify here whether Notifications Protocol should describe how any resource can advertise its own notification channels. So not all resources in the same storage will necessarily use the same channel e.g., a particular container or non-container resource could call its own. I don't have a strong use cases in mind for this but then again it is more intuitive than the channels being offered for all resources in a storage. The fact that we are talking about storage-level channels is only because of Solid Protocol and the concept of 'storage' existing. Whether the concept of 'storage' is fundamental to Notifications Protocol is yet another question. In practical terms, can/should the Notifications Protocol be usable alongside protocols besides Solid Protocol? (I'd love it to be the case if we can make it so.)

There is some consensus on providing the mechanism to discover storage description - from the perspective of Editors Team 2022-06-08 meeting. We'll work out some of the finer details in issue 355 and followup.

On a related note, the discovery of a resource's ACL resources, using acl link relation, is defined in the WAC spec, as opposed to the Solid Protocol. So, again, the question of whether Notifications Protocol should describe its own discovery for notification channels.

I can also see it being fine for the Notifications Protocol to only specify what the channel description should be and leave out its discovery to other protocols to specify.

[uvdsl]

re: Should a resource be able to advertise a non-storage-bound notification channel?

As an example use-case, let's say that there is a storage A that does support LDNs and Websockets but does not support Web Push notifications. And on storage S there lives a resource r. A user would like to receive Web Push notifications on that resource. (Web Push just for the sake of the argument, you can also have some other notification type that is not supported by storage S) But since the storage does not support Web Push, some other service is needed.

Let's further say there is an external notification service SN (provided by me, uvdsl) that has a Solid WebID and thus can be granted access to resource r. The SN can then subscribe using some available scheme and act as a proxy to forward Web Push notifications to the user.

Is this a common use-case? Probably not.
Would I like the flexibility of the approach? Yes, please. Even if many people do not use it.

Solution idea support:
The storage description approach for discovering notification channels is fine for me as the minimum standard.
However, I would like to add that a resource MAY CHOOSE to advertise (additional) channels in a resource-specific manner.
Similar to .acl, where a resource does not have to have a corresponding .acl since it inherits its access control from any parent resource. But if some specific ACL is to be set in place, the resource can advertise it. But per default, there is no specific .acl.
Similarly, I imagine this for notifications, where per default its just storage description, but if needed a, e.g., .notify or similar can be defined. Or even in the meta data via described by?
So, I would also be in favor of this approach.

[csarven]

Only one mechanism is needed for achieve minimal interop, but to be clear, different cases can be covered by the following:

• Storage wide: solid:storageDescription is useful towards storage level (all resources in a storage can rely on it) channel information.
• Resource specific: describedby is useful towards resource specific channel information.

The Solid Protocol describes description resources: https://solidproject.org/ED/protocol#auxiliary-resources-description-resource . It does not require servers to include the Link relation in the response of a subject resource, but it explains how clients can discover it.

From the perspective of the Notifications Protocol, I suggest that we do something similar in that the specification describes how clients can look for either one of the Link relations, i.e., storage wide or resource specific, when they want to find out about a resource's notification channel information.

In addition, it could (non-?)normatively state that when both relations are available, the client should use the resource specific one for channel information -- It may not be necessary to state this but it does answer a question for implementers about what they should do when they encounter, so it is generally useful.

[michielbdejong]

Hm, I think the current text is not entirely clear. Both paragraphs start with "When a server wants to" and then later contain a "MUST". So you MUST, but only if you want to? Isn't that better described with a "MAY", maybe?

Suppose that as an implementer, I read this spec to know what I should implement.

• Is my server required to enable applications to discover Notification Channels available to a given resource using the resource-specific Link response header?
• Is my server required to enable applications to discover Notification Channels available to a storage in which a given resource is in using the storage-wide Link response header?

The spec says that a server "MUST" do each of those "When [it] wants to", in other words, it leaves it open whether a server does one or the other, or both, or neither of them.

I would add that a server MUST support at least one of them. Otherwise discovery is pretty much impossible, I think.

[csarven]

Solid Protocol ED as of this writing requires the mechanism to discover storageDescription from a resource.

I suggest that as long as that's still part of the Solid Protocol ED, the Notification Protocol can continue to rely on it being available, with the understanding that it will be part of the next release of the Solid Protocol. We'll update the Notifications Protocol ED to clarify the requirement - as noted above and elsewhere re "when a server wants to" - and move towards publishing the next release of Notifications Protocol. If the Solid Protocol drops storageDescription, Notifications Protocol can drop it too.

Over the course of the Solid Protocol and Notifications Protocol, we'll gain implementation experience and go from there about what to do with these features.

So for now, this issue can be closed because it was already addressed by #104 . We will immediately follow-up with an editorial update to clarify the conformance requirement.

Any objections?