2019 05 02 TSC Minutes

Owned by Ry Jones
Oct 01, 2019
13 min read

02-May-2019 (7:00am - 8:00am PT)

via Zoom

Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit our Code of Conduct: Hyperledger Code of Conduct

TSC Members


Present?

  • Arnaud Le Hors
  • Baohua Yang
  • Binh Nguyen
  • Christopher Ferris
  • Dan Middleton
  • Hart Montgomery
  • Kelly Olson
  • Mark Wagner
  • Mic Bowman
  • Nathan George
  • Silas Davis

Resources:

Announcements

  • Congrats to the Hyperledger Transact proposal. It passed in the email vote this week.
  • The wiki has been a great help for everything we do so thanks to the team that made it happen.
  • CI/CD committee is moving forward so contact Dave Huseby if you want to be in that committee.
  • Contributors Summit Update
    • Looked in lots of surrounding areas and unable to find a location that is in budget.
    • Several other proposals for the Contributors Summit are being considered.
    • Silona is asking for people who would like to help in a committee for looking at and vetting locations for meetings.
    • Options for a September meetup:
      • Vancouver
      • Russia
      • Bermuda
    • Need to plan it sooner rather than later.
  • Brazil Bootcamp is happening at the end of June.
    • Contact Silona so that we can organize mentors and session leaders for the bootcamp.
    • We want all projects represented at the bootcamp.
    • We're looking for people who can mentor somebody who can attend to be able to present their material. Especially people who are multilingual and can speak the local language.
    • Hyperledger is sponsoring three bootcamps but there are others happening elsewhere:
      • Defcon and Defcon China
      • Denver startup week
      • Another in the fall.
    • Even though HL doesn't fund some bootcamps we do have some staff facilitating the organizing of presenters.

Items of discussion

  • Aries proposal
    • Reviewed by Baohua, Hart, Kelly, Mic, and Nathan before the meeting.
    • Nathan proposal presentation:
      • inline comments worked well and most were points of clarification.
      • Aries is a client tool suite but also in some ways a framework as well with library code for consumption.
      • this project won't be producing a mobile app but it includes all of the framework code for that.
      • targeting more than one chain, not just Indy.
      • it's moving into it's own project to stay true to the multi-chain design goal.
      • the sponsors of the document come from all over our community.
      • most of the sponsors are already code committers and active in the calls and mailing list.
    • Discussion:
      • Chris: it's not a wallet, it's got a lot of attributes of a wallet. the way that it is described is that it is part of one's SDK. I don't understand how you're going to do that unless you're going to have flavors of this in just about every language you can conceive.
      • Nathan: it's written in Rust and compilable down to C interfaces...
      • Chris: yeah, I'm getting a little bit tired of that, because c'mon, that's just not... it really isn't all that realistic.
      • Nathan: we've been shipping code on top of this in Indy for some time. I know it's a different approach than some of the other platforms have taken but we've certainly had a lot of success with it.
      • Mic: what's the breadth of language support you currently have in your clients in Indy. Is it just Rust?  
      • Nathan: so the main code is in Rust and that makes it so we can expose the main functionality to all of the different languages. We have really strong wrappers for .Net, Java, iOS, Android, Python, node.js, PHP, Ruby, Go, Objective C, etc. Every language on the list has supported code and maintainers.
      • Mic: I agree with Chris that just because it is in Rust does not mean that it is easy to put something else around it.
      • Nathan: I don't have an objection to that opinion one way or another, other than this is what we're doing in practice now and it seems to be working.
      • Dave: I have an objection but I'll take it offline.
      • Dan: I think the next level of abstraction up from that is the APIs you'd have to call through to do the resolving with different types of blockchains. So you'd want to be able to call in to the Fabric API, Ethereum API, and Sovrin API and so forth. So could you talk about the ability to do that with this future project versus the commitments to build that out.
      • Nathan: we expect a lot of new development to occur in this project as with one of the main scope changes instead of what's happening in Indy. We have the did:peer resolver which is the local wallet for doing all of the key management and that code has forced us to do a refactor on how we get things off of the verifiable data registry for the identity key management and definitions of schemas and so forth to where it has an abstraction layer that can then have other systems can plug in. The first systems that I expect to be targeting here are the resolver that the VerasOne folks want to contribute.  Their interface is more of a REST based interface so it should be a fairly simple implementation and then there's one for the ETHR DID method that uses IPFS for resolving the DID document and then there are others that are based on the code that is already implemented over at the Decentralized Identity Foundation where we're going to be popping the code out of the docker container based system they are using over there and moving it down in the Rust code so that it can be part of the native system. Marcus has committed to support this in the universal resolver. Hopeful that DID identity model work can be done to better support Fabric. It depends on the amount of investment we get from over there. Resolvers for other chains will live inside their respective projects (e.g. Indy) or within HL Labs.
      • Dan: should we interpret that meaning then that the kind of schemas that that code is meant to go do GETs and SETs on it should be centered around the identifier types of schemas? 
      • Nathan: that's correct. So the idea is that it follows the decentralized identity standard in terms of how it handles its key management and then for verifiable credentials exchange that we're following the pattern that was set in the W3C veriable credentials spec.
      • Dan: so nobody should be thinking of this then as a general purpose clients to go out and talk to all blockchains for all matters, this project is to provide a lot of standardized ways to go out and get identity styles of schemas from a variety of different blockchains. 
      • Nathan: so that is the main focus if you go look at the callout of scope, our expectation is that you'll have a simple client that can just sign and submit transactions to a blockchain so you could use it for that type of an application. We also expect that we could build verifiable data registries interface that will handle DIDs and DID documents and things like schema definitions for verfiable credentials and then we expect to have a payment interface that will allow for transfering things as tokenized assets a part of a verifiable credentials interchange. This could be used to transfer a crypto asset, but the main focus is for veriable credentials exchange between edge clients.
      • Silas: is this entirely meant to be driven wallet implementations. Is this meant to be machine to machine or as a library in a node.
      • Nathan: we think of the client layer as it could represent a person, an organization or a thing. So we don't make a clear distinction on whether which type of entity this wallet is representing. In the long term you have more than one machine that represents a person or an organization, for example, I may have my phone and my laptop and my cloud server and as I have to do synchronization between the wallet contents between those different compute units I end up building an ordering, gossip protocol and some kind of consensus on which changes I should accept and which I should reject. So you do end up some of the base building blocks for doing node-to-node types of things but for the Indy project we expect in the long run we may consider rebuilding the node code on top of the agent code. We would then think of the ledger state as the shared wallet state among the agents. Not sure how it will play out, just thinking what may be possible once this becomes stables.
      • Silas: you mentioned implementing WebAuthN/OpenID connect but you don't have enough interest?
      • Nathan: been in discussion with a company called IDRamp that built SSO integration with verifiable credentials so they will likely upgrade to use the agent framework. Seeing some good activity right now.
      • Dan: rounding out some of the thoughts. for the kinds of code that would reside in other blockchain projects, what would that look like?
      • Nathan: it would be an implementation that would sit behind the interface and would have to compile to be C callable. The ideal way is to write it in Rust but there are multiple options for other languages to match the existing blockchain frameworks.
      • Dan: so somebody would grab some library code from Fabric and then interact with Aries?
      • Nathan: correct.
      • Arnaud: this is an interesting project for sure. I still struggle with how we manage the different projects within Hyperledger. Historically we've been creating projects with hope that they will be used by different projects and kind of wishful thinking type of thing. I still wonder if this is the right approach. Does this really need to be externalized from Indy or should it not prove itself first and live within Indy and stay isolated with Indy and integration with other projects can happen and if that works out, we recognize that it is bigger than Indy and move it into another project. The Burrow EVM is integrated into other platforms and yet we haven't externalized it yet into its own project. It just raises that same question again.
      • Nathan: This is an important project that we should ask for all projects. In particular with the Aries project, it has grow to have about 30-40 regular participants in the calls (Indy Agent WG call) and the management of this code base relative to the management of the Indy codebase has become rather difficult. The coordination between the two has become harder. That's one main reason. The other is that we're hearing from people that want to do collaborative contributions with other code and they have this impression that Indy is only about the ledger and they have a hard time distinguishing between whether they are picking up the project to build their own blockchain or whether they are picking up the project to do this type of key management and information exchange. And we think this clarifies the scope of what the end users are trying to accomplish to better attract contributors.
      • Chris:  if I just heard you correctly, you just said it is getting difficult to manage coordination between the agent and the rest of Indy. Making a separate project is going to improve that?
      • Nathan: what I mean by that is there is a different set of features that have to land in order on the Aries side of the project than there are on the Indy side of the project. The type of work that is going on inside of Indy is related to the consensus algorithm and the type of work that is happening in Aries are message family and peer-to-peer protocols in terms of JSON of those different types of protocols and so the quantity of information that is being discussed in terms of standard in the Aries side of the project is squeezing out a lot of the discussions that need to happen with the ledger and what's going on for the batch ordering integrity and things like that on the ledger side. And so splitting them off into their own meetings allows them sufficient time to discuss the active development work.
      • Arnaud: to be fair, you don't need two different projects to have different meetings. The Fabric community has different projects going on and they don't all meet at the same time. Independently of what happens with this project, you could decide to have two calls a week or whatever it takes to have sufficient time.
      • Nathan: no object there, I think we're up to about six or seven meetings across the whole Indy community.
      • Arnaud: I do think that one point you raised that I think is valid is the communication aspect. I think externalizing a project like this definitely sends a strong message about the scope and dependencies that you don't have when things are still tied together. To me that's the biggest argument to externalize this project. The down side is what we've seen before when we take a bet on how we hope things will play out and they don't always do. And then we end up with projects that on paper should be independent but in practice are not. Which I think is not ideal. 
      • Nathan: I agree with that sentiment which is why we'll work really closely with the maintainers to keep the commitment that Aries is cross-ledger. It is one of the conversations we had at IIW that there are other applications and data registries that need this type of library code but are not a traditional blockchain or not something that would participate here in the node side of the development of the system.
      • Arnaud: thanks!
      • Dan: I don't think this would need to block moving forward with the proposal written as is, but maybe give some additional though to wether the repo structuring of this would facilitate blockchain code from the various blockchains that people are interested in supporting. So not that we not necessarily require this team to implement those integration points but I think that if there is way to house that code all together it seems like we would get better uptake than if we have a 2 or 3 point integration.
      • Nathan: I like that feedback for some of the projects that aren't doing Apache 2 license and DCO approvals and things like that. Giving them a home inside this project could help them with that.
      • Chris: I'm still smarting from the whole Composer situation where I think we went in with the best of intentions and nothing happened when it comes to supporting other projects. I think there was some expectation that the Composer team was going to do that and I'm still struggling with the point that Arnaud was on which is why not do this inside of Indy and see if it gets used elsewhere before moving it to its own project.
      • Nathan: we are already at that point already and have been some time. The folks doing some of the blockchain resolvers are going to be faces you're not used to seeing inside of Hyperledger they're folks that feel like they can't contribute to Indy because they would be materially supporting Indy but now they need to pick up the agent-to-agent pieces and they need it to be independent before they can participate. By moving it to it's own project, we can attract those people to join Hyperledger because it is independent of Indy.
      • Silas: what's the current state of integration with Ethereum? Is it resovlers?
      • Nathan: uport inmplemented a resolver for ETHR resolver. The expectation is that those external resovlers would fit under this interface. It's unclear which bitcoin and ethereum resolvers will fit into this codebase but I think we'll figure it out.
      • Dan: are we ready to vote?
      • Mic: this discussion has been very helpful understanding why this needs to be a separate project and the proposal doc doesn't fully capture that so we should consider rework our proposal doc.
      • Silona: add a question to the form?
      • Mic: yes, discuss offline. the last three proposals the critical discussion was about the relationship with other projects and how it will interoperate.
      • Dan: let's do a roll vote.
      • Mic: motion to vote.
      • Silas?: second.
      • Silona:
        • Arnaud: yes with the hesitation I already expressed. I think I would feel more comfortable with going forward with this kind of project if we were a bit more agile in recognizing when things aren't working out and we can take it back.
        • Baohua: yes, I think maybe we can make the decision later like next week because there is lots of discussion about this proposal and some open questions.
          • Silas: I am very reluctant to delay this but I would like another week to understand some of the bits before I support it.
          • Arnaud: I'm happy to retract my vote to be in favor of delaying a week.
          • Nathan: I'm eager to get approval because I'm at IIW and it would be helpful with recruiting new maintainers.
        • Silas: yes, good enough for me.
        • Binh: absent.
        • Chris: yes, I have similar reservations that I expressed earlier. We need to do more thinking on what are the criteria for becoming a top level project. We've got a ton of stuff still in incubation and we keep turning out new incubation and I'm not sure we are sustaining everything correctly.
          • Dan: that sounds like a yes but no.
          • Chris: it is a yes, but we need to discuss about how we intend to manage all of these projects and how we are going to get more synergy across these projects and we keep launching things that are supposed to build on top of other things and it never happens.
          • Mic: to be concrete, can we add something to the backlog for future topics that specifically focuses on how we manage the strategy for retiring incubation projects that are innactive and how we manage sub-projects. Chris want to take ownership? I will help you.
          • Hart: I have an email to send about this.
          • Dan: Backlog item added. Back to the vote.
        • Chris: a reluctant, yes.
        • Dan: yes.
        • Hart: yes.
        • Kelly: yes.
        • Mark: yeah!!
        • Mic: yes.
        • Nathan: yes.
        • Silas: yes.
      • Motion passes.


  • Wiki and processes.
    • There have been some changes in wiki that not everybody was aware of.
    • Because we are open source, we can usually get confluence additions for free.
    • We do have collaborative editing.
    • There's an in-source editor but be careful because you can edit the HTML and JS directly.
    • There are macros for lots of cool things, specifically the gliffy diagram and balsamiq wireframes collaborative work that isn't in google's platform.
    • Macros for checkbox lists and children's display. Lots of more stuff on our wiki than what you get on google.
    • Set up spaces for each project which gives the projects some autonomy within them.
    • Have a contractor for doing JIRA, github, and confluence integrations. Fabric is first.
    • Regarding the TSC we've got the project lifecycle and the proposals.
    • We have the project updates and a form to fill out.
    • We've also done similar things with the SIGS and proposing new groups.
    • Same with WG's and TSC updates.
    • We are building checklists for what need to happen for each state change of a project. Related to readiness.
    • Same thing for new working groups and major releases.
    • Questions?
      • Dan: let's talk about integrations for projects in an upcoming TSC meetings.
      • Silona: the contractor is going to be working on this with granular statements of work done publicly.



Quarterly updates


Upcoming items


Backlog


Recordings