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:

• 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.

• 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"

• 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.

• 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.

• 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

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