Hello all,
With ESS 2., I’ve noticed all the resources have been replaced with a storage-* string. However, I can no longer access any resources that were not public and I am unsure how to resolve this. Is there a new way to authenticate that needs to be done in order to view your old resources?
Thanks
Hi @gaz009, you’re right in that all resources are now located on storage.inrupt.com/$pod_id/$resource, however, as far as I know links to these resources and their associated ACRs / permissions should have been migrated.
It would probably be best to reach out to support@inrupt.com, though it may take a little bit to get a response this week.
Did you set the Resources that are public to be public by yourself? Because for me, even the files that are in the default /public/ folder are no longer publicly accessble (example), and I don’t think I ever changed the access control settings there (although I do see a /policies/ Container, I think created by PodBrowser).
Even the extended profile document is private now. If I go to the WebID and follow the rdfs:seeAlso link, I get to a private file. I never set my profile to be private.
Hello Vincent,
Afaik I didn’t manually set anything related to the public/ container on ESS. The main thing I find confusing is the fact that on podbrowser I can view the non-public files and containers in the upper level directories, however many (assuming all) of the files on the lower levels are giving me the no-access error. I have other pods I use for testing, and neither of them have the same issue, which is why this is confusing.
@gaz009 @Vincent & @jeffz looks like this may be a side-effect of the migration, I’ve raised this internally.
For now, to get back to the old behaviour, login in to your pod on podbrowser, navigate to the “public” container/folder, then select “folder details”, then in the sidebar, open the “sharing” panel, where it says “viewers” click “edit viewers”, in the modal that pops up, click “anyone” to check it, then “save viewers”.
Note: resources within the public container can still restrict access on their own, overriding that “anyone’s a viewer” at a container level.
Hope this helps!
Edit: example, this is on one of my pods after doing the change: https://storage.inrupt.com/e9179f88-ca8f-45e1-a1b9-88a83f61db5e/public/public-client-identifier.json
Edit: The details of how profiles will work is currently being defined by the webid-profile group: GitHub - solid/webid-profile: Discovery based on Solid Social Agent WebID. I have collapsed my previous statements.
The extendedProfile document is currently private by default, but you can make it public too.
The SDK currently only follows the foaf:isPrimaryTopicOf / foaf:primaryTopic predicates (you’ll note ESS 2.0 provides rdfs:seeAlso and foaf:isPrimaryTopicOf), as this is based on work that pre-dates the webid-profiles spec group.
(though we don’t currently have an API / means for creating additional alternative profile documents, so you’d need to do:
I think the intent in the future is that your webId would contain references to additional profile documents e.g., you might have a public extended profile and a restricted extended profile, and that restricted one might link to addition documents containing the data grouped by who can access it (friends, family, etc).
But this is all still being specified by the profiles working group, if I’m not mistaken.
Well, it seems like this is all going in a very different direction from previously established practice and from what the profile spec will recommend. Private resources should be kept in the pim:preferences file. The spec is open for review.
@jeffz I’ll defer to the spec team, I’m out of sync with them/you, and I’m sure ESS will align with the spec when it’s ready — I’m not involved actively in that, and the design above possibly pre-dates your spec work.
Gotcha. No blame intended. SInce the spec isn’t published, there’s no expectation that anyone will follow it :-). I think once it is more complete we should sit down with a team from Inrupt and find the easiest way to implement the way ESS wants it to work that is compatible with the spec. A predicate here or there ought to do it. I am certainly on board with Inrupt’s general principles which I take to be - the WebID Profile Document doesn’t need to live on the pod server and people should be able to keep as much of their profile private as they want.
Yup, that’ll need to happen for sure; the way it currently works in Inrupt’s ESS/SDK is work that wrapped up back in December 2021, if I recall correctly, and spec started after that when it was realised that a spec was needed.
I think the way things are now is temporary, and we’ll need to eventually help people migrate towards a public extendedProfile document, splitting the data that’s currently in the private document between multiple documents if there’s information they still want to keep private.
The original vision was that there would be two profile trees - pubic and private and that the pim:preferencesFile would be the jumping off point for the private tree. Rather than multiple private links in a public spot, there is only one link to the preferenceFile and all other private links are found there. Seems cleanest.
I think that makes sense… though, there’s a difference between “public”, “shared”, and “just me”; I think what’s currently being solved is the public and shared, but not the “just me”
Exactly! We intend to define those in the terminology up front. Probably using the terms private (only me), public (anyone), restricted (only those we have given permission to).
So the way we have it public and restricted stuff goes in seeAlso documents linked from the main profile and private stuff goes in the preferencesFile or seeAlso’s linked from it.
So if I want to share information about myself with just my friends, it’d go in a rdfs:seeAlso, correct? You could see the document exists (maybe it’s name) but not who can access, just that the general public or a non-friend couldn’t read it.
Current issue in ESS would be that the WebID document is only editable by the WebID service/app, so I’d need a specific app to add those additional profiles for groups of people (friends, family, coworkers, etc) — this is what I meant by the SDK doesn’t have a way to allow any application to modify that document, as that’s modifying the WebID (which in ESS is strictly controlled)
Yes, your top paragraph is how I see it.
So if ESS created links to the type indexes and one seeAlso/primaryTopicOf on account creation, all else could be done in those other files. The primaryTopicOf could have links to various restricted or public seeAlso files. So apps don’t write to the profile document at all.
Yeah, so an implementation would be following two degrees of resources: webid profile document (0, dereferencing the webid) → extended profile document + preferences (1st) → additional rdfs:seeAlso’s (2nd)
Does that make sense? Currently the inrupt SDK implementation only follows first degree automatically.
Yep, the way I phrase it in the spec :
rdfs:seeAlso, solid:publicTypeIndex, or solid:privateTypeIndex as predicate and load the objects of those triples.