Page Comparison

...

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
  - Tokens
  - NFTs
  - UX 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