2022-04-19 Off-Cycle Work Session

Notes from governing board
We had a conversation with the governing board yesterday. Here are my rough notes from that meeting:

* Oversight/governing
* Interoperability
* Manage across multiple chains
* What a DLT stack looks like and coverage of where we have coverage an where we do not
* Integration with enterprise systems
    - Secrets management/vault
    - Operations alerting/consoles
    - Events processing
* Connectors to Data analytics/Data reporting
* What are the swim lanes that DLT should stay in?
* Consensus library - defacto standards work
* Application level projects - supply chain, identity, tokens, provenance - projects that support application areas
* Crypto - making it user friendly
* Cross-chain wallet

Application Layer perspective from sigs

• 8-9 sigs across a whole lot of activities
• Mix of technical and non-technical
  • ex: Climate Sig, wanted to form "Grid of climate" - doing a methane tracking blog post with a solution
  • ex: Business focused
  • ex: Telecom is research focused, not seeding code, publishing papers
  • ex: healthcare went from technical to non-technical
• Look at blog posts and see if there are project level potential ideas
• Some are marketing an existing solution, some are trying to create a market.
  • Are there things we can do yo encourage them to create projects?
  • One sig came to TSC asking for project help and didn't have success
  • Lack of TSC engagement has lead some sig leaders to leave
  • Some sigs need HLF and tech help
• If sigs are a group of business people discussing it's difficult to get them to produce technical content (code)
  • May be lacking technical members in SIG to produce the technical content
  • Existing sig members may not be a good place to directly recruit technical members.
• Perhaps we should directly engage SIG chairs.
  • Have individual TSC members go to the sigs.

There are project ideas that exist that cannot find technologists, and similarly projects that can't find business areas.  There is a match making disconnect.

Technical Audiences for projects

• User
• Application Developer
• Network Operator
• Network Implementor
• Protocol Developer
• DLT Researcher

Network Operator/Implementors tend to have a lot of overlap, perhaps merge these two layers.

User - mentioned as a "to don't"

Public/Private chain mix

• A lot of permissioned chains are self-sufficient. Supply chain is a well known domain with no need to go external.  Value is intrinsic, making things more efficient
• Other permissioned chains are finance, supply chain DeFi, value flow. It's natural to involve the general public, will want to attach to the public chain
  • Example, NFT of a permission chained item, sell it on OpenSea
  • Want to provide exposure to crypto value into the private ecosystem.
  • Need to build Token Bridges, Swaps,
  • Deal with public chain quirks (reorgs, finality, stuck transactions)
• There are some paradigm issues when you separate it into public/private chains
  • Alt though: Permissioning itself can be used to support the decentralization of the system.  Governance can enforce decentralization and finality
    • Ex: sigining legal agreements,
    • Copyleft enforcement of decentralization rules 
    • Key rotation
    • Survive problems that would be existential to permissionless networks.
• Public and permissioned are designed very differently
  • Apples and Oranges comparison.
  • Governance model is fundamentally different, reputation safeguards data. trust
  • vs. Open, presume the worst human behavior and write code to deal with it.
  • Need to stay out of the trap of one is better than the other, we need both and they need to work together.

For philosophy statement :"We encourage projects integrating the permissioned and permissionless blockchains"

We care about what they are enabling not what consensus algorithm the use.

What are the sources of new projects?

• Researcher pet projects
  • Example, convince people that HLF is the right place to put the code rather than have a diaspora
  • Some researchers are doing this work "in their garage" rather than as part of the community
  • It's work to start a project, some would rather just build a POC
• Hackfests filled some of the project funnel
  • HLF staff and members talking at the projects helped
• Give incentives to projects that reacted to solicitation to move to HLF
• Existing projects moving to HLF
  • TSC could identify candidates and reach out
• Hyperledger Labs
  • Source for new top level projects
  • What can we do to encourage more labs or keep the pipeline engaged.
  • How can we encourage labs to continue, even if not as HLF top level project.

"To Don't" List

• Operating a public network
  • Instead, focus on the software that runs the network
• Specific commercial operations
  • Interested in the general part of the code
  • Commercial operation can configure and add development
  • HLF is not the dev team for your commercial operation
• Standardization
  • Need to be careful how this "todo" it is phrased
  • HLF is not a standardization body
    • There are legal implications HLF's protections are not enough
  • Projects may bootstrap and then migrate to standardization
  • HLF is a great laboratory for experimentation
  • Standardization works better with existing code

Labs

https://github.com/hyperledger-labs/hyperledger-labs.github.io/tree/main/labs

• HyperFabGames
• PerformanceSandBox
• acapy-java-client
• blockchain-carbon-accounting
• blockchain-verifier
• business-partner-agent
• business-partner-agent-chart
• dancap
• fabex
• fablo
• fabric-chaincode-ocaml
• fabric-machine
• fabric-operations-console
• fabric-opssc
• fabric-smart-client
• fabric-token-sdk
• go-perun
• hlf-connector
• hyperledger-community-management-tools
• hyperledger-labs.github.io
• minbft
• minifabric
• mirbft
• neferti
• nft-auction
• orion-sdk-go
• orion-server
• perun-cosmwasm-backend
• perun-cosmwasm-contract
• perun-doc
• perun-eth-contracts
• perun-node
• perun-proposals
• private-data-objects
• solang
• university-course
• voters
• weaver-dlt-interoperability
• yui-corda-ibc
• yui-docs
• yui-fabric-ibc
• yui-ibc-solidity
• yui-relayer

Recordings