Purpose of this document
Provide the Farmstack goals and vision of what it eventually would turn out. This is not a one time document but a living doc which will change over time as we gain more understanding.
What is FarmStack?
FarmStack is a
...
reference implementation of an open and interoperable data sharing protocol in agriculture sector. FarmStack enables network of data providers and consumers through a suite of products and functionalities:
Share data directly
...
without any third party through
...
trusted peer to peer (p2p) connector
...
Empower the data provider to
...
restrict usage of data through usage policies
Give control of data back to the farmers by managing consent using data wallet
Enable entities to create plugins to make their data discoverable
...
(description of data)
...
FarmStack is the sum total of all the peer to peer connectors and associated usage policies.
Why is FarmStack required?
FarmStack is required because:
...
Relevant farmer profile
...
including farmer activity
...
not available
...
Lack of trust on misuse or under
...
utilisation of data
...
with a centralised data warehouse
Need to comply with evolving data policy and privacy safeguarding measures
...
Existing data integration tools lack the customisation
Value generated by FarmStack
By combining specific datasets, better services or products can be created
...
Organisations can discover what data resides with whom to foster collaboration
Potential to unlock value of data that was previously considered not shareable
More
...
feedback from
...
lead to more enriching
...
solution
...
- giving rise to virtuous cycle
...
How does FarmStack network look like?
A typical FarmStack network looks as below with three distinct roles the actors in the network can play. Farmers are the end beneficiaries who consume services offered by one or more participants and can have their data wallet using which they manage consent to share data to specific organisations in return of anticipated returns. The participants are the organisations that maintain the data for the services they provide and exchange data. They run the FarmStack software on their own premise to manage connectors using which they enforce usage restrictions as per the consent. The participants get access to the software once they register with the steward who maintains and oversees the network.
Important links
Community governance
Business roles in FarmStack
Roles | Activities | Interface | Incentive |
|---|---|---|---|
Farmers | Manage consent to share data that could be managed by self or an organisation | Data wallet | Control data Get connected to services |
Participants | Organisations that exchange data and manage connectors and usage policies based on consent | FS Participant | Respect farmers' rights Offer better services |
Steward | Nodal agency who manage subscription of the participants (issue certificates, logs transactions etc) | FS Steward | Drive data sharing policies Sustain a network |
How will someone use FarmStack?
There are two ways to
...
set up FS participant software: a) obtain the FS participant software from the first steward, Digital Green and start managing the connectors and usage policies or b) service based model where FS team from Digital Green can deploy the
...
software for interested participants and hand over. There is no difference between the two in terms of functionality of data exchange
...
.
Available resources:
...
Code repository to see how the software works
FarmStack Website to sign up and register
Help guide to set up
...
FS participant and FS Steward
Documents
Tutorials
Videos
Fs participant/ steward UI to
...
Configure p2p connector
Container network
Services (endpoints, auth mechanism etc)
Routes
...
UI to configure usage policy for consumers
...
UI to manage activity log
...
UI to manage certificates
...
UI to manage which catalog service to be used
Configure usage policies
Manage participant subscriptions and certificates
Manage team members
Examples of policy based usage control (not comprehensive list)
This is just to give examples of usage policies for the purpose of documentation. This is not the immediate usage policy.
Below are the categories of use cases and examples for that
...
.
...
Not visible
...
, that is, available for some operations
...
by a containerised application only
Usage of data fields restricted to specific operations like joining
Usage of data fields restricted to specific operations requiring logging
Usage of data fields restricted to specific operation
...
for a limited number of times
...
Revoke usage
Delete data
Usage of data fields restricted to specific operations for a certain time period
...
Revoke usage
...
Visible with constraints
...
Only some part of data available for viewing for specific time period
Revoke access
Delete data
Specific data fields can be viewed by specific persons in specific organizations
Shareable with constraints
Can be shared to specific
...
organisations with them only able to view or perform specific operations
Can be shared with logging and notifications
Can be shared
...
for limited number of times
...
Revoke permission to share
Delete data
Can be shared for a limited amount of time
...
Revoke permission to share
...
Can share only specific data fields
Downloadable with constraints
Can download specific data fields
Stored with constraints
Can be stored but in encrypted form at specific instance
Can be stored for usage only for specific operations
Can be stored for usage only for specific time and operations