Define capabilties affecting Resource Identification (URI allocation)

[elf-pavlik]

This is a followup on short discussion during today's issue triage meeting where @jeswr mentioned Solid slash containment in context of

• Use of the Slug header in the LWS protocol text #94

https://w3c.github.io/lws-protocol/lws10-core/#resource-identification-0

Resources are identified by URIs. The URI of a resource is independent of its position in the containment hierarchy. Servers assign URIs during resource creation and MAY incorporate client hints (e.g., the Slug header), but clients SHOULD NOT assume that URI structure reflects containment.

Currently for a client to assume something like slash containment it would require some out of bound coupling with the server. In open ecosystem effectively client MUST NOT make such assumptions.

As part of

• Solid Compatibility / Migration Work Item #66

LWS WG could consider defining capabilities that could be used in the Storage Description and allow clients to discover implementation/deployment choice made by the storage provider.

Myself I would be interested in a capability which would allow advertising a URI Template which would define pattern for all resources as simple

https://storage.example/{uuid}

or

https://storage.example/{Idempotency-Key}

This could be related to potential solution for

• Idempotent Create #173

[acoburn]

@elf-pavlik if we approach this issue from the perspective of a server capability defined in a Storage Description resource, there are really only two required components: a type URI and a way of expressing this capability.

Using URI templates, this could look like the following (for servers that use UUIDs in a flat URI arrangement:

{
  "@context": [
    "https://www.w3.org/ns/cid/v1",
    "https://www.w3.org/ns/lws/v1"
  ],
  "id": "https://storage.example/",
  "type": "Storage",
  "service": [ ... ],
  "capability": [{
    "type": "https://vocab.example/URITemplateAllocation",
    "value": "https://storage.example/root/{[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}}"
  }]
}

Or, for any URI, the value could be https://storage.example/root/*

Alternatively, the type URI itself could indicate the supported URI allocation rules and the value field could be omitted.

If that seems like a suitable approach, there are some decisions to be made w.r.t. how that fits into LWS scope. One approach is to define the type URI in the LWS vocabulary itself and include this in the protocol specification itself (this would add scope to the current protocol). Another approach is to leave the definition of the URI out of scope for LWS (for now) and let this incubate for some time. Potentially, this could be brought into scope for a future version of LWS

[elf-pavlik]

I think that besides defining specific model for such capabilities, we may need some kind of registry to keep track of them.
Each capability may also need to have it's own spec, sort of LWS extension, where one spec can define multiple capabilities.
Fediverse has https://fep.swf.pub/
@pchampin should we consider W3C Registry Track for things like LWS Storage Capabilities?
I can find 8 existing registries via
https://www.w3.org/TR/?filter-tr-name=&status%5B%5D=dry&status%5B%5D=cry&status%5B%5D=ry