Add your comments directly to the page. Include links to any relevant research, data, or feedback.
Background
The usage policy class “Restrict: for specific purpose” constraints data to be transferred if the containerised application is verified to not have changed. The change in the containerised application is detected by comparing its hash at run time with the hash at the time when connector was configured. It was assumed in the product design that the containerised application in the choice of programming language (node/python/ruby etc) can be created in a no code manner through the click of a button referring to the github repository. It was realised that this is not possible in a no code way and therefore the flow and user actions need to change.
Relevant data
The sequence for creating a containerised application as thought earlier:
Consumer can share a github or similar repository of a node/python application for review to provider
Provider can verify the repository and approve
Consumer can containerise the approved application repository
Hash of the container is logged by FS at this point and stored at provider’s end as well
Provider shares data through connector and the exchange takes place only when hash has not changed
Issues:
How does the repository approval take place?
Single click containerisation not possible implying the consumer needs to create the container outside FS environment and therefore can change the repository after approval.
Options considered
Option 1: | Option 2: | |
|---|---|---|
Description | Trusted third party is where application repo is uploaded by the consumer with provider’s address and once provider approves the same, trusted third party creates a containerised application | Prepare guidelines for the developers of consumer application and ask them to strictly adhere to the guidelines. Also, step-by-step instructions could be created for consumer to containerise and upload the application as well as security hash. |
Pros and cons |
Takes away the effort to containerise application from consumer Can scale in future with service provider acting like a “play store” and also as approver for advanced applications
Need to publish/ show code to trusted third party (similar to Android application) Another actor in the ecosystem - governance needs to be sorted out |
Effort is minimised for containerisation for the consumer. No need for a third party intervention and submission of code to someone else Easy integration of application into the ecosystem with other applications.
Puts the onus on containerisation on consumer who may or may not have their own developer team. Consumer might not follow all the guidelines and hence could result in incompatibility of application with trusted connector |
Estimated Effort | LOW for building farmstack MEDIUM for building processes | MEDIUM |
Action items
Following action items to take decision:
- Mayank (Unlicensed) Come up with further options if possible
- Mayank (Unlicensed) What would be the long term implications for purely third party player instead of FS?
- Mayank (Unlicensed) Input for UI design based on the decision
Outcome
Since we are working with only a few partners for the starting phase, Digital Green can act as the trusted third party. Another important aspect to think of while containerizing could be analytics and usage patterns of the applications.
Add Comment