 So Chris, if you're ready, we can get things started. So good morning everybody or afternoon, evening, whatever it is in your galactic time zone. So first up we have action item review as usual, have an update from Dan on the virtual hackathon and I don't know if Sheehan or Ben is on, maybe they could update us on how the fabric has been going. I'd appreciate somebody weighing in on that and we can have maybe a brief discussion on what we can do to tune it up or tune it down or whatever. Then next up we have Greg Haskins, he's at a proposal for a chain tool and then we have workgroup updates unless there is any other discussion topics. We can get going and I apologize in advance but I'm gonna have to leave at 11, I've got a customer visit so the call can keep going but I'll have to leave. All right let's go. So exit criteria, Arnaud, do we make any progress over the course of the past few days? I apologize but I've been traveling. Not really but I was hoping if Jeremy is on, there's like a side discussion and Jeremy added the whole table in the document and you know it seems to be interested in going further than what we were talking about which was specifically the exit criteria to go from incubation to maturation and so you know he apologized and he couldn't attend the call last week when he discussed it so I was hoping maybe if he's here today we could have a bit of discussion on that to see how that fits. I don't want to disregard what he's done. He actually put quite a bit of content to the document and at the same time I don't really know how to use it. So yeah so I see Jeremy on. Jeremy so maybe it's a good and I did, now I remember that I actually sent a note to the list about some of my thoughts around this. I think it'd be valuable to sort of to have a brief discussion of this. Maybe if we could before we do if we can just sort of go through the the remaining action items and then we can visit this right before we talk about the hackathon. Let's find it with me. Okay so Todd thanks Jeremy. Todd hackathons and the scheduling. How's that coming? Yep so quick update. The June hackathon is underway. We'll do a quick update on that later this afternoon or later in this call. For July there are essentially two options. We reached out to a variety of companies. So Chris says you know IBM offered up some space that week of July 25th. The one downside of that is and Chris maybe you can speak to this as well. Is it's a bit south of San Jose? Yeah not near a whole lot in that area so yeah I mean so that's not necessarily ideal and then for those traveling in to SFO it's a bit of a trek to get down there. The other option would be to use some space in San Francisco adjacent to where the Linux Foundation office is in the Presidio. There would be a cost associated with that. The one thing we're trying to figure out there's essentially three different options. Only one is confirmed availability at this point. We should know back from the others this afternoon and can send the final date pattern for that. But we would on the high end be looking at spending around $12,000 to hold the hack fest on the low end around $6,000. Our preferred option would put us right around $9,000 to hold that event. The board has allocated $85,000 over the course of the year to fund some of these hackathons in the instance where we're not able to have a member host them. So those funds do exist. We just need the TSE to okay that. So I think for the purpose of this discussion you know there's two things we need to decide. Is the preference towards you know using the IBM location or using the San Francisco location and then from there go into the the subdivision of what the preference is. Right. So just to follow up Todd on that. Yeah so the offer from IBM we looked at a couple of different places. Foster City is obviously closer to San Francisco but we only had the only the only space that would fit everybody was really auditorium seating and I don't think we want to do a hackathon in that kind of a setting frankly. So we didn't have a large enough space for the 60 people in Foster City and that leaves us with Silicon Valley which is our San Teresa lab, formerly known as the San Teresa lab. It's in it's a very southern border of San Jose so it basically borders on it's the town just below it there. Morgan Heller Gilroy. It's practically in Gilroy. So it's rather you know out of the way it's not I mean it's it's it's a good 20 minutes to San Jose Center. So there's not a whole lot there right. I mean there's some plants and some vegetables. So again it's a nice place inside but there's like I said if you want to go out for dinner there's not a whole lot of choices. So you know I mean I don't want to discourage people but I also feel you know Todd to your point it's also a good hour from San Francisco Airport so if you can't get into San Jose Airport it can be a bit of a hike. So I mean maybe we should just sort of get a sense from and again this doesn't have to be a TSC vote this just the sense is is anybody sort of violently opposed to staying in the South San Jose area there for a few days in which case that can help Todd and company focus on the Presidio options. Just one more piece of information there's one advantage is that it's reverse commute to go there. That is true. You're not gonna be stuck in traffic too much that's right. While going to the Presidio you know it's another story. That's true. So am I hearing that there's nobody violently opposed to that and they can leave it on the list or? I certainly wouldn't mind that. I'm sorry Nick. Sorry I was just saying I wouldn't mind going south at all. Okay okay any others okay let's leave it on the list for now but let's work up the Presidio and the other couple of options from this afternoon and this sort of will weigh the. All right sounds good. Sounds good. Just quickly moving on from there August will look to do a virtual hackathon. I dropped a doodle poll into the minute into the agenda. I'll send it out with the minutes as well just so we can firm up a timeline for getting folks together virtually in August. Then for September October it sounded like the group was really interested in doing a European hackathon. There are a couple options to co-locate with events but we did connect with ABN Amro who has offered to host this. It would be at their office in Amsterdam. They're also very keen to pull together some of the community around there. IBM Netherlands is very interested to participate the fintech community in Holland. Blockchain initiative of the Dutch government various universities and they also have a pretty good network of blockchain contributors in Amsterdam. So that definitely seems like a great option to pull that together. They said dates are fairly flexible in terms of when they would be able to do that. So I included a doodle poll to gauge general interest in time timing from everyone. Definitely take a second to complete your availability if that's something you're interested in participating in. And that wraps it up for hackathons. Chris, do you want me to move on to the Sybos question before exiting? Yes. All right. So Sybos as many know will be in Geneva, September 26 to 29. The Hyperledger Project Marketing Committee is planning to sponsor that event and have an exhibit booth there for some marketing efforts. So as part of that, given that this is a significant marketing opportunity, the marketing committee is creating a SWAT team basically consisting of events, marketing PR, and they also want to incorporate a couple of people from the technical community. So they're looking for a few volunteers just to provide the technical perspective from this. So if that's something you're interested in, shoot me a message and I'll get you connected up with that team as they form a small group working on that. All right. Thanks, Todd. Okay, so let's talk briefly about the exit criteria. So, you know, as Arnaud, you know, Arnaud, we had, and everybody who was on the call last week recalls some of the discussion and so Arnaud was collecting and editing the document according to 74% of the world's global ACH volume. Sounds like somebody's watching TV. Or maybe another person's on the call. Okay. So Jeremy, maybe you could provide us with some background on the thinking, on the content that you had added to the exit criteria document. Certainly, Chris. Thanks. In trying to look through and make sense of a lot of the different comments that came up, both sort of on some of the Slack channels as well as within the document itself, it looked like there were different threads going on. And in trying to make sense of that, I tried, I started working through trying to structure something. And what it seemed like kept coming up were a couple different things. One of them was that, for example, the idea of the word maturity seemed to set people off in terms of thinking about the qualities of the software as a not just as sort of the nature of the project around it. And the other thing that kept coming up was a lot of things that could be requirements, they could be things that you attest to about the software. And when I looked at that, and I also looked at some of the other materials that I think Todd and others had written up about the project lifecycle, it seemed like a few things could be teased out. So what I tried to do was tease out different things about what are we saying about different stages in the project lifecycle versus what are some of the things that are being described within those. And so the table just came out of trying to make sense of that because it seemed as though what was going, part of what was going on in the discussion was about the need for a change control process. So not necessarily a definition of done, but that there that it was probably a good idea that a project had a definition of done. And then there's some of the some of the other sort of criteria about projects seem to fall into sort of adoption community support levels. In addition to just what the software itself did, or ways you could judge it, whether it's a question of judging it as being done ready for release. And so I just tried to tease those things things out. Not to say that there is a definition of done, for example, that should be promulgated, but that a project should have some concept of done, and stick to it within a change control process. Because I think some of the things that might give people pause would be for example, if all the sudden part of the project went the way true crypt went, where a lot of people depend on it for some various sensitive and valuable materials, and then all the sudden project shuts down. So essentially, in trying to step back and look at sort of how this fits in so I could better understand it and ramp up on understanding how the how this is structured, not having worked on a formal open source project before. That's what I sort of tried to lay out in this table on page three of the draft. And I think it as an as an example, you know, whether or not it's the TSC who says something's done, or it's the project team that says something done. Presumably, somebody ought to be saying this thing is done, it's done based on the fact that there's some piece of documentation that's written it up. It's documentation looks at functional technical, you know, abilities like scalability, operating service level agreements. It's been some way in some way tested, it's in some way been validated or code reviewed, similar to sort of some of the discussions around Garrett. And then at some point, at some point, if that stops, somebody ought to flag that. Not because, you know, with, I guess, with something like hyperliter, there's so much hype that's driving a lot of enthusiastic folks to the table, which is great. And presumably, the goal is to sort of channel that productively. And so I don't think there's a need, I assume it's important to stay away from a need to really push a lot of formal process on. But if, if, if part of the exit criteria is just to provide some guidelines, providing them with a little structure like saying, you probably want to have some kind of documentation. You probably want to have some kind of definition of done, you probably want to have some kind of release, not just release process, but change control process, which is, which are pretty close to the same thing, but not exactly. And that if, if, for example, a project stops following that, at some point, somebody ought to flag it. Just because if, if, if this effort does succeed, which would, which is great. We just want to make sure people's expectations are out there are being managed. And I think part of that, for example, is we're having a discussion yesterday on the identity working group. One of the concerns, one of the concern questions was, would it, would it make sense to be able to, even within whatever we're defining as a project that's exited incubation, if there's a, say a section, section of it that's experimental versus a section of it that's ready for release versus a section of it that's production ready. That would be a valuable distinction, at least in terms of setting expectations for folks who might be either working on it or using it. So that was basically the idea here was to sort of work, work, think through what are some potential dimensions of the guidelines that have come up and use this table as a way to try and slot those into some sort of structure. But that's that's the idea anyways. And Chris, Chris Allen suggested some further follow up on that as well. Some, does that make sense? Yeah, it does. I think, you know, and again, some of this is, I think a function of, you know, sort of the traditional, if you will, I don't know what's traditional, but, you know, sort of MO for an open source projects. And, you know, you have many communities such as Apache and Eclipse and Linux Foundation that have leveraged this concept of incubation to be really, and I think that this somehow or other is where you're, you're heading with this, but is that effectively, it's a measure of whether or not the team that's producing the code is mature, right? Have we got, you know, a diverse community of developers. So there's not just one person or one company that's contributing, but that it's, there's a certain diversity because that helps with the sustainability of the project if you have multiple committers from different, you know, different companies or different, you know, whatever. And, and then, you know, whether to, to your point, are they following sort of the prescribed processes for the code for doing reviews for, you know, for being able to produce a release. And, but the exit criteria for, I mean, I was just looking this morning at the Apache and the, you know, criteria and, and it's basically fairly straightforward. It basically says, you know, that the code runs that it doesn't say that it's done. It just says that it's, it's running code that, you know, they are following the, the sort of, and again, Apache has fairly, you know, fairly conservative approach to managing intellectual property. And so that's a function of the maturity of the project is whether or not they've got, you know, they've, they've leveraged all the various tools and, and they're able to get through a release process. I think maybe even a couple of them, you know, cleanly, you know, with the, with the IP audit and so forth. And then, and then, you know, again, the diversity of the community and so forth. And that's really about all they measure, right? It's not a function of is this code ready for production or something like that. Now, that said, I think that, you know, again, and again, I think that if we're going to have, if Hyperledger Project is going to be host to a number of top local projects, that I don't know that we necessarily want the TSC to be deciding everything for every project. I think that realistically, you know, we're going to have to, in order to make the scale, we have to sort of leave it up to the project team to decide when they think something is done for, from a release perspective, you know, is this a long term release? And does it meet a lot of the criteria we're looking for? So we may have, you know, we may want to put together some sort of a release yardstick in terms of maturity and code coverage, test coverage, and, you know, long term support, you know, branch maintenance process and so forth for something that we're going to consider to be ready for prime time. But the exit from incubation itself shouldn't necessarily be predicated on whether or not the code is production ready and sort of done, right? Because again, again, we're never really going to be done. And that was sort of the spirit of what I wrote in my note to the to the manlyness, but I didn't see any response to that. I don't know if anybody else has any thoughts on this. Hey, Chris, this is hard. I talked with Jeremy and Chris Allen yesterday about a lot of this stuff. And I think a lot of people are just worried that people, particularly outsiders, wait, maturation with like a product ready to release and be used. And people were worried that someone might use the product. Someone might use hyperledger before it's ready. And maybe, you know, it could be the case that there's, you know, there's security flaws, catastrophe happens, money is lost, or something like that. And people are just worried about something like that. So I think if we if we discussed, you know, probably sort of like some kind of release criteria, then people would be a lot more comfortable with this. Or if we said something like, Okay, well, this is mature, but, you know, we're clearly not ready for release, or something like that. Does that make sense? This is Brian Bellendorf. I don't know if you guys can hear me. I've been a muted. Okay, good. Problems have been on my side. Some of this conversation was my cue to jump in. I think a lot of these observations are really insightful. And I would love us to borrow and steal as much as we can from the Apache incubation process as we can, because I think, you know, that's something that's been honed over 15 years, and has resulted in some some really good community dynamics, I'd love to try to replicate. And I would love to separate out at least two things that might be in a third thing in there, the maturity and ongoing health of the community. And that is by having this exit criteria from incubation that says you have to be able to put out a release as a community that release has to represent the efforts of different organizations and individuals, right? It can't just be, you know, one company that's done the most of it or all of it. And so that's kind of a squarely definition. It's been a challenge in some projects as a bootstrapping. But it's one of those you kind of know when you see it, things. And that's that a that should be one one criteria. And then there's an ongoing reporting process from that project. In Apache case, it's up to the board. In our case, I think we should have it be reporting up to a board that represents kind of the technical interest in the project. And in this case, I would say, that's probably what the new role for the TSC is, or the existing role. And it's the ideas that it reports these projects that Apache the report once a quarter, we could probably start with monthly reports on, you know, their activity, you know, the releases they've made the new contributors that have joined the, you know, to some degree code quality, how many bugs might be outstanding or that sort of thing. But it's not just metrics, it's a narrative report. And one of the most important things is being able to respond to security notices, and push releases quickly. That's a really good measure of the health of a community is when a security hole came in, were they able to address it and respond within, you know, hours and days rather than weeks or not at all. So then separately, there is the question of code maturity and the labeling. And what I'd love to see across the projects within Hyperledger is a consistent kind of naming protocol for code that is, you know, we should come up with a taxonomy, but say developer preview, alpha, beta and production, right. And we could correlate those with numbering with the numbering, but having a consistent label like that across our projects would help transient communicates the world, you know, where the projects are, but also make things safe, I think for people to adopt and set expectations correctly and give us the room to refine something before labeling it as ready to go. There was a third one I can't remember, but really separating those two out is key in my opinion. Thanks, Brian. I tend to strongly agree with the consistency of labeling. I think that that will be important. And, you know, I don't know if we need to have, well, I suppose we can think about, you know, setting specific criteria for that labeling. That might make sense. But I think I agree very much with the points you're making on, you know, the sort of the type of community that the incubation process has enabled in Apache. And that's actually it's been replicated elsewhere. So it's, I think it's pretty successful. Then ongoing reporting is I think speaks to the concerns about what happens to the project launches and then loses momentum. Apache has been known to discontinue projects because they've lost that momentum. And that kind of mortal fear is actually somewhat useful. I mean, it's a sign that, you know, because it certainly is a big problem if there's a security hole noticed in something critical, and no one's around to know how to push an update to it, right? So so yeah, that regular communication back and forth is, I mean, it'll be second nature on a project when we start, you know, because there's only two right now and there could be more soon. But but that that heartbeat is kind of essential, I think. So how do we get to the sort of the next step with the incubation exit criteria, folk? Just a question from Richard here, just this conversation really helpful because it is great to hear experience from people who've done this and from other projects. And my initial thought, I looked at the draft document for the first time just now and my comment was, there is always try to be prescriptive about certain metrics is probably the wrong way to go. And this description, I think is making the same point. If I have Brian correctly, you're saying that there's a process that works pretty well in Apache is, is that the equivalent of the answers? Yes, I should know this. Is the equivalent document that we can just use as this review as a potential as input to the current one or as a starting point? I do it to what extent do we actually need to reinvent anything? I encourage all of us to go. I'll send the link around if Chris hadn't sent it before. I think I might have seen it on the TSE list. But if not, I will definitely send it around. And we should use it as a starting point. It is high maintenance in some ways, because it was it's been refined. And now the ASF has 300 different projects and their principle is their main board, their version of the governing board reviews, reports, once a quarter, which turns into three hour board meetings every month. So it may be high touch, but maybe high touch is what we want right now. But I'd use it as inspiration and a starting point and a base for conversation about what we want. Without treating it as gospel. It just is is pretty well that it pretty well tested. And and I'll take it as an extra. I'm certainly to look at the release criteria as a in the light of that. And you know, with that with that in mind. But it may be worth asking, is there a second document we may want to come up with that's parallel to that that talks about, you know, the release taxonomy that we would hope to standardize across projects. So in light of that, you know, the fabric team was hoping to be able to at least kind of release that we don't have to call it anything, we can just sort of, you know, sort of play it down a little bit. But I do think that, you know, as part, I think, you know, one of the things that we have, you know, for all these projects is that, I think, you know, we would like to demonstrate that in fact, you can do this as a team, you know, as a community, you know, to produce a release, it's got all the right bits and pieces and has, you know, established a process that can be followed and so forth. But if we're, I mean, are we going to wait until we see some release criteria before we can do that? Or would it be safe to come out with something and just call it, you know, alpha or something? So what would set expectations, right? And we can, I wouldn't want to hold up a release while we're working on taxonomy, but at the same time taxonomy shouldn't take a long time to do. You know, I worry even alpha suggests that a certain degree of maturity. But I think either alpha or developer preview might set expectations correctly. Okay. Right. What might be also useful when you make a release is to highlight those areas that will be a key focus, you know, beyond that. You know, if performance, for example, is a key concern, you know, to do in the release announcement, be clear about that and focus people's attention on that. Yeah, and I also want to sort of emphasize a point that, you know, for some projects, you know, and I'll just sort of they have a release process, and when they cut a release, it's a big deal, right? And then there are others that are a little bit more agile, and they're cutting releases all the time. But it's not a big deal, right? Docker, Cloud Foundry, you know, Kubernetes, a lot of these projects have, you know, whether they're dot releases or whatever they want to call them. And it's really just, here's, you know, a stable version, right? And it's really not saying anything much more than that. Somebody go on mute, please. Thanks. Um, you know, maybe a couple of times or three or four times a year, they might have a formal release that's got some hoopla associated with it and some messaging and labeling and so forth beyond just, here's another stable release. I'm assuming, or I would hope that we would be able to accommodate something like that, because I do think it's very important that we have, that we adopt a process where, you know, the code is constantly changing, but the people are able to pick up, you know, a stable version and, and really kick the crap out of it and give us solid feedback and so forth. So I would, I would encourage you when we think about the taxonomy to be thinking about, you know, each of those stages perhaps having a progressively higher tier required of kind of community approval before it's released, where early on it might be something such as, you know, if three people give it a, give a given release image, a thumbs up, you know, a plus one, and no one gives it a veto, then it can go out, I think. And, and, and who counts in that, you know, is, is right now perhaps pretty loose, you know, could it be anyone anywhere giving a veto? I'd say, let's try it. Let's try empowering folks in the community. And we can correct for that if we find it's too broad. And then as you get closer to a, say, a proper beta release or something you would call production, then you could have it a higher, higher threshold of positive votes, and people willing to, you know, you're essentially asking people to put their names next to as personal developers next to the release, right? I attest to the quality of this as it hits this, this threshold, this criteria, and the more diverse that committer base can be, the better, even early on, even early on. Any other thoughts? So I think it's probably worthwhile then that we sort of take yet another stab at going through the exit criteria and bring it back forward. It would probably help if people could also just weigh in either in the comments, or via email so that we can continue this discussion and not have to have it be punctuated by weekly calls. Because I do think it's important that we make these decisions, because then is, you know, we've just been discussing, we probably have to take it to, you know, discuss release criteria and so forth as a separate exercise, and I wouldn't want to have all these loose threads, all at once. So I know if you wouldn't mind sort of taking, you know, all of this into consideration and taking, you know, the pass it at the exit criteria, and then send it out to the list. Yeah, yeah, sure. But it's a bit difficult because I feel like, you know, we don't have a clear alignment as to what the nature of the, you know, exit criteria should be. I mean, when I look at the link I posted it, Mike Dolan, I posted it as a comment to the document, the exit criteria for the incubation at Apache, it's more, it's actually better, you know, it's better developed than what we have for sure. But it's in the same vein, in my opinion, it kind of gives you some general idea of, you know, what constitutes a match or project or what, you know, qualifiers match here. And it's quite different from other things that people have talked about. It doesn't actually talk about releases or the actual state of the product per se. And so I just would like to make sure that, you know, we have an agreement on, okay, this is the kind of things we're going to focus on when we talk about exit criteria for the incubation. Because if we don't agree on the scope, then it makes it very hard to make progress. And, you know, another aspect that I wanted to bring up is the, in Jeremy's table, I noticed that there's a stress on the change control. And it proposes, for instance, that the project in maturation cannot basically have any drastic changes. And as it goes through a whole incubation again, I mean, this is beyond my expectation. I don't know if other people have opinions on that. But no, I think that's a function, again, of the cadence of releases that, you know, that is expected, I think that projects would continue to evolve and improve and or, you know, just be at a point where they're squashing bugs. But that's not an incubation function. That, again, I think incubation is a function of the team. I like Brian's sort of the reporting requirement that sort of holds people's feet to the fire, or, you know, we, you know, the project runs the risk of being, you know, demoted, as it were, you know, to act, or archive, or whatever, you know, create, in a strategy, it's called the attic. And as we use foundry as well, I mean, it's no, it's a it's a healthy part of these communities. And, you know, I again, it's yeah, it's something we we're developing a community, you know, code, code is a natural byproduct of a healthy community. And that's our number one focus should be how do we get the healthiest developer community going, you need code to act as kind of the honey for the for the, or the the flowers for the bees to gather around. We're building a hive, right? And I don't know, I could get my metaphor is right. The point is, yeah, well, I think we can manage this, I think we can take our inspiration from from Apache and others are I owe you and the rest kind of more zero participation in the exit criteria, drafting process. So let me take it as an action item this weekend to spend some more time. And maybe, maybe I could put a first draft together of what a release, release taxonomy might look like, in parallel to that exit criteria from graduation. So we can pull over anything that is product specific about what the product is expected to do into that separate document. Does that make sense? I think so. I think I don't know what's the point about the scope. I think if you made a real clean heart separation between the community versus the product, I think that could work well. Okay. Alright, and then I'm happy to continue working on the list with that in mind. And so, you know, focusing more on the exit criteria from the project point of view, and which will be more in line with what we see there on the Apache page. And so, you know, my expectation will be that we focus the list on this for now for the exit criteria of the incubation. And then the other dimension that people have brought up will be addressed elsewhere, including the release taxonomy. If everybody is agreeing with that plan, I'm happy to continue. Maybe a consensus of the TSC voting numbers. Yeah, we'll have to do it. Kind of around Robin. Right, we'll use PBFT for this. That's not funny. If we use proof of elapsed time, we'll never get it done. Yeah, because we can all go back and get our coffee and then come back and whoever gets back first wins, right? Eventually, we'll just make decisions like this on the blockchain and it'll be so easy. Yeah. Okay, I think we've beat that one to death. Can we talk, Dan, you want to give an update on the Saatu's Lake hackathon and then, I don't know, if she and is on, maybe he could get an update and some thoughts from his perspective. Yeah, so we were able to kick things off yesterday morning as planned. And I think we had good participation in the first kickoff meeting. We had been talk about a few project ideas on the fabric that were mostly quality oriented. And then we had Sean Amundsen, who's one of the sawtooth maintainers present a couple project ideas around transaction families. The one that the community picked up on the sawtooth side to run with is a battleship project. So we've been having fun with that. The idea around all of these arcade games over on the sawtooth side is that it gives you a way to exercise the system in the same way that you would with other sorts of real world transactions, be they financial or other. So we can exercise requirements like confidentiality. This battleship one gives a long running set of transactions. So we made good progress with that. We had some active contributors working in maybe awkward times. Have a chat out in Brussels. And somebody else working through lunch in Virginia. And so good all around first day. And we'll be picking stuff up after this conversation. Later this morning, we've got two slack channels active one on the fabric hackathon one on the sawtooth hackathon. And then the the other tool that seems to be common amongst them is the documents that Todd created. There's a Google doc out there. And that has the definitions for the projects that were proposed. And my team is continuing to evolve that document as we flesh out the battleship game that's being developed. For those who can't participate live in this virtual hackathon, put a link out in the chat there. The work that's the the transaction family stuff is based on a new tutorial that we've released on the sawtooth code base. So the link to the documentation is there. And so you can work through your own game if that's of interest to you, independently. Otherwise, like I said, we'll be reconvening after this meeting. And we can help facilitate connections with with any of the projects between fabric and hyper ledger or fabric and sawtooth rather. Thanks, Dan. Sheanna Ben, one of you guys on that might want to give a brief update on the fabric work. Yeah, sure, we've got a bunch of issues out there that are tagged as help wanted. And we've had a bunch of people kind of looking at those and picking up ones that look interesting and fixing them. And then on top of that, a couple of us have been looking at the go report card. You can see that if you just go to the main page of the fabric project and click the there's a badge that says go report. And we've been trying to clean up those remaining errors and then get some of that functionality checking in our build process. I think Dan did a good job of covering where to contact us in the Slack channels if you want to participate. Great. Thanks. Anything you know, Dan or Sheanna or anybody else who's been participating want to weigh in? Is there anything we could be doing more, less, better, worse? Feedback is always useful in these things. Well, I think we had very little planning going into it. And I think the fact that that we're making good strides without that is is a good sign. We're always open to new collaboration tools. The the battleship stuff has been being worked out mostly over Google Hangouts and the Google Doc. I haven't really had a chance to try some of the other tools that Christopher Allen had suggested. But interested in feedback or thoughts for further ways to get, you know, multiple hands into the same code while their eyes are on it. Thanks, Dan. So just as a general question, you know, and this is just day one, but I'd like to come back to this on Friday when we had the kind of wrap ups. But are the virtual hackathons as effective as the face-to-face? And I understand the cost and time issues, cost and time tradeoffs and other things like that. But I'm really curious if this is a model that we can use consistently going forward. My experience has been that I think they're not quite as effective as the face-to-face. But but I think in the future, maybe we could explore some additional tools. You know, if we if we had a virtual hackathon where, you know, we had a couple rooms full of people in different areas, and maybe we tried some kind of, you know, video conferencing between those rooms, I wonder if that's something that would help. Hey, this is Morali from DTC. I think more than the tools, right? I think it's the fact that we're still in the office makes it hard for us to take fully part in this virtual hackathon. We're still tied to the office. Yeah, I don't know if there's an opportunity to kind of block out time for people so that, you know, it's like you're traveling, even if you're still right is equal to normal place. That's a good point. Yeah, I think I'll offer maybe a complimentary viewpoint that this has been a little bit more productive from from my perspective, and that we've we've got participants from some geographically diverse areas that I don't know if we would have gotten if we had required a single physical location. And I think that whenever we're on given conference calls like this, if you've got a collection of people that are in a room, and then you've got a few people who aren't in that room, there's such a big divide between how those people communicate that it's not as effective. But if everybody's on the same playing field that everybody's remote and everybody is is collaborating through the remote tool is, then that communication is is smoothed out and evened out. And I think everybody's on the same playing field. Okay. Yeah, I mean, my personal take is that, um, you know, may take us time to sort of, you know, to get to the point where the virtual is as effective as a face to face. I think the thing that the face to face does is, and it brings people together, they're out of their typical, you know, distraction environment of the regular day job. And you know, where when people are sitting, you know, in their day job, they're going to be distracted all day. And so I'm not sure how much people are actually sort of devoting to this. It's hard to tell, you know, I think we'll see over time. But, you know, the nice thing about the face to face is it brings people to get you can also do more than just, you know, sort of coding together or, you know, collaborating meeting, discussing architectures and so forth, because it also gives you an opportunity to socialize. And I think that that's actually, I mean, open source is a social thing. Right? I mean, at the end of the day, that's really what it's about. And, and so it's an important function that we get to, you know, know each other better. And, and I think the face to face is very effective as that, whereas I think the virtual hackathon may get us, you know, to a point where we can have people online and so forth, but where, you know, I think getting people physically together, I think has an additional, an additional value that the virtual hackathon simply can't achieve. But again, you know, being able to pull, you know, Google Hangouts, it's an improvement over just Slack, it's an improvement over just email, but it's not the same as being there, as they say. Yeah, I like the idea of mixing it up and, and maybe continuing to alternate between virtual and physical. Yeah. See, it's inclusive in the sense of, you know, there's people that just won't be able to travel, people that aren't necessarily being compensated to work on, on this that, you know, aren't going to be able to reimburse travel. So however, we can include the most people and keep things, keep the mix going is, I think, helpful. All right. And for what it's worth, whenever we have these meetings, Chris, I'm drinking to be social. This is true. I'm with you there. Okay. So next up, I think with Greg, I think, I think we've beaten the hackathon to death. And I apologize, but I have to leave and I'm going to leave my vote with Todd and say, I, I approve. But Greg has a project proposal that he'd like to present on something called Chain Tool. And so I have to pack up and leave my room. I will try to dial back in, but I will have to sort of be off the WebEx for a bit. Thank you, Chris. Could someone give me presenter status if that's possible? Thank you. So I'm not sure which screen is coming through. What do you guys see right now? Picture of my daughter or a web browser. I have two monitors. I can see your browser, Greg. Okay, perfect. All right. So I'm not sure if everyone has a chance to review the proposal, but so what I have here is a tool that I've been working on for the last few months. The proposal could be summarized as just, I'm proposing to bring the repository of this code into the tree of fabric. The support for the tool is actually already in fabric. But let's talk a little bit about what the tool does. I wanted to just give a kind of brief overview and a quick demo of if anyone was interested. But in summary, you could think of Chain Tool as a kind of a compiler and build tool. What the pain point for me when I first started working, this was back before it was even a hyperledger project when I was over blockchain, was the lack of a formal schema definition on chain code and, and the life cycle, I'm sorry, the lifetime management of that interface. So if there's changes to the ABI and, and you know, if a long running application changes its ABI, how do clients adapt and things like that. So the pain point, the primary pain point for me was to come up with a more formal definition of the interface, make it language neutral and build in, you know, backwards and forwards compatibility features that you would expect to have for a long running interface. But in addition to that, I also tackled some other things that I saw, I thought could use some more formal definitions such as, you know, how, how chain code is packaged up and deployed. You know, the canonic, at the time I wrote this, the only support for chain code was for Golang, and there wasn't a real formal packaging. It was kind of an ad hoc thing. So I, I tried to come up with a language neutral packaging mechanism as part of this, and the tool helps to do that. So the base, the, the, in summary, the two basic areas it's tackling are language neutral definition of the interface with, you know, with schema management baggage forward compatibility and language neutral packaging of chain code for deployment on various languages. Now that being said, the mechanism to describe both of those things is, number one, there's a definition for a, an interface definition language to use to describe those interfaces. And there's also a, the concept of a platform with the idea that a, a, a project can declare that the chain code platform it's targeting and the tool will help to build the, the environment resources you need for that particular platform. Today we still only support Golang, but the tool could be extended to support other platforms as well, such as Java or whatever, or else people would be interested. But anyway, the, the, the summary of the tool, it has eight subcommands. There's, so on the, on the, kind of like on the build side there's build clean and package, which is what I think developers would primarily be using. It works very much like, you know, you might see in other tools like Maven or whatever, or Leningen we can say, you know, build or clean the project. The idea is really that as a developer the normal workflow would look something like this, where you have this iterative cycle where you're editing your code and you're using chain code build to test the the code compiles and doesn't have warnings and etc etc. But when it comes time to deploy it, you actually use chain code package, which, which emits a packaged up version of your code that you can deploy to the fabric. So the idea is that the build code, the build routine is primarily there to give the developer some fidelity with the same process that the backend will use when it, when your code is compiled for the, within the peer network. It also has benefits as a secondary feature to help with like dev mode. So if you want to build the binary and launch it in dev mode, you can use the build tool directly for that as well. But anyway, normal workflow is you iteratively go through build until you're happy and then you package and send it out. So what I wanted to do now is give a quick demo of that actually happening in action. So what I have here is a example, I took a port of the example two from the Hyperledger fabric code base and I ported it to the chain code, I'm sorry, the chain tool environment. So what that means is essentially I was taking the, the interface that was presented in the chain code example two and, and describing it in terms of this language neutral interface for chain tool. And what that means is when you, when you set up any given project, the, the code here, source chain code, source chain code area holds your project, the, the code for your project. There's two extra pieces of metadata that you attach to your project. One would be a YAML file that describes the chain code project and the other would be the declaration of the interfaces that the, the project exports or consumes, right, because you can also consume other, other chain codes interfaces. But if we look at chain code YAML for instance, we can see here that it, it does some basic things like declare the name and version of this particular project, but it also declares a platform dependency. So we're saying this particular chain code is built against the Nolang platform version one. Now right now the version one has no real specific meaning. What I intend is that if, if this were to be accepted, we could have the same kind of notion that you might have with like say Java 1.7 versus 1.8. It would mean specific things with respect to the ABI that that chain code could expect to be executed under. So that might mean minimally, you know, a specific version of the shim or any other libraries that we want to include that would be helpful for a chain code app. So it can say I'm compatible with version one and the environment when it's deployed to the network, the network will spin up an environment that meets that criteria. The last part of it is the code can declare what's called provided or consumed interfaces. So a chain code can provide exported interfaces for people to call into it and it can also consume interfaces from other chain code if you wanted to do chain code to chain code invokes. But the idea is that you could declare the interfaces that your project uses of both the provides and consumes capacity here and then the last part of it would be you know actually putting in these what we call CCI files or chain code interface files to describe those interfaces. So just briefly here if we look at the interface for this example this particular application has two transactions and in one query so this is a it's an RPC like IDL. It's very closely modeled against protobufs if you're familiar so the message definitions up here which constitute the parameters that we pass you know in and get a result out of our model very closely to protobuf messages. The only thing that's really different here from protobuf is the structure of the the transactions versus queries. Number one we split them out so that we separate transactions from queries so that we can route them properly within the environment. And the other aspect is that I really didn't like that the GRPC mechanism kind of got rid of the the concept of a tag or index because I think that's one of the functions that allows you to have better forward and backwards compatibility over time to have that semantic decoupling from the name of the function to to its index. So I tried to retain those two you know I wanted separation between transaction queries I wanted to retain the tags but otherwise it's very much protobuf looking like if you're familiar. But anyway so once once your project is set up with that structure you know so you have your code you have your YAML you have your interfaces we can then use the chain tool itself to do interesting things. If you run without any options we'll get that that list of help for the sub-commands and any any given sub-command you can run with dash dash help will give you more info. But in this case what I'm going to do is to start with I'll just say chain to a build and it's going to take that YAML take the code take the interfaces and compile it all together into a binary. So this would be a representation of you know the development process the iterative processes and making sure that my code actually compiles and has no warrants. Now when this completes in a moment I can say okay I'm happy with that it didn't have any errors so I'm going to take turn around and I'm still going sorry. So you can see actually in the background what's happening is the tool is actually using the protobuf compiler so I processed I parsed the CCI files and actually turned them under the underneath the hood into a protobuf file and I then compile them in this case since we're targeting Golang it's generating pb.go output from that and then I'm invoking go get and go build on the code and but I'm synthesizing things like the go path. So what's kind of interesting here is that the you know because a given project is going to depend on different things like it's going to depend on any of the libraries that the project itself directly imports as well as things that might already be in your go path like the shim code for instance there's various go paths that we actually build dynamically to assist with that so when the project is built can see over here we just created this build directory so this build directory is created by the tool as is building and we actually synthesize a few different go paths so one is the go path for your project itself which makes sense another is it inherits the go path that you had set in the environment but there's two additional ones so one is one is that we have this notion of build depths so that's where I resolve direct and transitive dependencies using go get and I stick them into your build area and the other is that we're actually synthesizing code in this case Golang code since it's a Golang project which I'll get into in a minute but all these things together get synthesized into one go path by the tool of this building so that it builds cohesively anyway so the the project is built I could say this point I'm happy with and I'm ready to play so the normal workflow would be someone takes chain tool and says package and that will generate what's called a car file which is supposed to evoke you know that the same kind of notion of like a jar file it's an archive a chain code archive so we take all the code and the metadata associated with your project and we package it up so in this case you can see the code and the inner CCI files in the ML are packed together it's very much an agus to a tar ball or anything else but there's some this is some additional chain code specific things in here such as you know we're going to compute the shot one of each individual file we're going to compute the shot three which actually I don't know what the formal hashing mechanism will be for chain code so it could be shot three shot two whatever we can change that but right now the demo is using shot three so I give it I get an overall hash for the chain code project itself the files are all compressed and individually hashed so I can you know get an idea of the specific versions including this package and it's now written to this car file ready to be deployed so from there I could then take the standard fabric peer client and upload this car into the fabric and it would compile it or I could do other things like I can I can do chain code chain tool ls if I wanted to see what it's going to run the same thing we just saw but if I had a car file I want to see what's in it I can do that I can do unpack and all the other kind of things you would expect but normally you would say okay I built it I'm going to package it I'm going to deploy it so for the purpose of demo it's actually a little bit easier just use dev mode so rather than deploy the car file I'm just gonna spin up the binary that I already built in dev mode so I'm gonna start appear is demoed here I'm going to I'm going to launch one thing I should show is when I when I did the build it emitted a binary in build then right so here's the binary that was the result of me running chain code chain tool build so what I'm going to do now is run that in the dev mode fashion so I'm going to give it the name mycc there's the peer address there's the binary so I launched that it's now it's now running in registered in dev mode and it's just waiting for a deploy to complete it so down here I have a client that I've written against this interface so I'm going to deploy against the chain core the register chain code mycc operation deploy and I'm going to give it some initial parameters now the initial parameters I didn't get into are defined by this app and it interface so this this a knit message defines what our constructor will accept so that's exactly what I'm filling in here I'm saying we have party a with named a value 100 this is an asset management application by the way if you're not familiar with example 2 so what I'm doing here is I'm establishing two accounts with a bounce an initial bounce in tokens of 100 each so I'm going to go ahead and deploy this and you can see the peer recognized the deploy and the chain code saw some activity there and we now have a status of okay so our chain code is now deployed with the accounts A and B with a value of 100 a piece and now is I'm going to do a couple different transactions so I'm going to invoke this check balance query for both accounts so see here it's on a check balance for the entity a and I can see here I got back a value of 100 which is expected I'll do the same thing for B balance of 100 you can see activity going on the back end and now I'll invoke the make payments I'm going to send 10 tokens from A to B so source party A so it does to party B amount 10 I'll execute that we got back a status okay so it worked and if I now do subsequent check balances between A we can see they have 90 and B they have 110 as we expect so nothing exciting there it's the same exact thing as the example 2 demo it just has the CCI slash chain tool interfaces on it so we could presumably oh one thing I do want to show that's a kind of an additional neat thing here is that there's a notion of a metadata interface so so we actually emit a dynamic interface into your code as it's compiling that exports metadata right now I don't really put a whole heck of a lot in there but we can actually query it so I can take any given chain code instance and I can run chain tool inspect and I give it the name of the instance in this case my CC and when I run it it actually goes out through the rest interface queries the chain code and comes back with information about that package so we can see here that we have the example 2 application version 1.0.1 snapshot it's running on go lang 1.6 the chain tool that built it was 0.8 snapshot blah blah blah we could add whatever facts we would like to see surface there very easily and also it tells us the exposed interfaces so this is saying this this particular application exposes these interfaces and I can optionally say dash i foo to download those interfaces into a directory foo and now if I look in foo I can see I have those files so I can say foo or CCI so now if I wanted to develop a client or a consumed interface in a different piece of chain code that wants to do chain code the chain code invokes I now have the interface and I can I can incorporate that into my workflow so that is kind of summary of what the tool does it's written in closure which is a language that I personally really like to code in it and it's well suited to developing compilers which is essentially what this is I don't know if anyone has any comments about the code itself or that the function of the tool or anything like that so I'll just open it up this is Brian do you see this as a contribution particularly the fabric or do you see this as potentially something that could be a standalone community and product underneath underneath Piper ledger like something related to fabric clearly related to chain code but potentially for use if chain code is perhaps even used in other other circumstances as well I think so I coded it with what became hyper ledger fabric in mind and so and there's definitely some opinions in there about what you know for instance the with the code that I generate is compatible with the fire the fabric shim that being said I'm sure you know with some refactoring it could be made more generic you know it is after all taking in an input scheme and not and has an output scheme and it's translating between the two so we could certainly make a translate to something else it would take a little bit of work to get there you know there there are some there are some you know check fabric specifics in there today that we'd have to tease out okay and it's partly a technical question it's partly also a community development question to like you know to support this well probably means building you know a proper community focused on it of lots of others so yeah so I'll kind of second what Brian saying with this is that you know part of part of me would say if this is if this is fabric specific first let me say this looks really cool so but if it's fabric specific you know do we need a separate project for it that being said you know I can really imagine how this could be generalized into something that that describes you know schema transformations messages transaction interfaces and the concept of this tool would be something to be useful regardless of what the underlying fabric or what the underlying protocols or mechanisms would be for so you know I guess I'm what on one hand I'm you know all in favor of improving anything but this looks like something you could general is very nicely yeah I think that's totally accurate I mean I'll be open to that too you know I didn't paint myself into the fabric corner to because I didn't think it would work anywhere else is just that was where the focus was I can see that being a general mechanism to describe an interface and emit code we'll just have to think about a couple of the way the codes unit today yeah this is Chris I'm partly back on the car though yeah no this sounds really cool and I like the idea of potentially having this be a much more general and generalized solution for dealing with deploying and packaging at the smart contract and so you know to that end I mean and and others would would there be interest in collaborating with Greg on you know taking it out of the corner that it's in and and helping to make it more generalizable and useful in the context of whether it's soft-tooth lake or for that matter anything else I mean I think I think that's you know the important sort of next question that we have to ask ourselves and who's willing to sort of to collaborate with Greg on moving this thing forward I can certainly do a little bit more digging into the description the only thing I had before was the was the project proposal page but taking a look at the code and just seeing I know that in talks with right now we have transaction specification file but it's really documentation and what I really like about this is you're taking sort of that that abstraction and making it it's more than a specification it's really a prescriptive description of what the behavior should be and the interfaces to it and and I mean we've talked a lot about you know what level can we start thinking about kind of standards and interoperability and this looks like a really nice starting place for it yeah no I I agree mick and so I'm glad to hear you say that just out of curiosity Greg and I missed the first sort of half of I guess your is the API definition stuff is that based on swagger or is that if I understand what you're asking so the CCI I assume you're asking about the CCI interface that ends up defining that the interface into the chain code yeah so so it actually isn't based on swagger it's it's probably best described as protobuf based but today it tunnels through the existing fabric interface so today when you have a call into the fabric you just specify a function in an array of strings for the arguments and what I do is I have a very specific schema for defining what the function name should be and then I I package the payload as the first parameter in the argument string is a base 64 encoded protobuf object so it's you know it's not it's not a standard it's kind of a merge between the existing fabric ABI and protobufs and obviously there's some flexibility there I mean we can if that was for some reason objectionable we can do it a different way that's just the way I did it for now and this is really one one thing if I can add I think this also takes us towards a step towards proper DSLs domain specific languages you know now that we have a mechanism to describe it as a higher level we could start injecting DSLs this kind of tech DSLs kind of approaches to using this kind of tool as well yeah and actually to that point that was one of the reasons I tried to stick to a reasonably ubiquitous mechanism like protobufs because they do have wide they do enjoy wide language support right so that I know the I think it's the DTCC folks are working on Java like there's no reason why Java could become a platform definition with a chain tool and it could still express its interface with CCI exactly the way we did it here just the Java side would be interpreting the messages via the protobufs support for Java and what you know so and so forth for any other language that we wanted to implement if it can support protobufs it could easily consume this you know that was part of I mean I know there's there's other ways to skin that particular cat you could do JSON RPC or you know any number of other serializers out there but protobuf is something that was both familiar to me how you know performs very well and is widely available so I based on it but there's other ways to do it should we approve this as a incubating top level project that could potentially evolve into something that's generally useful or we approve it as a sub project of fabric possibly with its own repository so that we could maybe then think about this down the road I don't know make you said you wanted to give this a little bit more thought like to get your sense of where you I guess it in the current form it didn't make sense as a sub project of fabric I think you know there's there's no way for us to lift it out as it exists and drop it in I and and in that context I'm completely in favor so it's like a great idea and and as a starting point it allows us to start really exploring some other some other ideas on this regarding that you know its applicability I mean I'm just what I'm doing is looking at this going yeah geez we could use something like this as a compiler for transaction families which would give us both you know client-side validation and server-side validation components easily that he rated but I'm not sure I would start with with this form of specification but the concept in the idea of this tool is something that looks really really useful and I say I'm not sure only because I haven't looked at detail to think about it as a multi multi backend application it's not that it not that it won't work but just that I haven't spent enough time looking at it so the thinking about it some more because this is the really first time I thought about this kind of off the cuff but you know I I think in terms of the overall support for an arbitrary concept as opposed to being specific to fabric would be fairly easy to do so that I already have the notion of a platform definition abstracted out so today I have the notion of like go lang is is or hyperledger chain code going but we could certainly change it to be or a hyperledger fabric chain code going and that's pretty much you know room for sawtooth or anything else to slip in a different one without any conflict whatsoever the only part that's that's really you know probably most fabric specific is the inspect tool because I do generate a fabric specific arrest call and that could either be something that we put as a separate tool or or we abstract that the concept of inspection out as well as part of the platform abstraction and then I think it would be relatively straightforward to put anybody else's support in there because the platform abstraction really so the the core of the code if you look at it it the core of the code is really dealing with the abstract syntax tree that we get from parsing the YAML file and the CCI files which are not they I don't think off the top of my head would be fabric specific and then the platform takes the AST and spits out in this case what you know my goaling our goaling fabric code but if you wrote a different fact if you wrote a different platform it could generate whatever code it wants to so I don't see that as a problem I think it could be achieved relatively in a straightforward manner obviously there would be some work to define the platform but in terms of you know dealing with the abstraction I think it's straightforward but we can we can take that as a offline conversation I mean I can talk to Mick offline and show them what the abstraction is and if we still think it makes more sense to start now as a sub-project and then we could always promote it at some future date that's fine too but you know I'll throw it out there so you get a chance to at least see where it's at that sounds good to me hey well thank you everyone that's all I have thanks Todd you want to take a quick roll and get a sense of the TSE please yep sure thing we may have lost one or two but I believe we still have quorum so I'll just walk through the list Emanuel all right I think we may have lost Emanuel Stan hey Stan so I I would agree with Mick that it would be great to include it the project I don't think it's ready to be at a top level so I would agree to include it as a sub-project of fabric although I think it may be actually more beneficial if there's some abstraction work done to actually figure out how to integrate it with sawtooth and reintroduce it as later as a top-level project Tamas I agree to include it to fabric okay Stefan agree to include it to fabric and then move on afterwards okay Harda yeah I'll say agree fantastic tool I think we did this one okay hard I agree with what everybody else is saying all right Oshima son I agree Chris yeah I agree as a sub-project of fabric but I think I'd make the recommendation that have its own repository to make it easier to tease apart if we decide and if there's interest from the community and and sort of turning this into something more more purposeful my more broadly purposeful so I would say yes as a sub-project but you know we should put it in a separate repository all right Mick I'm in agreement all right Dave I'm in agreement all right and then Richard already dropped so that is nine yes and then two are not here so that that passes unanimously from those on the call awesome thanks everyone so I apologize but I think we're beyond time and but this was a very good call I'd like to thank everybody for their participation and we'll talk to y'all next week thank you all thanks everybody