Working with multiple pod providers

1

Applications should work for all the possible pod providers, so I created pods with several different pod providers to test my application:

I can login for each of the providers but when I want to create/get a dataset for example it will not work for all of the providers. When I look into examples or apps of other people they all do it in another way to get the URL where the dataset should be.

getSolidDataset(url, options?)

Letā€™s say I want to create a dataset ā€˜notesā€™ on my pod, what should be the URL?

1 Like
2

Iā€™m not an expert on this, so I hope others will chime in. But Iā€™ll detail the first part (getting the pod url) and hope others will fill in on the applications interoperability part :slight_smile:

After you logged in, you will know the WebId of the user. Now, every WebId can be linked to multiple pods, so will have to let the user decide which of those to use. You could for instance fetch these linked pods and show the user a dropdown. To fetch the pods with solid-client-js, there is getPodUrlAll. This will give you a list of zero or more pod urls belonging to the user, which you can use for the UI.

I think until here, it is clear what to do. Given a pod url, you could simply create a dataset ${podUrl}/mynotes.ttl and write there. However, this way other applications likely wonā€™t find the notes dataset, which hinders interoperability. Therefore, there are active discussions on how to store data, such that all applications can (more or less) easily reuse them. I hope others will elaborate here, as Iā€™m not so familiar with them :smiley:

EDIT: if youā€™re just getting started, I think itā€™s fine to choose the easy path now and simply write to ${podUrl}/mynotes.ttl or ${podUrl}/notes/some.ttl. Later on you can come back to this discussion and adapt the application.

1 Like
3

I think the initiative thatā€™s come the longest wrt standardizing how to tell other apps where you store your data is Type Indexes. It works, and although I donā€™t like the manual part of it, I understand why it needs to be like that (i.e. automating this would prob require server logic, and we want to keep the Solid protocol simple for now).

1 Like
4

If I try to get the pod urls with getPodUrlAll I only get something for my pod of inrupt.com. ['https://storage.inrupt.com/eb202e67-f3b3-4c7f-ac99-e7475459e4a7/']. For the pods of teamid.live & solidcommunity.net I get empty arrays []. What does this mean? Iā€™m a bit confused because for others apps I can use these pods

5

Hi. it probably means that no pods are associated with your profile. Would you mind sharing your solidcommunity.net webid?

For me, it worked with the following code:

const { getPodUrlAll, fetch } = require("@inrupt/solid-client");

const webID = "https://sheep.solidcommunity.net/profile/card#me"
const pods = await getPodUrlAll(webID, { fetch: fetch });
console.log(pods)
// logs [ 'https://sheep.solidcommunity.net/' ]
1 Like
6

This is my webId for solidcommunity.net: https://dietercasier.solidcommunity.net/profile/card#me
So when you register it doesnā€™t mean you automatically have a pod?

7

Could it be, that you by accident modified your profile card? When visiting your WebId it redirects to https://dietercasier.solidcommunity.net/profile/card/#me which is a folder called ā€œcardā€ rather than the document that usually should be there.

If you did not modify it, Iā€™d suspect an error in NSS. Maybe try creating a new one and see if visiting your webid redirects to a folder rather than the document.

And on a side note, for CSS it does not by default add a pim:storage predicate to the webid profile, so itā€™s normal that it is an empty array here. At least it did not include it some years ago ^^

Iā€™m a bit confused because for others apps I can use these pods

At least Penny is also confused with your WebId. The Penny app is pretty well-written, so Iā€™d suspect your WebId to be somehow broken. Hereā€™s a screenshot, showing what happens with your WebId (upper message - not found) vs mine WebId (lower message - suggests my identity provider which it got from my WebId).

immagine

8

Yeah, also inspecting that WebID directly you can see that thereā€™s no storage statement, whereas e.g. this WebID does list one. So Iā€™m guessing an existing app corrupted your WebID.

1 Like
9

Also here, it redirects to a folder (which contains a recipes file apparently) rather than the WebId. It sounds a bit like you created the resource /profile/card/recipes and this implicitly ā€œdestroyedā€ your WebId, by converting the card to a folder (PUT-ting a resource can create intermediate folders if they donā€™t exist. Maybe NSS ignored that the card document existed with the same name, not sure what the specification would guarantee here)

10

Yes I must have done something wrongā€¦ any idea how to fix it? it seems I cannot edit anything

11

Are you still currently logged in with any application? If yes, you could try to delete the card folder. Then it should already be fixed, as thereā€™s still the card document in the profile container (next to the bad card/ folder).

If youā€™re not logged in, either create a new account or ping an admin of this instance (I think bourgeoa) to fix the account.

12

@bourgeoa can you fix/reset my solidcommunity profile? Iā€™m not able toā€¦

13

I think it has been repaired.
I used last week backup of your webId card
I have moved

  • card folder to card.old folder
  • renamed card$.ttl to card.old.ttl
    I donā€™t understand how you came to this content
    NSS do check that you write a turtle file but not that this turtle file is a valid webId.
  • Strangely your OIDC Issuer is
    solid:oidcIssuer https://solidcommunity.net:8443;

Hope this helps. Please acknowledge.

3 Likes
14

I would guess, that it was because a PUT request to /profile/card/recipes created the intermediary container /profile/card/. The profile still contained the original card next to the new card/ container, so I donā€™t think the original card was modified. Only NSS redirected all requests to /profile/card to the /profile/card/ container.

15

I would guess, that it was because a PUT request to /profile/card/recipes created the intermediary container /profile/card/.

But NSS has protections that donā€™t allow the creation of /card/ when /card exists. Perhaps a) those protections were somehow not coded into the recursive creation of containers or b) the user created the situation before NSS put those protections in place.

@dieter - can you tell us how /profile/card/recipes was created? Was it by an app, and if so, which?

16

Iā€™ve filed an issue at the NSS repo that explains how it can be reproduced: PUT can hide /profile/card with intermediary containers Ā· Issue #1743 Ā· nodeSolidServer/node-solid-server Ā· GitHub

1 Like
17

I still get an error if I go to my profile. You can delete my complete account, maybe itā€™s not a bad idea to start over completelyā€¦

18

Since I did not have any pods I tried so many things, I know it doesnā€™t make much sense now but I guess I tried something like:

const url = webId.split("#")[0] + "/recipes";

await saveSolidDatasetAt(url, createSolidDataset(), {
  fetch: session.fetch,
})
19

I still get an error if I go to my profile.

Could you give more details ? Please show your error .
Else we do not learn anything.

1 Like