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?
- It depends
- What about gaps that are "features" rather than a stand alone project.
- Big question is can the project stand alone?
- How close to DLT core code do projects need to be?
- example: application frameworks, such as a Ruby on Rails for DLT Apps.
- Things have changed in the past 5 years
- There is less resistance to going "up the stack"
- Still in the early days, patterns up the stack are developing
- Natural evolution to expand the scope
- Scope of added features is going down for DLTs
- Where are the exciting things happening?
- Some projects went outside of HL because apps were out of scope
- Sometimes because of domain expertise too
- What gets people excited to house their projects on HLF
- Do we want to invite projects that fill gaps?
- 80/20 brownfield vs greenfield (maybe close to 100%)
- Most major projects came in with substantial code at first commit
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
- Specifications tend to be different from Standards
{"serverDuration": 94, "requestCorrelationId": "2cd04212011d8f15"}