No pod associated in profile

Build a Solid App
1

Hi,

I’m running a local instance of the community solid server (with -c @css:config/file.json) and created a new account using the /idp/register flow. After successful client authentication (using @inrupt/solid-client-authn-browser) the associated pods shall be listed (using function getPodUrlAll()). Unfortunately there’s no pod assigned.

As far as I can see, the lib fetches the profile card from the solid server and trys to find a predicate “http://www.w3.org/ns/pim/space#storage”. Unfortunately, there’s no such predicate associated.

The pod exist, as I could verify by accessing it through the URL, but it seems not to be assigned to the profile for some reason.

grafik
grafik778×380 16.1 KB

My local profile looks like:

@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix solid: <http://www.w3.org/ns/solid/terms#>.

<>
    a foaf:PersonalProfileDocument;
    foaf:maker <http://localhost:3000/test1/profile/card#me>;
    foaf:primaryTopic <http://localhost:3000/test1/profile/card#me>.

<http://localhost:3000/test1/profile/card#me>
    
    solid:oidcIssuer <http://localhost:3000/>;
    a foaf:Person.

Does anyone have an idea what’s going wrong?
Thanks, André

1 Like
2

Hi Andre,

From what I’ve read, the pim storage predicate is optional in the solid specification and CSS does not include it by default (see this discussion: Add `pim:storage` in profile documents by default · Issue #910 · CommunitySolidServer/CommunitySolidServer · GitHub).

But based on this discussion, you should be able to modify a few lines of the source code to add it. In particular, try to go /templates/pod/base/profile/card%24.ttl.hbs and add the lines:


@prefix space: <http://www.w3.org/ns/pim/space#>.

...

    space:storage <{{podBaseUrl}}>;

Alternatively you could manually modify the profile using any application that doesn’t crash without the storage predicate (eg with Penny it should be possible).

2 Likes
3

The storage can also be discovered from the link headers - SolidLab has some code to do so here.

4 Likes
4

That helped a lot, thanks @A_A. I was following the Getting Started guide, which describes how to retrieve a list of associated pods. The mentioned function getPodUrlAll() (see solid-client-js/webid.ts at 77121959e2f965257bcf017d74c2e7c5a79632f3 · inrupt/solid-client-js · GitHub) expects the pim:storage to be defined within the profile (seems, like this lib is partly incompatible with CSS6.0).

Also, thank you for the hint to modify the profile template, but I prefer to use the “tree/traversing” discovery described in the SOLID protocol and shown in the code referenced by @jeswr (thanks by the way!). Penny seems to do it the same way. I think this is more robust and I don’t have to take care when it comes to updating the CSS.

Problem solved :wink:

Thanks,
André

5

On Inrupt JavaScript Client Libraries — Inrupt JavaScript Client Libraries it says, that the libraries I use do support the Inrupts Enterprise Solid Server - so it was my fault to expect, that it’s working with CSS.

Do you know of any CSS compliant library? Based on your experience, should I continue to use these libs when developing a SOLID app against the CSS?

6

When in doubt, follow the specification. The most recent specification says that servers MUST provide a link header with a pim:stroage predicate in the root of the storage but it does not say that there MUST be such a predicate in the profile. In other words, no matter what server you are on, you can not count on there being a storage predicate in the profile. Therefore, the only interoperable way to find the location of the storage if it isn’t in the profile, is to do a HEAD or GET on the container and look for a returned link header with rel=“type” http://www.w3.org/ns/pim/space#Storage. If you haven’t found the storage yet, walk the container tree looking for the header until you find one. I don’t know which servers are spec-compliant in this regard, but if they do not have a link header with a storage triple at the root of the storage, that is a bug in the server.

1 Like
7

From my experience, it’s a good library and I’d suggest it. The developers focus on ESS, so some thinks may not work on other servers or get fixed slowly. But the main problem I’ve encountered (access/universal functions throw error instead of creating .acl when no .acl exists · Issue #1549 · inrupt/solid-client-js · GitHub) seems to have been fixed lately though, so I think you most cases you should be fine with it also for NSS and CSS.

And regarding “CSS compliant”: ideally “solid compliant” should be enough and not specific to the server. The solid-client-js library is also based on the solid standards, but I guess in some cases the use optional stuff that’s implemented by ESS but not by others. So in general it’s fine to expect that it also works with CSS :slight_smile:

2 Likes