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?

[luispc1998]

I will reformulate what has been exposed in #4 about this topic, and what some people here considered a good approach. I will also comment some of our architectural decisions.

We have identified some ways of solving this issue, I will be commenting some of them.

Route Folder Permissions

This is what we are doing now in our app. Managing the permissions of the viade/routes directory and the files inside we can cover this functionality. Assume that wants to share a Route with Sara. Let's see what can be done. Luis will give Sarah reading permissions to the viade/routes directory and then give reading permissions to the route file. By means of the solid-file-client module Sara can list all the webIds in the folder. You may not have access to all the routes, so it will necesary to check over which of those webIds the current user, in this case Sara has read permissions, and only show those to the final user.

Advantages and Disadvantages

It is clear that this is a pretty simple approach, both for programmers and for the pod owner, since there would not be a large amount of artificial app files. We have a disadvantage though, continuing with the example Sara would be able to list Luis viade/route folder, being able to read the names of the files inside.

Tradeoff decision

Since the names of the files does not really provide a piece of information, being just a webID, we believe this is not a security problem. Consider that in real life you may have URLs but the server can deny you the access to it, it would be exactly the same approach.

A file in Sara's POD per friend

In this example when Luis wants to share a Route with Sara he will go to a specific folder in Sara's POD, let's call it viade/shares, and there he would have to update a file related to himself, where he must list all of his route Sara has access to.

Tradeoff decision

Sara would have to give writing permissions in that folder to everyone, since SOLID friends system is not reciprocal, and so she doesn't know who may share a route with her. We believe this is a really bad approach. (You may even fill that folder with non relevant files)

A file in Luis' POD

In this approach Luis will have a file per friend in a folder, let's call it viade/shares. This file will have some easy identifier of Luis friend in this case Sara, something such as the webID. Let's explain how this would work. Again Luis wants to share a route with Sara.

Luis must give Sara reading permission for the route file, he should add her to the corresponding file in viade/shares, if such a file doesn't exist, he would have to create it, following a convention, in this case, Sara's webId.jsonld (just an example). He must also provide reading permissions for the viade/shares folder and for the file that points to all the routes shared with Sara.

Sara will have to check first if she can list the folder (that condition is met is at least Luis have shared one route with her). Then she checks the corresponding file, and get the webIds of Luis's routes.

Tradeoff decision

This approach is pretty much the same as the first one. In the end we need to allow the friend to read the route file. What this solution provides is that you doesn't give the webId of your routes, but in the end you are now giving the webId of the sharing files. It's the same issue in other place, and complicating a lot the design.

Variant

There exists another way to follow this idea, but you will have a file and inside the links of all your friends, we believe that is an awful approach but we must say that we considered it too.

Conclusion

We concluded considering that the best approach was the first one, even though at the beginning we were a bit concern about that. Consider real applications, for instance social networks. Here you may see which are other people friends, count them an so on, seeing this we considered that being able to know the amount of routes of a person, may be even useful in some cases, for instance statistical research.

Hope this proves useful to you guys.

[uo265363]

I just want to point that there is a little mistake with the "A file in Luis' POD" version. The 1st aproach's issue does not happen here. The viade/share doesn't have read permisions, so you can't list the webIds inside, you can only get the file by using its uri directly, and that file is always named with the user id, so you can always get to it without need to list the folder before. But anyway, I see a fair tradeoff between the aproachs and we don t have any problems with using the first one to ensure interoperability.

[luispc1998]

That's true, thanks.

[christianpe98]

@luispc1998 there're another approach, the Inrupt's approach.I'm going to try to explain it as best I can, although my English isn't especially good XD.
@uo265363
I've made some diagrams that can help understand how the inrupt approach works.
https://imgur.com/a/pVcKv7l

The Inrupt approach is very similar to A file in Sara's POD per friend approach that @luispc1998 explains,the difference is that it solves the problems that Luis indicated. Before I explain, I'll clear up a few things:

• In the inbox folder any user can add information, but cannot read or delete anything from the inbox (except the owner of the POD).This is because it has Submitter permissions for Everyone.
• A notification will contain URIs of the route to be shared and more data (owner's route WebID, date,title,summary ...)
• Through the hook useNotification() you can send and read notifications(and more things).

So ,following the examples of Luis:

1. Luis wants to share a route with Sara so the Viade app sends a notification(it will contain the URI of the route, Luis webID,...) to Sara inbox (Luis cannot read/remove anything of the inbox of Sara so there isnt a security problem). Also the application will give Sara reading permissions on the route

2. When Sara logins into Viade App, the app reads the inbox of Sara's POD and shows her the notification that Luis wants to share a route with her.

3. If Sara accepts the notificacion, the app copies the route's URI into a file in viade folder.This file will contains all the URIs of the routes they shared with Sara. So when Sara wants to see the routes they shared with her, she'll just have to read that file.

Advantages

• No permission should be given to Luis, as the default inbox is sufficient.
• Sara has on her own POD the URI's of the routes that share with her.

Disadvantages

• Working with the hook can be tricky

[luispc1998]

Due lo the lack of participation in this issue which we consider crucial for the interoperability. We have done a form: https://forms.office.com/Pages/ResponsePage.aspx?id=o3TqBcWSMUyXipJcPHmc0BAg91QvzdpOkrb4dXEp4URUNTJHRDlETlpSV0hJNjhRREtOVjM1U0lCVS4u

[uo258865]

I have one question about the idea of Use pod permissions. In this idea, is notifications useful? I mean, the notification is only to tell that X person has share you a route, right?

[uo258865]

And another question, in this idea "Use inbox folder", do we have to decide a specification for the file, and use the same format like Turtle or JSON-LD?

[luispc1998]

For your first question that's right, the notification will just inform the user, since that information will be available for him even if he doesn't read the notification..

For the second one, I guess so, but nothing was said about that yet. We would like to comment it more and see which is the most fitting approach.

[luispc1998]

You may check the results in the following link: https://forms.office.com/Pages/AnalysisPage.aspx?id=o3TqBcWSMUyXipJcPHmc0BAg91QvzdpOkrb4dXEp4URUNTJHRDlETlpSV0hJNjhRREtOVjM1U0lCVS4u&AnalyzerToken=CDvAMpKexCTlKHR4SfyhmYzBpRJSCIR3

My group didn't vote, so it would be a 5-5, however since we believe that there is no time to discuss it more, we will be trying the inbox folder approach, so that would be a 4-6.

It was commented in this post the following by @christianpe98:

3. If Sara accepts the notificacion, the app copies the route's URI into a file in viade folder.This file will contains all the URIs of the routes they shared with Sara. So when Sara wants to see the routes they shared with her, she'll just have to read that file.

However there is no specification in this repository about such a file, should we have uploaded a simple approach to this issue in our pull request #21 .

[Raulpemol]

In fact it doesn't really matter which format is used in the rest of the application in order to use one or another here. If we use the jsonld as proposed for this fact, it doesn't affect the rest of the application. So in order to discuss which format to use for this file, please let's just think about this particular case and do not mention the format that each of us use to store routes.

[christianpe98]

Interoperability

If we want the notification and route sharing system to become interoperable, i think we will have to decide:
1- Where will we place the inbox folder? Do we use the global one or do we create one inside the viade folder?
2- What format should the notifications have? Although using the hook useNotification already partially solves this problem, I think we should choose some parameters such as the type of notification and license (I think the rest of the elements are not relevant)
3- About the file that will save the URIs of the routes: What name and extension will it have? Where do we place it? Through which vocabulary do we express which user has shared which route with us?

My opinion:

1- We should create an inbox inside viade so that if the user uses more applications the notifications don't get mixed up.
2- In my group we use Offer as a type of notification and as a license: https://creativecommons.org/licenses/by-sa/4.0/
3- I'll break down the third part:

Name

In my group we are using: shared_with_me

Format

The file should have an extension that is an RDF serialization, Turtle or JSON-LD . I think that users that use Turtle for routes should continue to use Turtle for this file and those of JSON-LD that continue with JSON-LD, this way the only interoperability problem that exists would be fixed by parsing.

Where

I think the file should be inside viade at the same level as the routes,media,comment folders.

Vocabulary

idk, We'll have to investigate schema's vocabularies

---

This is all my opinion. Maybe some of you probably have better ideas.

[Raulpemol]

We agree with an Inbox folder inside Viade, where these notifications would be stored.

We don't think that having a unique file for all the URIs is a good idea. It is more common that a user will have more routes shared than friends, so having a file per friend would be the best solution in our opinion. If you want to retrieve all the routes that a friend has shared with you, you would have to parse a huge file in your case.
Regarding the format of those files, please note that as I previously said, the format used to store routes is not relevant in order to decide the extension of this one, as they have nothing in common and nor they are related in any way. These are just simple files to store the uris of some resources. Therefore, having to create another parser because each group writes them in a a different format would be a really dirty solution. I strongly believe that we should reach an agreement for this particular files regarding their format.

[uo258865]

I agree with @Raulpemol that it could be more useful if we use a file per friend.
So, to be clear, it would be in root the viade folder. Then we have viade/routes for the routes, viade/inbox for the notification, and viade/share where we have a file per friend, right?

[Raulpemol]

Yeah, that's what I believe would most appropriate. Just to make the point as clear as possible, instead of a file per friend, it would be a file per person that shared a route with you, as some friends may never share any route with you. Once, the first route is shared, the file is created.

[christianpe98]

@Raulpemol Having a common format for the file/s looks right.
About having a file for every friend who's shared a route with you, I don't completely agree. It's a good idea but as we consulted the server I think it would be much slower than if the routes are all in one file.

x: file reading time
y: folder reading time

One file with all the URIs(A)

1. Read the file and obtain the URIs => x
2. Read each URI and get the data of the routes => x * number of URIs

Total time: x + x*(NºUris)

One file per person that shared a route with you(B)

1. Read the folder containing the files and get the URL of the files => y
2. Read each file and get the URIs of the file => x * number of files
3. Read each URI and get the data of the routes => x * number of URIs

Total time: y+ x*(Nºfiles) + x*(Nºtotal Uris)

Comparison

To simplify, we'll eliminate the constants:
A=x+x*(NºURIs)=x*(NºURIs)
B=y+x*(Nºfiles) + x*(Nºtotal URIs)=x*(Nºfiles) + x*(Nºtotal URIs)=x*(Nºfiles) + A

The complexity of approach B is higher than that of approach A

Correct me if I'm wrong about anything, that I'm a little out of practice XD.

[InigoGutierrez]

The problem of having only one file with all the URIs is that everyone has permission over that file. When having one file per person, only that person can mess with that file.
EDIT: I was wrong about this, these files are not shared with anyone.

To simplify, we'll eliminate the constants:
A=x+x*(NºURIs)=x*(NºURIs)
B=y+x*(Nºfiles) + x*(Nºtotal URIs)=x*(Nºfiles) + x*(Nºtotal URIs)=x*(Nºfiles) + A

The complexity of approach B is higher than that of approach A

Why arbitrarily eliminate those first constants? The idea you are trying to convey, correct me if I'm wrong, is that:

A depends on NºURIs
B depends on Nºfiles + NºURIs

While on B more files are read, the complexity of both approaches is the same, O(n). Therefore, i would rather not discuss on choosing one or the other based on efficiency, since you know what they say: premature optimization is the root of all evil.

[christianpe98]

@InigoGutierrez That's right, my mistake.

[Angelixus]

My teammates and I were discussing both approaches and we came to the conclusion that they have little to no differences the only important one we identified is that the approach of having several files is more robust to failures (e.g corruption of files or accidental deletions).

[uo258865]

I dont understand the point because i thought that the idea was: i receive a notification, and i accept, i copy the webid of the route that is in the notification in the file of the person that has shared me his rout, so i don't know why the other person has to have permission

[Raulpemol]

Yeah you are right Inés, I also believe that's a better approach.

[uo258865]

I just realized that the name of the file in the 'shared' folder has to be common. One idea would be that the name is the webId of the friend, since nobody is supposed to be able to read it (only the owner) and it doesn't matter... but I don't know what you think

[Raulpemol]

I think it could be better to use the whole domain name of the POD, such as "username.solid.community", because more than one person may have the exact same name.

[InigoGutierrez]

Won't there be just one file in the shared folder containing the URIs of routes shared with the user? Regarding the name, we are calling it sharedRoutes.jsonld, but we should also decide on a common name, this one or another.

[uo258865]

I thought it had been agreed that it was better to have one file per friend, leaving aside the complexity although it was defended that it was the same.

[uo258865]

If it's only one file, sharedRoutes would be a good name

[Raulpemol]

Yes, our group also believed that that approach was the one agreed.

[Raulpemol]

Leaving the complexity aside, the one file approach wasn't supported by any other advantages.

[uo258865]

I think it should be discussed soon, because there are groups like mine that don't use JSON-LD on the routes, and parsing the json-ld will delay us a little more...

[Raulpemol]

Yes, there shall be a final decision soon. However, don't worry about parsing jsonlds, as the JavaScript JSON object does all the work for you and you just need to get the value from the desired field. It should be very straight forward.

[uo258865]

I think that if the @InigoGutierrez group started to do it with one file for all the friends, we can continue with that idea since they have started to implement it. The idea of a folder inside 'viade' called 'shared' and inside a file 'sharedRoutes.jsonld' seems to be good. The only thing I have doubts about is the specification, I don't know how it would be an example of several shared routes.

[Raulpemol]

I don't know if I have understood it right, but we have also started implementing it using a file per friend, and I am sure that many other groups have also started doing it following who knows which approach. I am sorry but don't follow that reasoning.

[uo258865]

Well, this should be discussed among those of you who have started, because, for example, my group was waiting for a joint decision, so we don't care

[uo265363]

Our group prefers 1 file per friend. And what's the point on having a single file in a shared folder?

[uo258865]

Yes, I just thought of it and it doesn't make sense if it's just a file that's inside the folder 'shared' and that the folder exists.
So we have two options

1. File per friend: File per friend, inside a folder 'viade/routes/shared/{webIdOfFriend}.jsonld'
2. Single file for all the friends: Single file for all the friends, inside 'viade/sharedRoutes.jsonld'

[InigoGutierrez]

We took this approach trying to conform to the specification currently presented in the open pull request, but reviewing it I think I misunderstood it. It is confusing and should be changed: it first talks of having several files, not specifying what for (I suppose that the intended explanation is having a file per friend who shared a route) and then showing an example of a file with routes of different owners, which conveys the idea of having all the routes of every sharer in the same file.

We should agree on this soon, and we acknowledge that some groups have already implemented it in one way, some in another. I sincerely find it much easier to have just one file (probably not inside its own folder since this wouldn't make much sense) since that file will not be shared with anyone and adding and reading would not have to deal with parsing several files or having to choose the correct file to add a route to, when in the end all will have the same behaviour.

[uo258865]

I don't have much idea about jsonld, so I can't say if it's easier to do queries if there is one file with everything or if there are several files.
I think that if there is only one file, it would be a good idea if we use a list. Like any rdf it has to consist of subject, predicate and object. Obviously the subject is the webId of the friend who shared you, the object is the webId of the path, but the predicate I don't know what it could be. I found this
{
"@context": "http://schema.org",
"@type": "ShareAction",
"agent": { //The friend
"@type": "Person",
"name": "FriendWebId"
},
"recipient": { //You
"@type": "Person",
"name": "myWebid"
},
"object": {
"@type": "Text",
"name": "routeWebid"
}
}

[Raulpemol]

In the active pull request you can find since a couple of days the format proposed for the file that I believe you are talking about. Please note that if the current "several files" approach is followed, the owner of the route is obtained by the name of the file, so the json will just be a list of uris.

[uo258865]

Yes i saw the format proposed but i thought that ShareAction would be better than Offer, but it was only an idea

[uo258865]

And do you have a proposal for your idea? @Raulpemol

@InigoGutierrez I think that your proposal is good but type Offer is not a good one because we are not offering, so i think it would be better what i said, ShareAction.. I don't put it in the proposal because i want to know your opinion about that because it's your proposal.

I know we have to agree but if we don't decide it early, my group will start with one of those propose because it's getting late.

[Raulpemol]

Of course I have, I've already told you that it is in the pull request and I have also explained how it is supposed to work. Or what do you mean?

[uo258865]

I'm sorry i didn't see it because i was looking in the comments. You mean this, right? [https://github.com/Arquisoft/viadeSpec/blob/POD_Data_Management_Proposal/main/jsonldProposal/sharedRoutesExample.json]

[Raulpemol]

Exactly, that one.

[uo258865]

Okey, i saw it was proposed 7 days ago so i'm gonna try to follow yours specification.
So, to sumup, the files are in the folder viade/shared and the name of the files is the corresponding part of the webID of the friend.