SAFE Network Services
Currently SAFE services are created by inserting an entry into the services MD of a public name.
For example, for the public name ‘thing’ the entries in the corresponding services MD might be:
| Key | Explanation |
|---|---|
| blog@www | There’s a website at safe://blog.thing |
| www | There’s a different website website at safe://www.thing which you can also reach at safe://thing |
| mail@email | You can send email to an inbox at mail.thing |
I propose a modification to this convention for a class of services which are compatible with ‘www’ - ie all services for which the value of the corresponding entry is an NFS compatible MD which contains entries for files. For a website this NFS container MD is an index of the files of the website (index.html etc).
Each NFS compatible service would have a different service name so it can be detected by software that provides functionality specific to that service, but would still be accessible as if it was a ‘www’ service by a SAFE web browser - either via index.html, or as individual files via individual URIs.
1. RESTful SAFE Services
I propose that these services have a service name ending in ‘-www’, so for example, an LDP / Linked Data Platform service would be named ‘ldp-www’.
A SAFE web browser accessing a ‘safe:’ URI would treat all services whose name is either ‘www’ or ends with ‘-www’ the same, as currently for the ‘www’ service.
Benefits
Most software would treat this class of services like a website, making it easy for files stored on such a service to be accessed with a SAFE browser and the appropriate URI regardless of the other features of the service.
While software which recognises the particular service could offer additional functionality in accordance with the service. So for example, in the case of ‘ldp-www’, a library can provide emulation of a RESTful LDP server.
In fact a range of existing RESTful web protocols and services could be supported in this way (Solid, a URL shortener, ftp, WebDav etc) making it much easier to adapt existing web based applications, tools and libraries to work with SAFEnetwork.
Any application wanting to make use of a RESTful service on the SAFE Network would include a standard SAFE services library (such as the safenetwork-webapi which I’ve been working on to enable Solid applications to work with SAFE Network in a similar manner to that described here).
The ability to support RESTful services in this way means that developers with existing web skills can reuse those skills when building on SAFEnetwork rather than having to learn the intricacies of the SAFE API before they can begin to be productive, at least for applications where a RESTful interface is a good approach, which covers a large set of use cases.
Alternatives
One thought is to call this class of services ‘nfs’ rather than ‘www’ and so they would all end with ‘-nfs’ and a Web service would use key ‘www-nfs’, and LDP service would use key ‘ldp-nfs’ etc
This seems more correct, because it indicates the nature of the secondary MD (an NFS container) rather than suggesting it is a website, which is not necessarily the case.
Additional Proposals
2. Container Metadata
A special key is used to hold metadata for an NFS container MD.
Currently the key used is ‘_metadata’ which means that it is not possible to store a file of that name in an NFS MD, which is not a major limitation, but unnecessary and undesirable.
So I think it would be best to use a scheme which allows any legal filename to be used.
One way would be to include the leading ‘/’ in the path for all files. So the ‘_metadata’ key would remain unchanged, but a file of this name would have a key of ‘/_metadata’ and all other file entries must also begin with ‘/’.
This is slightly less efficient but more intuitive, which I think is worth the cost. So I also propose this change for discussion.
3. NFS File Permissions
This topic needs it’s own thread so I’m just mentioning it here as it is relevant to some services, but it would be useful to have per file permissions in order to implement some services (such as Access Control Lists for a Solid service) and in general to enhance the capabilities of SAFE apps.
but