🛣
Roadmap
To get more information on Roadmap, please click: https://app.zenhub.com/workspaces/guardian-618c27c08661c0001461263a/roadmap?invite=true
Create a facility to define 'higher-order' (than blocks) Policy constructs thus enabling the creation of pre-build policy modules which can then be linked together to compose end-to-end policies, without needing to understand the low-level details of 'blocks' and 'events'. The following are other constraints/parameters of this functionality:
- modules have clearly defined purpose and function
- modules have API specification, i.e. ingress and egress events and documents they consume/produce
- modules are published with attribution of the source/author, can be 'imported' and 'exported' from Guardian instance
- modules can be run on separate 'workers/services' within a single logical Guardian instance, enabling optimal scalability setup (i.e. 1a single instance of the module running in one small-powered service for 'onboarding projects', and multiple 'MRV processing' module instances for aggregating data and minting tokens.
All heavy process backend service need to be able to run load balancing and handle task lock.
Introduce the following functionality in the Guardian:
- Facilities to mark some fields as private (in schema)
- VC documents based on the schema with 'private' fields do not get published as is, instead they are encrypted with the owner key and published encrypted
- VC documents with 'private' fields use BBS signature
BbsBlsSignature2020method instead ofEd25519Signature2018 - VPs derived from VC documents with private fields will contain 'cut down' VC only containing public field, signed by the BBS signature as per above.
Design and implement the process for submitting 'supportable' policies containing:
- Policy user guide and description
- Automated policy workflow, with valid sample MRV data or MRV data generator/simulator
- IPFS timestamps, .policy files
- Requirement to run tests before sending Guardian the policy, including backward compatibility tests
Create a tagging system with the following properties:
- tags can be created by any actor with a valid DID.
- created tags should be credentialed, i.e. it is clear who and when created or added to a particular tag.
- tags can have cumulative scores, i.e. two people independently creating/assigning the same tag to the same artifact results in both tagging actions recorded (credentialed etc), and the 'tag score' is then counted as 2.
- It is possible for users to untag the item, however this action does not remove the record of tagging in the first place it just records the action of untagging (also credentialed), and reduces to score by 1.
- tags should be associate-able with any identifiable entity/thing/artifact that guardian uses and/or produces, such as:
- actors, including SRs (i.e. DIDs),
- schemas
- policies and policy modules
- VCs/VPs,
- tokens,
- smart contracts (i.e. addresses).
- tags can be created after the (immutable) artifacts are produced, therefore tags are external to artifacts.
- it should be possible for DIDs to create and/or follow tag ontologies containing the definition of description of tags.
- tag registry[-ies] should be discoverable and useable by automated indexing systems.
- Support the use, from inside the policy, of VCs/VPs produced by other Guardian instances published in IPFS.
- Support other Guardian instances' APIs as sources of the data
- Support integration with Google geo-location API
- Implement integration with these 3rd party data providers (may be similar to IPFS/Hedera integration), such as:
- policy can easily add such 'integration' to their policy - potentially using the new policy modules functionality Linkable policy modules for constructing end-to-end Policy workflows #1657
- the data can be defined as mandatory or optional (by the policy author)
- data imported into Policy artefacts is stored and displayed in its native format, preserving 'mime type' and/or any other indication of the nature of the data as well as the identity/credentials of the source, time/date and other identifying information as appropriate
- Continue working on enhancing policy definition language to enable new capabilities in policies
- Re-engineer policy creation workflow to simplify the tooling for non-programmer users potentially using such approaches as
- wizard-base workflow
- data definition enhancements in schemas enabling more precise specification of expected data formats
- support for new data types (like 'spatial' etc) which are useful specifically in the ESG domain.
- auto-suggestion mechanism (for 'next' block or other policy language constructs) based on the structure of existing policies
- syntax highlighting of JSON policy definition view
- Add new reference UI tools that would simplify comprehension of policy and its execution results for complex use-cases such as those with multi-benefit projects with multiple tokens and multiple MRV sources
Policy comparison tool to be adapted and enhanced to recognize the linked policy modules and display useful differences, statistic and analysis for compared policy instances.
Develop and demo a Guardian policy that allows companies to mint CETs and develop GHGP-compliant tokenized GHG inventories.
Develop a Guardian 'Oracle' service to produce (at least) a verifiable binary valid/not valid answer for a given token or group of tokens reachable from within the smart contract, which can then form the basis conditional operation inside the smart contract.
Using a combination of HTS and HSCS capabilities develop a consistent system which enable policy creators to specify rules and parameters of the minted token lifecycle such that:
- rules are enforced regardless of whether Guardian is used or not for token management
- rules and their parameters can be changed by the SR that originally minted the token
- anyone can create additional sets of rules and any holder of the token can agree to follow them, thereby imposing on yourself these additional rules. Such rules cannot overwrite the original SR rules, the validation is effectively performed in a sequence:
- additional rules applied for validation of the attempted action
- SR rules applied
Create a Guardian policy that quantifies and reports GHG emissions from HBAR, using the GHGP product Standard and ICT Sector Guidance for guidance and requirements mapping.
Last modified 4d ago