Support multiple service types on a given safe URI

[happybeing]

This is a feature request to allow enhanced or alternative services to be implemented while maintaining functionality in existing clients (including SAFE Browser). The example is based on the experimental WebID APIs but would apply equally to the current API and other alternative service APIs.

My use case is related to compatibility with Solid but I think is relevant to other situations because it increases the capabilities of clients that support services not anticipated by SAFE itself.

Current Implementation (experimental WebID API)

I think there's a limitation in that you can only have one service per service URI (RDF subject).

The following example is the RDF for the subNamesContainer (services MD) for the public name happybeing, as accessed via webFetch() / readPublicIdAsRdf():

key: safe://happybeing
val: {"@id":"safe://happybeing",
    "http://www.w3.org/ns/ldp#contains":[{"@id":"safe://me.happybeing"}]}

key: safe://happybeing#it
val: {"@id":"safe://happybeing#it",
    "http://safenetwork.org/safevocab/hasService":[{"@id":"safe://me.happybeing"}]}

key: safe://me.happybeing
val: {"@id":"safe://me.happybeing",
    "http://purl.org/dc/terms/title":[{"@value":"'me' service"}],
    "http://safenetwork.org/safevocab/typeTag":[{"@value":"16048"}],
    "http://safenetwork.org/safevocab/xorName":[{"@value":"235,191,43,80,187,123,165,110,156,170,165,28,130,238,5,149,208,139,140,238,97,13,177,87,190,199,71,5,93,253,202,143"}],
    "@type":["http://safenetwork.org/safevocab/Service"]}

The last key is for the service entry of safe://me.happybeing, which I think is designed to only allow one type of service for safe://me.happybeing.

I propose this is changed to allow multiple services to be present on the same service object (e.g. safe://me.happybeing).

The reason is that this will allow the client to decide which of the services available it supports and what to do with them. If the client finds services it doesn't understand at a given URI it can ignore them.

In the current implementation, only one service can be specified and the client must fail if it doesn't recognise it. By allowing multiple services, a basic or default service (e.g. 'www') can be specified which many clients will understand, alongside enhanced or alternative services giving additional functionality through clients which support them.

I imagine there are various use cases for this. The one I'm keen on is to allow me to create both web and LDP services for a SAFE storage location. So for example, safe://files-me.happybeing with both 'www' and 'LDP' services would allow a Solid file manager or an HTML editor read-write access, while SAFE Browser would be able to display the content as web pages.

Summary

This feature would allow specialist clients to access storage using different protocols (LDP, WebDav etc) all as services on the same URI, and the SAFE Browser (and other clients) can fall back to handling of 'www'. And as I say, an immediate benefit will be to allow Solid apps to read/write access to a SAFE storage container while keeping the same content accessible via the standard SAFE Browser.