Add migration instructions for older apps

[RubenVerborgh]

No description provided.

[NoelDeMartin]

I started making Solid apps exclusively on NSS and trying other servers (not just CSS) I've found a couple of things I needed to change, so maybe it's useful if I share the main ones that come to mind.

To clarify, these are things that Solid apps should NOT depend on:

• Globbing - It's at risk of being changed or removed.
• posix:mtime and purl:modified for container resources - This is not part of the spec yet.
• solid-auth-client - It doesn't support DPoP authentication, you should use @inrupt/solid-authn-client-browser or something else instead. Related with that, your app won't stay logged in after refresh.
• pim:storage in the profile - It can exist, but if it doesn't you should move up the URI path hierarchy.
• The type index - It can exist, but if it doesn't you can create it. Although that's not recommended either. I'm still learning about this, so I can't say much about the proper way to do it. So far, I was pointed to the interoperability spec.

[jeff-zucker]

Great list @NoelDeMartin. I would change your second paragraph to "things your app should NOT depend on". We certainly can use typeIndex, mtime, etc. when they are available, there is nothing wrong with a server making them available, what's wrong is counting on them to be there. The use of solid-auth-client probably, unlike the others, should be in the do not use list.

[NoelDeMartin]

Thanks for the suggestion @jeff-zucker, I just edited it. I'll leave solid-auth-client in the same list because I still use it in my apps, it works better with old versions of NSS than Inrupt's client. But it's not the default authentication option.

[Vinnl]

@NoelDeMartin pim:storage in the profile should exist, according to the spec according to @csarven:

Clients can discover a storage by making an HTTP GET request on the target URL to retrieve an RDF representation [RDF11-CONCEPTS], whose encoded RDF graph contains a relation of type http://www.w3.org/ns/pim/space#storage. The object of the relation is the storage (pim:Storage).

So it looks like we should be able to assume we can determine the storage, and that the fact that CSS doesn't is a bug in CSS. @matthieubosquet said he was going to respond to that (which is why I didn't report a bug), because he believed profiles didn't need to list storages (which is why CSS doesn't), but he hasn't responded yet at this point in time.

[Vinnl]

I didn't report it because Matthieu said it was intentionally left out, but reported here now: CommunitySolidServer/CommunitySolidServer#910 Listing it in the template sounds perfectly fine to me.

[csarven]

The Protocol does not require that a profile includes pim:storage. I don't think it is a CSS bug.

But @Vinnl I think what @NoelDeMartin is referring to this instead:

Clients can determine the storage of a resource by moving up the URI path hierarchy until the response includes a Link header with rel="type" targeting http://www.w3.org/ns/pim/space#Storage. Clients may check the root path of a URI for the storage claim at any time.

and for that yes the server is required to:

Servers exposing the storage resource MUST advertise by including the HTTP Link header with rel="type" targeting http://www.w3.org/ns/pim/space#Storage when responding to storage’s request URI.

I don't know if that's a CSS bug or not.

---

Although that's not recommended either.

Some claiming "legacy" is not the same as consensus :)

[matthieubosquet]

This is not a bug in CSS.

Clients can discover a storage by ...

1. That is not a MUST
2. If a MUST related to that existed, then all resources served by a Solid server would include an authoritative statement pointing to their storage
3. However, there is nothing mandating that a WebID is stored in a Solid server, besides that, any number of storages might be "owned" by a WebID AND there is no requirement for a storage to advertise its owner (so, by extension, there should be no requirement for a WebID to advertise all the storages it owns)

So to your question @Vinnl:

if someone logs in to my app with their WebID, how do I figure out where to store some particular data?

I'm afraid, there is no answer.

An application can not and for that matters, will never be able to consistently determine where to store data based on the WebID used in the session.

Probably that moving up the path URI can help a little in some cases, that is if: the server decides to advertise its owner AND the WebID is stored in a Solid server AND the Solid server used to serve the WebID is where the user wants to store that "particular data".

In truth, the user will need and should have a way to determine where data is stored and that's quite complex and prone to judgement calls and errors.

As @justinwb mentioned in gitter, those questions are being addressed in the data interoperability panel. But I'm afraid, there is no consensus or standard way to answer your question. In any case, I think apps will need to keep track of storages and provide adequate help for users to chose where to store their data.

[Vinnl]

@matthieubosquet I took it back to Gitter since it's not really related to this issue or even this repository, so hard to track for people it might be relevant to: https://gitter.im/solid/specification?at=611a44153eec6d41d15c0c09

[jeff-zucker]

An issue for implementers to keep in mind : CSS does not label the iana media type of resources in the listing of a container. On NSS we counted on being able to look for a triple with the content-type in the container's RDF. Things that count on knowing the content-type of contained resources (like the mashlib databrowser's slideshow) will not work. See SolidOS/solid-panes#301. Am I right in assuming that the specs do not require the content-type and that therefore this is an issue on solid-panes rather than on CSS?

[bourgeoa]

@jeff-zucker @RubenVerborgh

Some specifications are the result of existing specifications and implementations depending on maturing ideas and server implementations.

Here the problem has I see it is that :

• contentType is a MUST on create and it is surprising not to be able to be returned back in container. A resource is defined by a pair of content and content-type. This pair can have different representation but it does not seem the point here in displaying container content.
• it is available in GET or HEAD and there is no other way to find it, even on NSS or CSS the resource name cannot give you the contentType

The argument of representation does seem to me something else and not related to returning the resource contentType used on creation or update

So yes there is an issue in dataBrowser and all apps using the container to find the contentType, if the contentType is not available in the container.
The solution of doing a HEAD from browser is much heavier than server side.