You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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


  • No labels