 There's our anti-trust policy. You have been warned. Thanks. So on our agenda today, pardon me, we have the EU hackfest update. Then I think we're ready for a vote on quilt, but we can have some brief discussion or longer if that's needed. I didn't see anything on the mailing list. Let me have a proposal for chain code designer that I think I'd like to just go through and have an overview presented and maybe some discussion, but we'll defer any vote for people to have time to think on it, and then we can have an update from Tracy on project reporting. Is there any other topics that people would like to cover today? Hey, Chris, sorry, my audio is still coming up. Could you repeat the first part of that? Where did you chime in? Where you were saying something about give people a chance to catch up before a vote? Oh, yeah, so we have two project proposals, quilts, which we've already discussed, and I didn't see any more chatter on the mailing list. So I think we're ready for a vote. We can have a brief discussion and chain code designer, which is new into the mailing list. I didn't see any discussion on the mailing list, but I think it also probably needs more time, and so I was saying that we would discuss it this week, but we would not vote. Thank you. I think there was just a little bit more discussion on the quilt stuff, so I'm looking to see if all the updates are there or not. So EU hack fest, Todd? Yeah, no update today, unfortunately. We are still moving forward with the planning on that, and we'll be in touch with registration details as soon as that's secured. Okay, thank you very much. Any questions on the hack fest? So maybe Todd, if we could just remind people of the dates and adding into their calling as well. Yeah, still looking at December 5th and 6th, but we'll send out final confirmation once that's locked in. All right, so next up is quilt, and let's find the proposal link, people. I just dropped that into chat. It looks like the last that it was an hour ago or potentially some just got accepted in. Yeah, I think it goes a little bit as Arnold pointed out. I'm sorry, Jonathan, could you say that again? I didn't quite catch it. Sorry, I'm saying, I think that I wrote also in the chat. I think that the proposal needs updating as per Arnold's email, unless you think that you're ready to vote now. I think, yeah. I didn't see our nose, no, let me just read it quickly. What's he? Do we have anyone from quilt on the line? Adrian or anyone? Hello? This is Michael from... Okay, I'm Michael from Ripple. I'm working more on the JavaScript code, but I also am in favor of the quilt project. And so Adrian is on another call at the moment. He couldn't make it. Okay, from everything, we are Juan Carlos and Enrique. Hello? Okay, so Arnold, you wanna reiterate the concern you had this morning? Yeah, so essentially, I think there are a couple of things. I mean, last time we talked about it quite extensively and I think it's not an easy situation with all the different plays at work in the different bodies that we talked about, Lauritry C, IATF, JavaScript Foundation, but at the end of the day, as I said last time, I think it's workable. So I don't think there is much concern about the project itself, but the proposal is written, is not very clear on what the scope is. And I think this needs to be clarified. And mainly it's a matter of, is it really just about primarily implementing the interledger protocol, in which case it should just say that, or is it broader than that? Because the way it's worded, especially in the first paragraph, is kind of very broad scope of interoperability between ledgers. The main objective will be just to implement the protocol that basically means to interoperability amongst ledger, but just for the use case of value exchange, not just every type of smart contract. This is just an specialized protocol for payments. Let's call, let's say that. It doesn't cover all the use cases of every smart contract. The final objective will be just if somebody want to exchange assets from one ledger to another ledger. At this moment, I'm not aware of a standard protocol to do that. So everyone has to create his own code, create his own protocol, and the final objective is just to have the protocol making it compatible with the existing hyperledger ledgers. Just that, it's relatively close. The objective is, sorry, I mean, it's quite centered on our use case, on a single use case at this moment. I don't know if that's clear or you need more explanation. So are there built-in, in the protocol, are there built-in extension capability for us to add in additional assets transfer later on? Otherwise, if that's the case, then the project should be narrow to value transfer only and shouldn't be named as general as interledger protocol. Well, the case is, I think the confusion here, it comes from the ledger. From our point of view, a ledger is just the classical ledger that where you store balance and assets for different accounts. But I observe you extended the term of ledger to something that can also execute smart contracts. Angron, about that? I don't think what you're hearing is not so much complaint about that scoping, but that the proposal doesn't capture that scoping. That the proposal comes across as a very broad general, lets you interoperability between all ledgers, but there's nothing in, but the reality and the response to the comments is it's about payments. It's about an implementation of the interledger protocol, not about the connectors that are gonna be necessary in each of the components. It's about, as you say, traditional ledgers and value transfer, not about kind of generic interoperability. And the proposal doesn't capture that specificity. Okay, I see. I see what you mean. I think maybe one, I don't know about what the plan is for this project, but I do know the way we do it with the JavaScript project, which is at the JavaScript Foundation. We have an RFC's repo under interledger and that's generic independent from programming language. And then for JavaScript, we implement those specifications. And if something's not clear about how it should work, then that's outside the scope of this JavaScript Foundation project. It's just implementing what the specs project specified. Right, so what I think you're hearing is that if we just say that, that this project is intended to be a Java implementation of this specification, nothing more and nothing less, I think then the people that you're hearing from would be much more comfortable because it's clearly scoping. And we can add in essentially the essence that it's about an interledger protocol for exchange of value to even further clarify it, but by making the point that it's an implementation of that specification, I think. Oh, I have, well, I don't know, maybe three points, right? So I agree with, yeah, I think that's what we need to clarify. We need to, if we narrow the scope to payment, so even if we say something and I'm not trying to oversimplify, if you're just talking about like a two-phase commit, right? So you have to prepare in the commit and then we say separately, we have connectors. So if you can just simplify that and just to be clear that the protocol allows you to do that in a, let's say in an accessible way, that will be easier for everybody to kind of relate to. Second thing is, what is it? If we had a spec that is already approved with the JavaScript guys, what is there any difference between that spec and our spec? Because I'm trying to understand the relationship between the JavaScript implementation and the Java implementation. So, okay. Henry, can you help me with that? So, in principle, the JavaScript intention and the Java implementation will target the same use case, the same objectives. So, there must be a completely interoperable amongst each other. So you have one specification, right? That the JavaScript... Yes, that specification is the request for comment, the RFCs. The RFCs. Yes. But that's gonna be, we're gonna do exactly the same thing just in Java? Yes. Okay. All right. So maybe you should, I don't know if it's written like that. So, maybe that would be helpful as well. So, I saw the reference, yeah, to the Intelligent Payment Community Group. So, here's what I would recommend. Well, first let me ask this. Are there any other remaining concerns other than the scope discussion we just had? Is there enough diversity on the developer proposed maintainers kind of list? Is, I think, perhaps something else for the TSC to just ask and see if there's more that could be done to recruit potentially more volunteers. So, I see three vendors represented in the list of committers. Ripple, it's NTT data, right? In the form of Everest. Are you counting those as a suit number one? There's also applied payments at the bottom, but it's dependent on availability. But, I mean, realistically, we've started projects with fewer initial committers. Again, this is incubation, not graduation. I think on graduation we would expect higher degree of diversity, but... Yeah, I'm satisfied with that. I'd ask Adrienne to... So, any other concerns? Help clarify the commitments there. To another point on the scope discussion. Yeah. I don't feel that it's... If we're just listing, or if you're just listing hyperledger framework integration, because that feels like a gate that you would need to clear to get into hyperledger, I would discourage you from doing that. If the main mission is really just to connect existing payment networks, then I would again try to be more precise about that. Yeah, right. And I wonder if we're getting hung up on payments, too, because I think in most ledgers, not all of them necessarily, but in most, you're going to have a digital asset of some sort. A land title, a carbon emission credit, and payment is really just a transfer of one kind of asset to another. And the assets are always going to be locally defined to each ledger. So, I'd encourage people to think, don't think of this as like a bank transferring a payment to another bank, or from Bitcoin to Ethereum, or something like just limited in that. I think it's perhaps not so broad as to say it's all sorts of types of interactions between ledgers, but it's payments of digital tokens or digital assets of all sort. It seems to me at least the most I, as for you to understand it. Yeah, so here's what I would recommend. That we send this back to Adrian and request clarification and being a little bit more prescriptive as we've discussed about the scope, that this is about implementing RFC, whatever it is, and nothing more, nothing less, and removing the language that sort of hand-wavy tries to describe interoperability between all the hyperledger projects. And I think we're ready to vote, and then we can do an email vote once the document has been updated according to those changes. Everybody agree with that? Anybody disagree with that? Okay, I'm not hearing anything. So I think, Todd, we have an approach. I will send a note sort of writing that up just after this call. And then once Adrian gets back and says they've updated the proposal, Todd can send a vote out. Sounds good. Okay. I'm just getting a question from Adrian on the chat. He is asking, why should the scope specify the language? Is that, can that be left open? The language is Java, I thought. Yeah, cool, the Java script is fine. I mean, look, if we can move Java script project over from the JS foundation to this one by Brian going over and talking to Chris, I'm okay with that to have them side-by-side as they're implementing the Java script and the Java implementations. I don't have a problem with that. But I think the question would be from a developer community perspective, with this project. Everybody said, hey, we wanna do an implementation in Rust or in Go, right? So could run natively inside Fabric or in Python. Would that, those efforts be done inside the Quilt project as separate code bases with separate release streams or something like that? Or would Quilt be specifically about the Java implementation of Interledger? My recommendation is, yeah, leave it open and allow for the developers to tell us what they prefer in terms of granularity. Yeah, I don't have a problem with that, actually. Yeah, just like we do with SDKs, right? Yeah, it's very similar. So we're doing an API and interface and then people can implement. Yeah. I mean, one thing if Hyperledger were, you know, all about just Pythoners, but we're not, clearly. Yeah, yeah. No, the only concern, maybe it's a side comment, right? Is the JavaScript implementation more mature or less mature or equivalent? I just feel that if you're gonna do everything about the JavaScript, I'll feel bad that we are like behind. We can catch up, but... At this moment, the more mature is the JavaScript. Is there a reference implementation? Let's call it. Yes, okay. Yeah, I agree. I don't think we should limit ourselves to a language. If you prefer to have something more generic and talk about any implementation of an RFC, yeah, that's fine with me, Jonathan. So I'll send that note and we can vote when after Adrian has updated. So thanks, guys. Let's move on to the chain code designer proposal. And I think we have, we have Bei Wang on. Is that right? I think I saw him pop into the video for a second. Bei Wang is not muted. So are you there, Bei? Hey, can I talk? Send a WeChat to him or something? I don't know if he's maybe just sort of walked away from his... Oh, he can hear us. We can't hear him. Maybe you're muted. Oh, it says you're not muted, but maybe you're muted. Yeah, maybe he's muted. Can I talk, Bei Wang? We cannot hear you. Yeah, I suspect that's what's going on. Oh, maybe he's down. Try it again. I think he's dialing in again. I just saw it. Can we move to the next item first? Yeah, I think that's fine. I did see him just pop in, so I'll just give him one more second. But I don't see him on. Well, I guess we'll move on. So Tracy, I hear reporting. Get that in until Bei Wang gets connected again. Okay, so my internet is also not very good. So hopefully you can hear me. With the project reporting, there was two comments that came back on the mailing list. One was from Brian to do a rolling schedule for project reporting. So we talked about doing project reporting every three months, but Brian suggested that if we did a rolling schedule, then we could make sure that we were pretty much constantly reviewing the projects as they came in. We could decide on, you know, maybe the first meeting of the month or something to do the review so that we're not reviewing every week. Oh, I actually took it the other way, thinking we'd have rolling reviews, so we wouldn't be doing them every week. I mean, we wouldn't be having to cram and review a bunch of things before the meeting. I hadn't intended it to mean like, you know, the city heartbeat once every other meeting or every third meeting, we'd have one report to review, discuss, and approve. Right. That way, rather than having eight once a year or eight once a quarter. Right, exactly. Yeah, so I was thinking the same thing, Brian, that we would spread them out. And so that's what I had, that's what I had intended to say if it didn't come across that way. I'm sorry for that. So, yeah, and then the other comment is the one that you had Chris around the date maintainers last at it. It seems like maybe you would instead like to just report on who the maintainers are and what their diversity is. And those were the only two comments that we had on the project reporting from the last email discussion that went on. Yeah, I mean, my concern is that the churn of maintainers isn't necessarily a good sign. And so I think, you know, it's fine to sort of report, but I wouldn't necessarily use it as a yardstick. I would think that there should be at some point certain amount of stability and then periodic, you know, there would be a little bit of turnover in the maintainership, but at some point you reach a sort of a steady state. And then people, you know, if they change jobs or they decide they wanna go off and do something else or they decide that they don't have enough time to do reviews anymore, that kind of thing. And so periodically you start having turnover and then, yeah, sure, you expand the project and you know, there's new areas of the code to be covered and so forth. And you might add a maintainer or a three, but again, I don't necessarily think that, you know, looking for new maintainers is necessarily a good thing, but the diversity is definitely something that we should be looking at. And if it's persistently low, then obviously we can have a conversation about that. If it remains a pretty high percentage of diversity, then I think that's a good thing. I think it's easy to report, you know, new maintainers added since the last report, right? Just report it as a bare fact just to see as a, it doesn't necessarily have to point to churn. I think just knowing a project's alive and paying attention to the flow of new developers in is a useful thing. It doesn't have to be a date last added. You can just say, hey, this quarter we added, you know, this maintainer, Bob, he's great. And then on the diversity metric, that might be harder for projects to self-report on until we get to tooling that might make that easier. So, you know, I think if it's, as long as it's easy for any projects for the board to look at and drill in and see, you know, is it really one person kind of running the show or is it multiple? Then I think we'll be in a better spot. Oh, diversity is pretty straightforward to measure because it's a small set typically. I mean, you know, a dozen or less. You mean like employers or ethnic and gender or? All of those. I agree. I mean, measuring the diversity of contribution is a little bit harder because not everybody uses their corporate email. And so there's a certain amount of email mapping that's gonna have to go on to try and track down and figure out, you know, the diversity of contribution from the community generally, but maintainership I think should be fairly straightforward. Anyway, so, okay. I think then we're, I think we're good then with Tracy's proposal and so Tracy, what's the next step? Are we gonna have like a template on the Wiki that we can? Yes, definitely. So what I'll do is I will change that to basically new maintainers addicts since the last report just to address the comment that you had, Chris. And then I will make sure that gets uploaded as a template such that when somebody creates a new page in that particular location, it will pull from the template and then they just have to fill in the details. And then the other piece of it is really just the rolling schedule, right? Defining what that rolling schedule is, which I'm happy to put out something as a strong man for people to review. My thinking is like just pick alphabetically and go from there. Or you could just put names in a hat and draw them randomly or whatever. I could do that too. Otherwise, everybody's gonna name their projects. Thank you very much, Tracy. Now is Beguang on, I guess we'll have to defer this. Oh, go ahead, Tracy. Do we need to vote on this proposal or anything? Or is it just like, let's go. Okay, let's have a vote. All right. Is there a link to the final version of this proposal then? The template, that's the only thing it's in the proposal. We're just voting on the template, right? Yeah. Right, with the one modification changing the date maintainer or last added to new maintainers added since last report. And the link the link to the template that is in the agenda, email. And the chat. Excellent. Somebody just, oh yeah, Todd just put in the chat. All right, Todd, you wanna go around the room? Sure, Arnau. Arnau, are you there? We'll come back to him. Baohua. No, I guess I need a more review. Chris, do you wanna give people a minute to have a look through or continue with the vote or? Baohua, when you said you need more time, you need more like five minutes or another week? I guess another week. Anybody else in that same position? But I just didn't wanna necessarily delay this much further. Okay, Baohua, if you need more time, I think we can work on that. I guess. Yeah, maybe we can go with email vote. Okay, so Tracy, why don't we update the, thank you, Baohua, why don't we update the template and then Todd can send out an email vote? That's right. Thank you very much. Thanks, Baohua. Okay, and Baohua rather is still not on, I think. See him with a green audio. Yeah, I do too, but we can't hear him. So I don't know if he's got a problem with his audio or what, we have to try this again next week. What I did think we could do though since we have time is maybe just a quick recap of the hack fest for some of us who weren't present and we can just sort of go around the room and invite people to sort of reflect on their experience and whether they thought it was good, bad, or indifferent. I personally thought that it was certainly a little bit more engaging from a hands-on keyboards perspective. It wasn't quite as much hacking, over-yacking as I might have envisaged, but it was still, I think, a good improvement. And I think a lot of people had an opportunity to sort of do at least a little bit of hacking or exploring of other projects, which I think is, it's a step in the right direction of where I think we need to be trying to do more of exploring the other capabilities in the adjacent projects and thinking about areas of opportunity for either integration or interoperability or certainly of sharing of ideas across projects, I think is a good thing. And I think we had some good discussions on Indy, on Sawtooth, on Composer and on Composability just generally Jonathan, I think, led a nice discussion on that. So I was very pleased. I wish I didn't have to leave so early in the afternoon on Friday, but that was the only flight I could get, so. I don't know if anybody- Yeah, so, yeah, just one of the version. I think it's funny, right? We wanna have people hacking and getting, kind of getting dirty with the code and committing, but, and we had these sessions, but I think it's also, it's because Hyperledge is kind of positioning itself as a kind of blockchain for business or enterprise kind of great implementations. And I think it's good that we also see business people coming in. Like the discussions that I had with many people, they're like integrators. Many of them used to work in very large kind of advisory boards, you know, like a KPM. I met like a few people from really different, different kind of sides of the spectrum. And they're like just trying to see, okay, I'm trying to see what can I do with Hyperledge? What are the projects? Just to get a high level, because I have a lot of people that are technical, I'm trying to understand how can I propose it? So it was kind of, it was a lot more interesting to me to see these kind of discussions. It's more extended than what we have in San Francisco. In San Francisco, usually we talk about road maps, you know, just historically, right? The two outcomes that we had and people are trying to kind of get to see how many bugs are left. People are trying to see, okay, where are we going? Where is Hyperledge gonna be in like three months time, six months time? I think it was very refreshing to see it. Yeah. I like that, I think it was a good event. Dan or Mick, Rono or Nate? Yeah, this is Dan. I thought- Go ahead, Dan. Yeah, well, I guess one of the things since Nathan was about to talk that I found it a good opportunity to get to sit down with Nathan and crew there to start to get up on Indy. I would have liked even more time to have hands on keyboard. You know, it's definitely a balance to strike where it felt always that there was a need for the audience that was there to learn very, you know, one-on-one stuff about Hyperledger that it felt like we needed to have agenda and presentations up to talk at them from the lectern. So it would be good for the next one to think more about how we can balance that effectively so that we could continue to put more emphasis on the hands-on keyboard time. One of my other takeaways was kind of like Jonathan was saying that it was good to hear the perspectives from Chicago. I didn't have insight into a variety of things that seemed to be going on there with respect to blockchain. So continuing to move these around to different cities, different regions, different parts of the world, I think, will be informative for us as a community. So just one observation on that, that I know both for both of Indy and Soutooth, having a little infrastructure that could do a kind of local cache of the files would have made life a lot easier for a lot of people or a lot of us were sort of sitting around waiting for downloads to finish. So infrastructure-wise, if we're gonna do that kind of mass download with 30 people chunking down 100 megabyte files, it might be good to make sure that we've got the infrastructure to do it. You know, that'll have people come prepared with thumb drives or something. Or have some instructions sent out ahead of time to preload some of that stuff, that'd be good. That's good point, Nick. Thanks, Nate. I think I'm just gonna echo some of the same comments that Dan and Mick said. I was caught a little bit by surprise, but by how much talking people wanted to have. I came prepared to kind of do some hacking on some of the specifications and try to get some interoperability code going. So I ended up spending a lot of time talking and not as much time coding up some things. But I think, like Jonathan said, that was kind of just the natural consequence of who attended and what they wanted to do. And then having some more infrastructure, like Mick said, for setting up some of those things and also maybe some advanced warning about what kinds of tutorials we wanted to do before the hack test started would have helped us be a little bit more prepared to have kind of some thumb drives or whatever else was required in order to make sure we had the ability to bypass network bottlenecks or what have you. So I think it went really well. I think there was a lot of really good discussion. I especially like kind of the interoperability round table discussion we had early on, I think it was Friday, where everyone kind of got to just talk about what interoperability they were hoping for. I think some of those discussions were really productive. Thanks, Nate. Anyone else? Any of that captured? What do you mean? Vivian? Oh, you're off. Discussions about interoperability, for example, where a lot of interesting points came up. Did they get captured in some way that you can actually go back and say, we hit some of these points or we did not? Because I remember that in the early days of the identity working group, we did, like for example, in JPMorgan in Brooklyn, we wrote down a lot of things that seemed to be coming back over time. So it would be interesting if, at least some of the salient points were captured that it would, you know, it would help one, the people who were there, of course, to reinforce their memories and also to help the people who are not there to understand, especially in the broad brush areas, like, you know, what you guys were talking about just now. I guess the answer is no, but yeah, I don't think that anyone took notes. Yeah, it's a good point. Unless all the people took notes, I didn't take notes. Perhaps, you know, a couple of folks who are leading the discussion could put together something from memory and distribute it. Yeah, yeah, we should do that. Yeah, because we had really a lot of discussions, that's right, yeah. We can probably put together a dog. It's a good idea. Mark or Dave or Arno? I can initiate. We had a lot of discussions about interoperability, if you remember, when we talked about like reusable components, and then we had some more discussions later with Meek and Gary and we talked about like, actually where my proposal was not going well and what else can we do? So maybe I can try to summarize and then we can review it. Stan? I'm just looking to see if anybody else was there. All right, everybody else wants to remain mum. So there's one comment that would make, I mean, you know, as a follow up to the discussion about the hacking versus talking, we go over this over and over. And I think, you know, the point was made that, you know, this is kind of what people wanted, talking. And I think if we want to have more coding instead, maybe we need to have that as a set agenda so that people who come there don't expect anything different because... Yeah, I hear what you're saying and I've been struggling with this because, you know, frankly, I keep thinking to myself, two days really isn't enough because by the second day, you're really just sort of getting going and you really want to sort of, you know, keep that momentum. And, you know, as Mick said, or Dan, you know, you actually want to start getting your hands dirty and starting to actually get, you know, indie running on fabric or sawtooth or whatever it is. And then you're all running to catch a plane. So I realize that there's probably also never enough time, right? And that's a reality. And so maybe the thing that we need to do, Brian, I don't know, is think about maybe we have, you know, a day devoted to yacking and then another day where it's a little bit more yacking and smaller group, you know, breakouts and so forth that, you know, we tried that, you know, to say the afternoons are for hacking, but we still ended up having somebody on stage in almost every breakout period. So, I don't know, we... No, Chris, on that note, just to say, I was, so I just came back yesterday from Nashville and Brian Belendorff was there and Tracy was there and a few people from Hyperledo were there and what they had, they had like, it was distributed health and they talk about, you know, how to use blockchain and technology in healthcare and stuff. And they had a separate session which was kind of a code camp where there were four projects, I don't know, it was a Hyperledo Composer, Gem, Quantum, which is an open source kind of implementation on top of the Bitcoin stack that allows like smart contracts and it ends up with block apps. So some of these, I think that some of these events were kind of, some of these workshops were sponsored. I was moderating, but what was interesting is actually that crowd was a lot more likely to become a contributor to one of the projects because you saw like all the, you know, the other C-suits and other suits and the healthcare discussion talking about market opportunities, but then the code camp really had people that looked into the code, tried to download, play with Git and it was a very different crowd. And of course the discussions were very different, right? So maybe it's not going to be a bad idea to separate if we are trying to look for contributions and people kind of joining the projects on the code level, and then separately to have the business guys kind of getting more aware of what the Hyperledo can do and what we already have. It's not a bad idea, I'm just saying, I've seen it like this all this week. Yeah, one thing I was going to suggest was, I mean, there were a lot of new people for Hyperledo, if you will there, that were there to learn about it. And so, you know, what it competes with, we just want to go and hack on code. So maybe we have, you know, at a third day at the beginning though, where anyone that's coming in to learn and we get them up to speed, you know, with people explaining what's going on and all, and then they can contribute when it's time to go do the coding. That's, I'm kind of liking that idea of a day of presentations and status updates and where are we and where are we going, kind of, you know, for each of the projects and maybe work groups. And then, you know, for the new people, and then we can focus a little bit more on the hacking part of it for two days. So what about combining some of what, what about combining some of what Tracy's been doing requesting with the project reporting pieces of it. So, you know, you do, on one day, we just have 15-minute report outs from the projects as part of that, I think that, again, that sort of provides at least a little bit of an introduction to what's going on. Because, I mean, there were enough new people there that there's no way we could have just jumped right in to just hacking. And, you know, and I know that, Brian, that some of this is coming along, but, you know, having a YouTube video that sort of introduction to Sawtooth and Burrow and Fabric and whatnot, you know, would also be a good thing. And we can make sure that we advertise that for new people that sign up or register for a hack fest so that they have an opportunity to hear some of that and then they can focus a little bit more on some deeper discussion on actually getting up and running and so forth. Yeah, so I've said this before, but I think a good way to do this would be to have presentations in the morning and then explicitly ban presentations in the afternoon and have that be hacking time or something of that variant. I also think one of the issues is that recently we have not had a lot of, you know, clear defined hacking goals for these hack fest. Like someone says, hey, you know, we're going to try to do X at this hack fest. I think that would make hacking a lot more likely to happen if there was some sort of collaborative project that was well-defined that people wanted to work on. And maybe a reality to recognize with that too, that was, you know, if we're gonna have something like, making Nate want to do something on an identifier, that's maybe two or four people that can participate in that hacking. It's not necessarily a room of 30 to 50 people that can all be working on the same problem. Yeah, it's a little different than if we were doing a bug squashing day or something. Yeah, exactly what's supposed by Chris and Bren, we have some old bug fix hack fest. And I would like to suggest we let those call developers to sit down inside all those new beginners and to show how they fix those bugs and to help the new beginners learn the projects quickly. Yeah, I was just thinking about it. Because you have so many maintainers, it's gonna be a lot easier to have like a task or added by crashes or a small task or an extension that project that the maintainer can push internally and help the newcomers to feel in a sense of accomplishment, right? Within a day or half a day, yeah. I was gonna say, you know, about the topic of not having enough time, you know, and having 30 people in a room trying to download images and get all spun up. What if we went into the hack fest with sort of preparatory homework? Like, hey, we're gonna have a session on Indy. The only way this is gonna work is if everybody does steps one, two, and three before they come. So like, you know, go and follow this short tutorial on getting, you know, your image set up and so that you can at least spin up a node. And then when we get there, then we can really dig into let's build a network or deploy some chain code, that kind of thing. Like, it seemed to me like we wasted all of our time just trying to get everything downloaded. And we didn't really get into the meat of the technology. Well, yeah, in terms of hacking, I would agree that we spent, you know, many people spent 15 or 20 minutes just downloading code that didn't get us. Well, internet... Or an hour because it was an ISO that was 500, you know, 500 megabytes. Yes. Yeah, so... But yeah, maybe there should be like a standard, like, do these things to get yourself ready for the hack fest. And then if you didn't do those when you show up, then maybe we can have someone volunteer to say, you know, over in this corner, I'm gonna run everybody through the tutorial, you know, that we sent out, you know, so that you can catch up with everybody else so that the existing sessions aren't overrun by people going, you know, I'm not downloading the image or this step in the tutorial is wrong, you know, Git doesn't work that way anymore or anything like that, you know. Sort of like a, yeah, come up to speed corner. So, you know, we have a little bit of time before the next hack fest in December. And so I think, Todd, that what we ought to do is we ought to put some thought into the next one. And I would actually propose that if people are willing to have a work group that comes up with ideas about how to improve the hack fest, make it a little bit more about hacking than yacking and having, you know, something for noobs. And I'd be happy to lead that. I don't even wanna call it a work group or a task force, but we have that and we still have to go back to the GitHub stuff, but I'd be interested in doing that. Cause again, I think this one was an improvement over the past, but, you know, we're not there yet. Yeah. Can we ask in the registration, can we just explicitly whether people are interested in coding or not? Because I'm always curious like what percentage of the attendees are, as Jonathan pointed out, you know, kind of more business oriented who are interested in seeing what Hyperledger is about. And if people don't have a coding background, it's going to be kind of hopeless to get them to hack. So I'm curious if we could get some kind of metric as to what percentage of the people showing up were in this category and what, you know, we're kind of ready to hack. That might actually find a home in our community survey. Tracy, I see you're on the call. What do you think about that? I mean, you know, we could do a section of have you attended Hyperledger meetup. If so, what was your primary interests and checklist? Maybe you did cover that already. Yeah, the survey went out already. So it would be, it would have to be a separate thing. I think it makes more sense to do when people register, just provide the information. Yeah, so I agree with Tracy. I think we, you know, the different HackFest might have sort of radically different people, you know, like I would imagine, you know, a HackFest in the Bay Area would probably have a lot more percentage of coders than one in say like Washington, DC, but you never know. So yeah, I would love to see this like a week before HackFest. So that we could kind of come up with the plan. Well, I didn't hear a whole lot of people chime in, but I'll at least start a thread on the mailing list and maybe we can get some ideas about how to... Chris, I'm happy to participate in that. Thanks, Tracy. Yeah. Okay, well, we're out of time. And unfortunately, we didn't hear from Bayline on his chain code designer proposal. I would suggest people again, review that. Let's discuss it on the mailing list and we'll try again next week that I think we'll close the call. So thanks, everyone. All right. Yeah. Thanks a lot. Bye. Thanks a lot.