Caps Disco
Closed this issue · 4 comments
Over the years we have struck a balance between two approaches to defining Solid: "all storages should work with each app" in one extreme, and "any storage can decide for itself what it supports" in the other.
We have now arrived at a point where:
- this specification leaves it open whether a storage supports WAC or ACP
- this specification leaves it open which Notifications Channel type(s) a storage offers
- some features like chunked uploads and paging are considered up to the storage - some storages will support them, others will not, but they will still be called Solid storages.
- we are no longer adding or deprecating features in https://solidproject.org/TR/protocol
This means that to make a specific app work with a specific storage, the app will have to find out the storage's capabilities in the same way a browser discovers the capabilities of a website: through things like per-resourceWWW-Authenticate response headers and the like.
To make this all a bit easier, it might be useful to define a single well-known resource that lists all a storage's capabilities. I'll prototype this in Pivot and then we can discuss it in the community group.
NB: If the Solid CG can incubate the usefulness (or not) of such a mechanism, then maybe the LWS WG would also be interested in adding it to their protocol, but I'm opening this issue here first, to discuss how we deal with this in the Solid Community.
I think this issue is a duplicate of #355 , if not, it is already covered by the discovery of communication options as one of the cases. I suggest sharing implementation experience in that issue so we can continue to track public incubation.
Ah, thanks for link! Indeed a lot of overlap, especially with the "Uhuru" story from #355. If not a duplicate, then at least #355 is a prerequisite of #699, and definitely relevant discussion about how to implement the mechanism, e.g. nesting .well-known in folders etc. I'm reading through it now. I'll make sure the right discussion ends up on the right issue (maybe indeed merging this issue into the older one), so we're not discussing in two places.
For the mechanism, I'll experiment with the option @csarven explored in May 2022:
The server MUST include the Link header with rel="http://www.w3.org/ns/solid/terms#storageDescription" targeting the URI of the storage description resource in the response of HTTP HEAD or GET requests.
I'll post my findings on #355.
PS, I originally wrote 'discovery of Solid server capabilities', but later realised what I meant is almost entirely about capabilities of the storage and not of the IDP, so edited the top comment to be about 'discovery of Solid storage capabilities'.