How to share routes?

[christianpe98]

Perhaps this issue really should not be in this specification but I think it is an important point so that we are all as interoperable as possible. Our group proposes the approach followed by Inrupt (sharing routes through the use of notifications).
Explanation of the Inrupt approach:
A user A shares a resource with a user B, so user A gives permissions to user B about the resource he is going to share and user B must save in his POD the URI of the resource to be able to access it. How can user A inform user B about the URI of the resource if user A doesn't have write permissions about the POD of user B? To solve this Inrupt uses notifications.

User A sends a notification to the inbox folder of user B's POD with the share route information. When user B login the application will show him the notifications and if he accepts (this is really not necessary) the application with the login of user B will save the URI of the path in the POD of B.

We will have to decide:
1- Should we all follow Inrupt's approach and share routes by using notifications?
2- If we do it as Inrupt, what form should the notifications have and in which inbox will we save them?
3- When a user accepts the shared route notification, where will we store the URIs of the routes that they share with us?

I hope you have explained it to me fairly well. @labra is there any error in what I explain?

[christianpe98]

I'll also tell you how Inrupt answers some of these questions:

Notification Shape

The notifications according to Inrupt have this form:

@prefix terms: <http://purl.org/dc/terms#>.
@prefix as: <https://www.w3.org/ns/activitystreams#>.
@prefix schema: <http://schema.org/>.
@prefix solid: <https://www.w3.org/ns/solid/terms#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix : <https://pruebachristian.solid.community/inbox/1583248045023.ttl>.

<URI of notification> a as:<Notification type>;
    schema:license <license of notification>;
    terms:title "title of notification";
    as:summary "URI de la notificación";
    as:actor <WebID of the user who wants to share the resource>;
    as:target <WebID of the user with whom you want to share the route>;
    as:object  <URI of resource>;
    solid:read "notification read or not"^^xsd:boolean;
    as:published "sending date"^^xsd:dateTime.

(

Our group is using Offer as a type of notification

Inbox

From what we've seen, the Inrupt application creates an inbox inside the game folder (which the sample application uses to manage the game information) and sends the notifications there, although it is also able to use the general inbox of the POD. Our group proposes to have a dedicated inbox for viade.

Where do we store the URIs of the routes you share with us?

Apparently, Inrupt saves the game shares in a Turtle file and links the resources there using scheme:hasPart. We think we should do the same but instead of using scheme:hasPart use another property.

[uo265363]

We have done a different aproach with the route sharing funcionality. The user B doesn t have to accept the shared route, he can get the uris of shared routes from a file in user A pod instead writting it in the B user's pod.

[christianpe98]

Hmm looks interesting, and how would the user know all the routes his friends have shared with him?

[uo265363]

If the user A wants to know all the routes shared by his friends, A checks in their pods a file stored in viade/routes/shared/{userAwebId}.json (or .ttl if you are using turtle), which contains a list of the uris shared with him.

[sarav22]

In my group we have a folder inside viade called inbox, so we agree with that proposal. We don't accept the routes, our notifications are only to inform the user that something has been shared. I think that it is better that the content is shared directly, without having to accept anything.

[christianpe98]

#34 (comment) (Sergio)
but if you have a lot of friends it would be a pretty big workload to look at every single POD and read that file, no? Also, user B would be able to see the routes that A shares and with whom, wouldn't this be a security problem?

#34 (comment) (Sara)
Yes, at first we started to do it this way, without accepting the routes they share with you, but we found multithread writing problems. The file that saves the routes that have been shared with you is a shared resource, when you get multiple notifications and make asynchronous write requests on this file the problems start. Having to accept the routes with a button allows you to have some control over writing the file.
I'll tell you our experience. The point of accepting or not the notification I think would not give problems in terms of interoperability.

[Raulpemol]

I highly recommend discussing first the folder structure for the application in issue #4 in order not to mix up things

[themrcesi]

I think we should also take into account that the approach of using the inbox/notifications to share routes is only valid for groups using the Inrupt generator... It will be difficult to accomplish that approach for the groups that don´t use that template.

I like the solution proposed by @uo265363 .

[uo265363]

@christianpe98 There is no security problem, the user B can read only the file with his webId, the folder itself can not be readed without read permission, so A can't see the files inside. I dont see this as big workload neither, it s just one more file fetch for each friend.

@Raulpemol I think we should first discuss here if sharing routes needs an auxiliar folder for working properly without having security issues.

[InigoGutierrez]

We talked about this and decided on either make copies of shared routes, so they are independent of the creator, or writing the URIs, so they stay as a reference. I think writing URIs is ok and it seems everyone is taking this approach.

About where to store them, we decided on storing on a user's pod the routes shared with them, having a specific folder with global writing permissions. This has also been proposed here.

About notifications, as @themrcesi stated, it can be difficult to deal with them for groups not using the template. We think directly writing the URIs of routes is the correct approach.

Also, note than when a route is shared, its permissions have to be changed for the receptor of the route to be able to read it.

[uo265363]

@InigoGutierrez If an user A shares a route with a user B, the uris are stored in the B's pod?There is problem with that. If A shares a masive number of routes with B(maybe trying to atack him), The pod size of B could get to it's limit, so if another user try to share something with B he wouldn't be able to get those routes.

[christianpe98]

@themrcesi @InigoGutierrez To implement the approach of sharing resources through notifications it is not necessary to use the Inrupt generator, you only need to use the hook useNotification() which is in the solid-react-components library (which I imagine many of you already use).

@uo265363 Okay, I think I got it.However, I'm still not convinced at all, if I have 100 friends and I want to see the routes that they have shared with me I have to make 100 requests to the server to read, if it exists, the viade/routes/shared/{userAwebId}.json. file of each friend. Wouldn't that take a long time? And wouldn't it be the responsibility of storing the URIs of the routes that each friend shares with user B in the wrong place? Because for example, if user A is no longer accessible you would lose the information that he has shared routes with you.

[uo265363]

@christianpe98 I think I did not understand correctly what you are proposing then. Can you explain it in more detail?