I’m reading the above as “this is the place for posting about the experimental API” so…
Context
Having taken a pause with SAFE Drive etc I’m back to working on compatibility with Solid apps (SAFE Plume was almost a year ago!).
The aim is for someone who has a Solid app to be able to run it on SAFE with as little work as possible, and for anyone familiar with creating Solid apps, or who knows the web specs relating to Solid (RDF, WebID and LDP) to find it easy to migrate to or build directly on SAFE.
Status
I’ve updated the SafenetworkJS support for LDP which was used in the Plume demo, and created a fork of solid-auth-client. Using those, and no other changes, I have one Solid app working (solid-filemanager but not yet ready for public consumption.
This demonstrates that authorisation and simple file access can work without code changes to the Solid app (though it is only the first so I’m not sure how many apps this will be true for).
Now I’m looking at how to make access to WebIDs work equally smoothly. I have the same app picking up the SAFE WebID (again without code changes to the app), but the SAFE way of tying the two together (WebID and storage) is non-standard, and would not work as is.
I have a solution in mind using my LDP emulation, so that if a Solid app tries to access storage based on the WebID (as solid-filemanager does) it can ‘just work’ without code changes, as follows:
Attempting to follow convention, solid-filemanager assumes that storage for a WebID safe://me.happybeing#me will be accessible at safe://me.happybeing (it assumes the ‘host’ will be the root of storage which is the case for a Solid POD, and I think other apps will make this assumption even though it isn’t mandatory). I can emulate that, and provide ways to determine the storage location from the WebID profile, but the SAFE API doesn’t represent this in quite the way Solid does which will be confusing and make it hard to provide a seamless way for Solid apps to access WebID profiles. This is because Solid WebIDs are typically represented as safe://me.happybeing/profile/card#me rather than safe://me.happybeing#me.
Proposal
So I’d like to suggest that the SAFE WebID API (or rather the URI representation) be changed so that a SAFE WebID includes the profile as well as the ‘host’ (i.e. safe://me.happybeing/profile/card#me). This may seem clunky to those implementing the Maidsafe code, because a SAFE WebID is not a file (it’s an entry in the _publicNames container), but it is intuitive as an API and for my emulation at least it will enable greater compatibility with the Solid API. It also makes it easier to map this API in an intuitive way to other apps such as SAFE Drive.
For example, in SAFE Drive I could implement a _webIDs folder much like _webMounts, where the former would contain a directory for each WebID and the profile would be represented as a file in the directory, as if it were part of a storage container which I can create automatically. In this way, a SAFE WebID URI and profile could be accessed in exactly the same way as on a Solid pod, and as part of a file system UI. For example, a SAFE WebID of safe://me.happybeing/profile/card#me would appear in SAFE Drive as:
~/SAFE/_webIDs/
\- me.happybeing/
\- profile/
\- card.ttl
Summary
By changing SAFE WebIDs to follow the convention for WebIDs in Solid (i.e. safe://me.happybeing/profile/card#me) they will be recognised as a WebID by anyone familiar with Solid (whereas safe://me.happybeing#me will not), and they will know how to access and modify the profile using the API (LDP) which they already know (and can emulated on SAFE). This can also be represented in a consistent way as part of a filesystem. By eliminating the ‘card’ from the URI all of that becomes harder.
And getting back to the other, more important aim, it makes it possible for more Solid apps to work on SAFE without code changes.
@joshuef @lionel.faber If there’s a better place to file issues, let me know and I’ll add this there.