Should it be possible to find controller of storage via resources?

[megoth]

(I think I've created an issue before that's close to this one, but I'm unable to find it right now - sorry if this is a duplicate, but think it's important to bump the issue for the specification editors to discuss.)

In the current data browser we have a function that gets the profile that is "the owner" of the Pod, i.e. the profile that is located in (Pod)/profile/card#me. This is hardcoded against the current implementation of Node Solid Server, and will break if NSS changes or on any other Solid Server implementation that don't follow this pattern.

Currently there is no way of detecting the "owner" (in lack of a better word) of a Pod from a given resource. (Or possibly "owners", if multiple WebIDs can be said to be owners of the given Pod.) I think this can be useful, as it allows us to give more context to the current Pod that someone is visiting, at least when visitig the "root of the Pod" (another term I know might be problematic, hence the air quotes).

It might be problematic for people to expose their ownership of a Pod, so if it should be part of the standard, we might want to make it opt-in. (The Pod Provider would still have access to the info, but accessing the WebID through resources, or just the root, might be hidden for everyone else by default.)

[elf-pavlik]

I think this can be useful, as it allows us to give more context to the current Pod that someone is visiting, at least when visitig the "root of the Pod" (another term I know might be problematic, hence the air quotes).

I recall conversation about root of the storage in solid/data-interoperability-panel#10

Following terminology from auth draft resource controller(s) of the "root" in a solid storage would very likely set very restrictive ACL on that "level". If someone arrives to that "storage root" IRI for example following space:storage predicate in someone else's WebID Profile, they would most likely get HTTP 403 due to mentioned restrictive ACL on that resource/container.
For users who do have at least read access to the storage root, I think one could add statement to that container using space:storage predicate the same way as we use it in WebID Profile.

[RubenVerborgh]

The bigger blocker for this is that, strictly speaking, we don't model the concept of a "pod" in the Solid tech stack. E.g., you won't find predicates like "hasPod".
It's the same on the Web, really. On the Web layer, there are only linked documents. The notion of "server" disappears in the layers below.

So we would first have to explicitly model the pod, as part of another system that is independent of the current document-based infrastructure. This modeling of accounts etc. is the topic of another discussion somewhere.

[megoth]

@elf-pavlik Yes, that was the issue I was thinking about (in the Solid Data Interoperability Panel), thank you 😸

I understand that this is a complex issue, and might end up with us not being able to do what we currently do in the data browser. We'll support whatever decision the editors conclude.

If you can advice us to what we should do with the aforementioned function at some point in not to distant future (e.g. should we remove it altogether?), that would be appreciated.

[csarven]

Background on determining root(URI): solid/data-interoperability-panel#10 (comment)

Loosely speaking, if we agree on "determining" instead of "discovery", then an intuitive way to discover the "owners" (or controllers) of the root resource would be a simple relation eg. foaf:maker. What's around the corner is a way of discovering agents with particular roles involved with a resource eg. owner (the authoritative agent), administrator (to ask for stuff and nonsense). There are existing vocabs and ontologies around this.. and we can take a closer look at those. It could even end up as a simple shape in that every root resource should for example advertise a contact.

[elf-pavlik]

The bigger blocker for this is that, strictly speaking, we don't model the concept of a "pod" in the Solid tech stack. E.g., you won't find predicates like "hasPod".

I've commented in solid/data-interoperability-panel#10 (comment) , #16 (comment) and various other places that while pod gets used more as vague buzzword, we seem to have pretty well defined term solid storage, and predicate space:storage where space:storage rdfs:range space:Storage.

@megoth in this issue and the other one about root url, when you use term Pod do you mean something distinct from Solid Storage discoverable from WebID Profile through space:storage predicate?

[megoth]

@megoth in this issue and the other one about root url, when you use term Pod do you mean something distinct from Solid Storage discoverable from WebID Profile through space:storage predicate?

No, I'm referring to storage. Sorry for the confusion.

[megoth]

I've updated the title of the issue to refer to storage, hope that's ok.

[RubenVerborgh]

^ Depends on: create a definition of "owner".
(At the moment, storage could have zero, one, or more owners.)

[elf-pavlik]

https://github.com/solid/solid-spec/blob/master/solid-webid-profiles.md#storage-discovery

Storage Discovery

A Solid WebID Profile SHOULD contain a link to one or more Solid Containers
that act as Storage (a space for apps to read and write data).

Example link to Root Storage (gets created
by default on account creation):

# ...
<#me>
    a foaf:Person ;
    <http://www.w3.org/ns/pim/space#storage> <../> .

---

Since Solid already establishes this predicate to relate WebID with Storage, I think we should see first if we could rely on this relationship for discussed scenario. If we take example where WebID Profile and Storage have more separation, we could have two independent documents including the same statement:

# https://alice.example/
<https://alice.example/#me>
    a foaf:Person ;
    <http://www.w3.org/ns/pim/space#storage> <https://alice.solidstorage.example/> .

# https://alice.solidstorage.example/
<https://alice.example/#me>
    <http://www.w3.org/ns/pim/space#storage> <https://alice.solidstorage.example/> .

If we find reasons to introduce another predicate than space:storage, I think we should clearly document how their meaning differs and how differently we intend them to be used.

[kjetilk]

Indeed, I think we need to have some explorations around "owner", as there are a few things that are centered around that agent, for example concerning recovery from Loss of Control (#67). As @RubenVerborgh says, it is tricky, because we need to change things conceptually. I haven't had time to think very carefully about that topic, so I follow your thoughts around using space:storage with interest.

Also note that we do have this explicit hierarchy in Solid pods, which could extend up to the authority (in RFC3986 sense), which could also possibly help in defining this.

[csarven]

The notion of server-managed or protected resources are covered in #65 as part of "auxiliary resources" in #156 . It is read-only for a client. It is intended to have information about the creator of a resource (among other claims).

A strict notion of "owner" of a storage is not necessary at this time - but we can revisit that if we need to. It can be pulled in the direction of the authority of the URI space, the controller of the resource, or the creator of the resource.

For the time being, the closest concept is the agent with control access on the root container. Pods or storage are typically instantiated with an agent having Control on the root container (ie. root path as per hierarchical containment). AFAICT, storage only becomes useful if there is an agent with Control on the root. Everything stems from that.

It can follow that: there should be a claim about the agent(s) that have control access as the owner/authority of the pod that's discoverable and readable from the server-managed resource. Servers should create this information when the first account (with WebID) is created. Server updates the server-managed resource as owner/authority/controller changes.

Client discovery and use:

1. Discovery of the server-managed resource (follow solid:managed)
2. Finding the description about the "controller" of the storage (eg. look for </> solid:controller <WebID>)

1 is nearly resolved. 2 the shape/description needs to be worked out.

Edit: using "controller".