Discoverability of root and controllers of Pods

As part of the latest work we've been doing with the data browser (which can all be tested on dev.inrupt.net), I've introduced a couple of new parts to the global layout. The first part is the global header, which shows you the Solid logo in upper left corner, which links to the root of the Pod that you're in, and a section in the upper right corner, based on your authentication state: 

  1. If unauthenticated: Two buttons, one for logging in and one for signing up a new Solid account, or 
  2. If authenticated: A menu that opens various parts of what we call the global dashboard (a new feature in the data browser that allows you to access to aspects of your profile and Pod irregardless of which Pod you're at).

The second part is a footer that is shown when you're visiting someone else's Pod. The idea is to give some context for people who might be unfamiliar with how Solid works wrt controllership, and an easy way to learn more about the profile that controls the Pod you're currently visiting.

Side note: I define "visitor" in this context as someone who is either a) unauthenticated or b) authenticated as someone else than the profile that controls the Pod.

The current implementation are based on several assumptions based on how Node Solid Server (NSS) works today, which most probably will not be interoperable with how other implementations of Pod servers might choose to do things. So these new parts are no doubt flawed, and needs to be improved or perhaps altogether removed. But I do think this way of providing context for users that might not be familiar with the current Pod (and Solid in general) are useful and valuable. I think this will become increasingly important as more implementations and instances of Pod servers pop up.

In this text I will make an argument to standardize data discoverability features that removes the need for the assumptions we've made. I'll try to outline the various options I see to how to go about this, and the problems/challenges that I've been able to identify. 

Side note: I'm not married to any of these new features, and am open to be convinced that the downsides of these types of data discoverability that I'm arguing for are too problematic to justify.

The problems

The underlying challenges that I'm trying to solve has two distinct problems:

  1. Discovering root of Pod: Given a RDF resource served via a Pod server, there is no way of discovering in a standardized way the root of the Pod.
  2. Discovering which entities that control the Pod: Given a RDF resource served via a Pod server, there is no way of discovering in a standardized way which entities (be that natural persons or organizations) that have the ability to control the content of that Pod.

I'll expand on these problems in their respective sections. I'll then go on to explain various strategies to solve these problems, and the pros and cons that I currently see with them.

Side note: There is a way of discovering how is in control of a given resource through Web Access Control (WAC). This requires you to be authenticated and have Control access to the resource though, so there is no way for visitors to gain insight into who is in control for a given resource.

Discovering root of Pod

This feature is important if we want to be able to navigate to the root of the Pod that a resource is located in, or if we want the ability to get some information about the Pod that is only available through the root of the Pod.

The assumption I've implemented the current solution with is that the root of the Pod is the site of the URI (site = domain + /, e.g. for resource https://foo.podprovider.com/bar the root will be https://foo.podprovider.com/). This might not be the case, e.g. the Pod root of https://solid.mysite.com/pod/foo could be https://solid.mysite.com/pod/.

Discovering which entities that control the Pod

The idea behind this feature is to provide context about who is in control of the Pod that you're currently visiting. I think this is valuable information in an interface that aren't necessarily branded the way you're used to with centralized systems.

The assumption I've done in the current implementation is to look for the profile document that is NSS generates at <pod-root>profile/card#me (hence building upon the assumption I did in the last section). But of course, there might be other entities that control the Pod, e.g. listed in the root ACL. But as a visitor you can't read the content of this ACL resource, so that's why I chose to use this assumption.

Side note: It might also be interesting to show which entities are in control of the specific resource that is requested, but this requires access to the corresponding ACL resource, and that is not something most visitors have.

Side note: There might be other entities in control of a Pod than the ones listed in the root ACL, e.g. you can argue that the people who has root access to the Pod server also has control access to a Pod. This might be something we want to formally describe at some point, but for this document I'll leave it out.

Solution 1: Link Headers

I think the easiest solution is to simply add Link Headers with some appropriate relation that would point to the various resources. Linking to root of Pod would be something similar to rel=storage (we could make it rel=storageRoot if we want to distinguish it more from http://www.w3.org/ns/pim/space#storage), and for listing controller entities we could suggest rel=controlledBy.

This is a pattern used for linking to ACL resources already, and I think this is a good way of solving this. Another advantage with this pattern is that we can reuse this logic in HTML link tags as well, making this a more versatile solution.

Example link storage: Link: <../>; rel="storage" (for resource https://solid.example.com/pod/bar where root is https://solid.example.com/pod/)

Example link controlledBy: Link: <https://alice.podserver.com/profile/card#me>; rel="controlledBy", <../../#i>; rel="controlledBy" (for resource https://solid.example.com/pod/bar where there are two controllers: https://alice.podserver.com/profile/card#me and https://solid.example.com/#i)

Solution 2: Extending the data model for containers

NSS serves a rich model today for containers, listing all items and metadata for the container itself. We could extend this model by adding triples denoting the storage and which entities are in control.

Clients would know that to find the storage for a given resource, they can either look at the container of the resource, or the resource itself if it is a container. I suggest that we reuse http://www.w3.org/ns/pim/space#storage for this, but open to something more specific (e.g. http://www.w3.org/ns/solid/terms#storageRoot).

Using this solution for controlledBy is a bit more troublesome, as a container can have a different list than the resource itself. It might be useful to show the list of controllers for the Pod itself, but apart from that we cannot rely on the preciseness of controllers listed by container of a non-container resource. Nevertheless, if we go for this suggestion, I recommend that we extend the Solid vocabulary with controlledBy.

Example triple storage: <> http://www.w3.org/ns/pim/space#storage <../> (for resource https://solid.example.com/pod/bar where root is https://solid.example.com/pod/)

Example triple controlledBy: <> http://www.w3.org/ns/solid/terms#controlledBy https://alice.podserver.com/profile/card#me, <../../#i>; (for resource https://solid.example.com/pod/bar where there are two controllers: https://alice.podserver.com/profile/card#me and https://solid.example.com/#i)

Discussions

Should controller entities be publicly listed?

The controlledBy relation would in practice circumvent a design of WAC, namely that you must have control access to be able to read which entities that have the various access modes set. The use case for not publicly listing a controller might be reasonable, and should be discussed. A solution might be to have an opt-in for entities to decide if they want to be listed, and a heavy emphasis that Pod server controllers (e.g. the team that hosts and have access to the root of the server) should list themselves publicly on the servers they have control access to.

Modified
Language
English
License
CC0 1.0
Document Status
Draft