POD directory standard

[csirgo]

As our application must access some routes that could be uploaded by different applications, we think it would be easier if all of us use the same directory to save the routes in the POD. For example, when a user uploads a route, store it in a direcory called "ViadeRoutes".

viade_es4c team

[labra]

Although I like the idea, I am not sure if it would be too limited. Some concerns that I have:

• Should all the routes be stored in the same folder?
• If the number of routes increases, maybe having all the routes in the same folder can difficult to manage and some structure would be preferred.
• What access control would that folder have?

Are there other ways to discover the folders that contain routes?

As I am not sure about what is the best practice, I posed this question to the solid gitter channel here: https://gitter.im/solid/chat?at=5e5b60f0ec379e558e9a7692

[labra]

Look at this suggestion: https://gitter.im/solid/chat?at=5e5cc3227fef7f2e89968763

I'd find/define an RDF class for Routes, then list that in a type index. Then it doesn't matter what the folder's called

[luispc1998]

This issue was requested by @labra to talk about the directory structure exposed in #21

As a summary of the related information in the pull request. We propose a viade/ folder in the root of the POD, here we should store the data related with the app. Inside it we will have other three folders: routes/, comments/, resources/. In the comments and resources folders we will be supposed to store the files, .txt for the comments, and media formats for the resources.

Why should we do it that way?

We could each of us (teams) have our own way to handle this, but supposing that one user used several of our apps, that would lead to a complex or even crazy structure of the user's POD data.

This is just a proposal that we consider pretty intuitive both for us and the user.

Talking about the index that was being commented in order to manage too many routes in the same folder. By means of the solid-file-client (https://github.com/jeff-zucker/solid-file-client) we can request for all the webid inside a folder, which we believe it is not a big computational cost. Once we have the webId we can then allow the user to load a route, which would translate into retrieving just one file from the pod.

Talking about the permissions, by using this structure we will be able to handle shared routes exactly the same way as private ones. Using Solid permissions behind the sharing function of our applications, when reading the folder /routes, users will only see those routes which they have access to. Therefore, creating other folders for shared routes or a more complex structure to handle friends' routes would not be needed.

[christianpe98]

The es4c group agrees with this proposal and will follow it. We also propose to add an inbox folder inside viade to store/manage notifications about shared routes. It should have the same permissions as the general inbox (Submitters -> Everyone).
What do you think about it? @labra @luispc1998

In the inrupt example application you can see in detail the use of the inbox folder to manage notifications and share resources.

[labra]

What happens if the route is something more private that you don't want to share with everybody and only with some friends or groups of friends?

[christianpe98]

@labra I don't know if you're talking about my proposal about the inbox in the viade folder. If so, the inbox folder would not contain the routes, it would only contain the notifications about shared routes. Example of notification flow (following the inrupt approach):

Suppose that user A wants to share a route with user B.

1. A notification is sent to user B notifying that user A wants to share a route with him.
2. User B can accept or reject the shared route.
   2.1 If user B accepts the route it will be added to the routes shared with him. In addition, user A will be notified that user B has accepted his route.
   2.2 If user B denies the route, user A will be notified that user B did not accept his route.

These notifications would be saved in the inbox.

If you are not talking about my proposal I imagine that each route(in routes folder)will have its .acl file to control the permissions given to each user. If someone shares the route with a friend, this will be added to the .acl file of the route with read permissions.

[labra]

I thought you were proposing to store all the routes in the public folder 😃

If that's not the case and you are using notifications, then it seems OK.

About defining a common folder structure, it is indeed a current issue in the Solid specification that is being discussed. You can see a similar discussion here.

The most promising solution seems to be the use of footprints. You can read more about the idea of footprints and shapes here. And there is a proposal for a specification about footprints. You can read the introduction here and the formal specification here.

It would be great to provide a formal description of the structure using footprints. I will create another issue for that.