Dealing with missing discovery infrastructure

[jeff-zucker]

The default version of CSS is missing a number of things which SolidOS counts on - a settings folder, preference file, typeIndexes, an inbox container , a public container. In Data-Kitchen I pre-provision all of those so a Data-Kitchen CSS does include them all. If we believe that these things are a best practice for pod providers, we should say so publicly so that those intending to offer CSS pods will at least know that these things are missing and hopefully provision new pods with them. If these are not a server best practice and/or we want to handle servers who don't implement them, how should we handle it?

We could have mashlib itself create the settings, inbox, and public folders, and put pointers to them in the profile. If we don't do that it seems like the minimum we can do is a) when preferences are missing, treat the person as in the developer role when logged in - otherwise there is no way to delete any resources (see #47 and #48) and b) have the "got to user X's files" link on the pod root home pane go to the profile instead because it should exist even if there is no /public/ folder.

[timbl]

These should be created by the client if and when they are needed. There is code in solid-ui to do this for the type indexes.

If you want to read that type index and it isn't there, and the preferences are not there, then your search returns nothing.

If you want to write the type index, either private or public, then you may have to create it. And you may have to created the preferences file if it does not exist and you need a private type index.

[timbl]

It is not the server's job to supply that, it is the the OS. The set of clients. I'll rename this issue from "Dealing with missing server infrastructure " to "Dealing with missing discovery infrastructure "

[bourgeoa]

Should solidos create all needed structure, including what's needed in profile/card. Links to preferences but not only: like store ?

[jeff-zucker]

Well, we can now see directly what is missing. You can create a local CSS or make an account on solidweb.me and use https://jeff-zucker.solidcommunity.net:8443/browse.html. It seems to me that the most critical piece and the one that is easiest to fix, is the missing capabilities from the user role in preferences. I think that we should add "under the hood" to anyone logged-in - I can't see that any user of any level would benefit from not being able to delete their own resources (see #47 ). We could also (later?) add something to create the preferences file and a link to it in the profile, but even in that case, I don't see a reason to deny the ability to delete so we'd need to change the under-the-hood audience anyway. For those who don't know, the forum has had many complaints about the inability to delete.

[jeff-zucker]

Okay, I will give up trying to get servers to be expected to provide discovery infrastructure. If we are then going to create it ourselves to pre-existing pods, it seems to me that we need to allow users to opt out. Should we have a dialog box that tells users what changes we will make in their profile and container structure and ask their permission?

A separate question is what we should do when SolidOS is the front-end for a CSS server as it is on solidcommunity - in that case it seems that provisioning the profile and settings etc. should be done by the server rather than recreating the process for each new user from the client.

[SharonStrats]

I'm not sure about the second question, seems like if we are not having the Spec specifically call these out how could we create them on the server just for SolidOS? My answer to the first question is definitely. I think when we do create some unexpected things we should mention that to the user. I think this will also at least prompt the user to potentially understand what their pod has because if they look at their files they may wonder what these are or may come across it again at some point.

[jeff-zucker]

Now that we can delete from any logged-in role (not just developer as previously), SolidOS itself can work on CSS without any of the infrastructure changes. Some of the panes may need to create the typeIndexes if missing, but for the general databrowser, we can get by without preferences, typeIndexes, inbox, or public container or the other discovery items. So I'd suggest putting this issue into a long-term thing to look at, not as a priority for merging auth-upgrade.

[jeff-zucker]

I have made a proposal for a best practices document to deal with this infratstructure at solid/data-interoperability-panel#209

[timea-solid]

@jeff-zucker This point is being further discussed here: solid/solidcommunity.net#62 (comment) and according to solid/solidcommunity.net#62 (comment) "CSS supports extended profile via a custom pod templates."
Also given our work/discoveries on webid-profile: what is your opinion now? Can this discussion be closed with a resolution?

[jeff-zucker]

@theRealImy My opinion is that this issue should be closed when we are satisfied that SolidOS is capable of assessing the validity of a profile (including all its sub-documents) and fixing problems if the profile is not valid according to our forthcoming webid-profile spec. This would mean that SolidOS should be capable of creating a preferences file and a public and a private type-index file if missing; complaining if there are more than one of any of those; and possibly should notify the user about other missing infrastructure such as oidcIssuer, storage, inbox, name, etc.

The question of what CSS supports is orthogonal to this question - regardless of what CSS supports, SolidOS should be capable of creating missing profile infrastructure.

[bourgeoa]

@angelo-v @timea-solid @jeff-zucker
https://github.com/redpencilio/app-solid/tree/master/templates/pod has created templates to be mashlib compatible.
I think this should be reviewed by the profile panel. It works very well and could be added as default for CSS mashlib recipes

This is an implementation exemple that do not conflict with mashlib being able to create needed extended profile

[jeff-zucker]

I haven't fully reviewed it, but at first glance that looks very good. I believe that SolidOS should also implement this on its own and if any of the infrastructure is missing, use that template to create it.

The one problem with us creating the infrastructure is if the storage predicate is missing, SolidOS won't know where to create the settings and inbox folders. So I am wondering if the default behavior should be to place everything in the profile folder e,g, /profile/settings, etc. We still need to discuss that issue but my opinion is that the spec should NOT specify any filenames or paths except that the WebID Profile Document itself be dereferenceable from the WebID. And that apps should NOT depend on particular locations like /settings/prefs.ttl but instead should always look for its location using the pim:preferencesFile predicate.

I think that once we have finalized the webid-profile spec, we should create an app that implements everything that CSS does in that template and make the app run automatically within SolidOS but also be available to other app developers who might want to depend on the profile/settings but not want to use SolidOS as the means to accomplish it.

[angelo-v]

So I am wondering if the default behavior should be to place everything in the profile folder e,g, /profile/settings, etc.

You cannot rely on a profile folder as well, ;) A WebID could be https://alice.org#me

[jeff-zucker]

@angelo-v - is that true? A WebID must dererence to a document. The WebID spec says "For WebIDs with fragment identifiers (e.g. #me), the URI without the fragment denotes the Profile Document. " What document does https://alice.com dereference to?

[jeff-zucker]

I am certainly not suggesting that there must be a container called /profile/, but, as I understand it there must be a document and documents must occur in containers.

[jeff-zucker]

The container might not be writable, but that's another issue. In that case the only option is to ask the user where to put the folders.

[angelo-v]

What document does https://alice.com dereference to?

Could be whatever document, e.g. a turtle file or a html page with rdf-a

Does the Solid spec prescribe that a WebID profile document MUST reside in a LDP container? I imagine that many pre-Solid WebIDs won't conform to this

[jeff-zucker]

No, there's no mention of a container. So I guess we are left with

1. Look for a storage predicate,
   1a. if exactly one predicate found, put extended profile documents there.
   1b, if none or more than one predicates found, ask the user

[timea-solid]

UPDATE: A big part of discovery was achieved with SolidOs creating new preference and typeindex files if they are missing in profiles.
As I can can see from the conversation, this ticket goes beyond those files. I suppose this will be 'done' only when the WebID spec is finished and we have a shape we can check in SolidOS and take action if a profile diverges.

[jeff-zucker]

One major thing undone - AFAIK, we completely ignore see-also files.