In its current form, PASS renders the list of documents from Solid in React through the doclist.ttl stored in the Documents container in PASS. As users add documents to their Pod on Solid, the doclist.ttl expands, storing the location of where the uploaded file is stored along with relevant metadata.
In this process, the Upload button in the Add Documents Modal triggers addDocument from src/modal-helpers/DocumentList.js and updates the list on both Solid and React. In React, the list comes in the from of a list of objects called docList (which is also located in DocumentList.js under loadingDocumentList).
While this approach works great to reduce the number of API calls needed to display what document files are in Documents, this document list on Solid works only when users have access to the entire Documents container even if users can get permission for individual files. An alternative approach would be needed in order to allow for file-specific permissions.
Proposed Changes:
There are several approaches I could think of at this moment that's within Solid specifications.
The 1st approach would tackle the issue in a way similar to how PASS had previously implemented document uploads. That being, each file will be stored within a container of the same name along with the metadata (likely in the form of a TTL file) and an ACL file. Each container would be called individually, but we could generate a list that contains specific files other users could have access to when shared. For docList.ttl, we could still use this when the full container is allowed to be shared.
The 2nd approach would tackle the issue by creating new docList.ttl that are user-specific. For example, if we want to share a specific file from the document list, we could generate a new TTL file with the name of the user that is being shared to. For example, if the user wishes to share a document with http://localhost:3000/testpod/profile/card#me, we can create a new ttl file with a name generated using the webId inside Documents. From the client, we can use the parsed form of our document object to generate that list similar to how we create a new list when uploading documents. As for displaying the document list of users who have shared their files, we can have the other user (i.e. testpod) generate a document list using that new document list file instead of docList.ttl, unless the Documents container itself has been shared.
Rationale:
To generate a document list that allows for file-specific permissions.
Possible Drawbacks:
Each approach do have their own drawback. The first approach would be traffic-heavy, with each file needing its own API request from Solid. The folder structure for Documents would also need to be re-worked with utilities functions from the client which would help these containers generate a list of objects similar to what we had now with the existing approach.
For the 2nd approach, while it'll keep the file structure flat inside Documents, would generate a lot of TTL files inside Documents. The name of the new document list ttl files needs to be systematic, utilizing some aspect of the other person's webId, and easy to fetch back like with docList.ttl
Describe the Current Behavior/Feature:
In its current form, PASS renders the list of documents from Solid in React through the
doclist.ttlstored in theDocumentscontainer in PASS. As users add documents to their Pod on Solid, thedoclist.ttlexpands, storing the location of where the uploaded file is stored along with relevant metadata.In this process, the Upload button in the Add Documents Modal triggers
addDocumentfromsrc/modal-helpers/DocumentList.jsand updates the list on both Solid and React. In React, the list comes in the from of a list of objects calleddocList(which is also located inDocumentList.jsunderloadingDocumentList).While this approach works great to reduce the number of API calls needed to display what document files are in
Documents, this document list on Solid works only when users have access to the entireDocumentscontainer even if users can get permission for individual files. An alternative approach would be needed in order to allow for file-specific permissions.Proposed Changes:
There are several approaches I could think of at this moment that's within Solid specifications.
The 1st approach would tackle the issue in a way similar to how PASS had previously implemented document uploads. That being, each file will be stored within a container of the same name along with the metadata (likely in the form of a TTL file) and an ACL file. Each container would be called individually, but we could generate a list that contains specific files other users could have access to when shared. For
docList.ttl, we could still use this when the full container is allowed to be shared.The 2nd approach would tackle the issue by creating new
docList.ttlthat are user-specific. For example, if we want to share a specific file from the document list, we could generate a new TTL file with the name of the user that is being shared to. For example, if the user wishes to share a document withhttp://localhost:3000/testpod/profile/card#me, we can create a new ttl file with a name generated using the webId insideDocuments. From the client, we can use the parsed form of our document object to generate that list similar to how we create a new list when uploading documents. As for displaying the document list of users who have shared their files, we can have the other user (i.e. testpod) generate a document list using that new document list file instead ofdocList.ttl, unless theDocumentscontainer itself has been shared.Rationale:
To generate a document list that allows for file-specific permissions.
Possible Drawbacks:
Each approach do have their own drawback. The first approach would be traffic-heavy, with each file needing its own API request from Solid. The folder structure for
Documentswould also need to be re-worked with utilities functions from the client which would help these containers generate a list of objects similar to what we had now with the existing approach.For the 2nd approach, while it'll keep the file structure flat inside
Documents, would generate a lot of TTL files insideDocuments. The name of the new document list ttl files needs to be systematic, utilizing some aspect of the other person's webId, and easy to fetch back like withdocList.ttl