Structural Questions
- What is the viability/appetite for "single chain" top level projects?
- i.e. a project that only runs on fabric/besu/indy/<non-hyperledger-dlt>
- Should it be top level? Some limited scope? A sub project of the chain?
- If sub-project, are they subject to parent's maintainer and other policies?
- What about gaps that are "features" rather than a stand alone project.
- How close to DLT core code do projects need to be?
- example: application frameworks, such as a Ruby on Rails for DLT Apps.
Grouping from Discovery Sessions
- End User Focused Projects
- Wallets
- Secret Storage/Vaults
- Credential Storage
- Varied scope of end user
- Enterprise at scale
- Single User/Single account
- Departmental, Team, etc.
- Applications
- General App Feature Libraries
- Domain specific toolkits
- Supply Chain (Grid)
- Provenance
- Exchange, DEX or CEX
- Cross-chain interoperability
- private/private
- public/private
- public/public
- Operating and running a chain
- Alerting
- Monitoring Dashboards
- Integration into enterprise data systems
- Tools to set up chains
- Protocol
- Common Consensus interfaces
- New DLTs
Out of scope
- Operating a public network
- Hosting a specific application
- Standard process work