csarven
commented
1 year ago I wrote something along these lines elsewhere. Pardon me for not finding the URL for it (yet).
The short answer is no, clients can't "control" it. Yes, the ResourceServer already has "exclusive control over notifications discovery."
The Solid Notifications Protocol neither prescribes the behaviour for a product to update the description resource or the ResourceServer to accept update requests targeting the description resource. Entirely undefined / out of spec behaviour.
As far as conformance to Solid Notifications Protocol is concerned, the only thing that's prescribed is the ResourceServer behaviour to provide a representation for a description resource using the description resource data model. The ResourceServer is not even required to be aware of/understand/generate anything besides the description resource data model.
While it may be possible for different products to produce separate portions of the payload for the description resource, it is still entirely up to the ResourceServer to materialise the description resource data model - authoritatively making the final call.
Put differently, while one product from another specification (e.g., Solid Protocol's Server) may accept update requests targeting the description resource using the description resource data model in its payload from another product (e.g., Solid Protocol's Client), the Solid Notifications Protocol's ResourceServer has the foremost responsibility to govern and generate the portion including the description resource data model. Solid Notifications Protocol's ResourceServer has higher specificity on Solid Notifications Protocol's description resource data model than the other products (e.g., Solid Protocol's generic Server or Client behaviour).
It goes without saying, and this is not specific to the Solid Notifications Protocol, any system that's combining conformances for different products need to simply take these into account. A couple of approaches off the top of my head:
- A system rejects update requests to the description resource. Out of the box behaviour for Solid Notifications Protocol.
- A system rejects update requests that use Solid Notifications Protocol's description resource data model when processing the payload.
- Irrespective to any updates to the description resource, the Solid Notifications Protocol's ResourceServer generates whatever it wants to. This approach would still be conforming to the Solid Notifications Protocol with the understanding that it is actually still the ResourceServer that has the authority over the materialisation of the description resource data model, as opposed to "client control".
These implementations would be interoperable products. Famous last words of course :)
How is this similar/different than Solid Protocol's Server controlling the containment statements in a container? The Solid Protocol's Server accepts update requests targeting the container, whereas - as mentioned earlier - the Solid Notifications Protocol's neither defines updates or prohibits. A ResourceServer implementation can't sensibly be conforming or built properly if it doesn't have the fundamental authority on the part using the description resource data model.
This issue is partially related to https://github.com/solid/specification/issues/525
Currently, we seem to assume that the server controls statements about notifications discovery. I don't see anything preventing the client to that has to write access to the resource to modify the Description Resource, including the notifications discovery statements.
IMO server is responsible for coordinating with the Subscription Server and Notifications Sender so it should have exclusive control over notifications discovery.