 Thanks, Todd. Sorry to interrupt. Hi, this is David Pinsky with Hitachi. I'm filling in for Ashima-san who's traveling today. Okay, welcome. So on the agenda today we have hackfest planning, another refresher on the internship program, which is accepting applications. We have a draft of the requirements working group charter to review. We've got a proposal to start a new project around the go SDK client for the fabric. We've got the fabric composer proposal, Sawtooth demo net from Dan, and then follow-up Q&A on GSL. Are there any other agenda items? It's a pretty packed agenda. If not, then I think we should get going, Todd, on the hackfest planning and then hopefully we'll achieve quorum before we have to build on stuff. All right, sounds good. I'll move quickly through these. For the April hackfest, we are still looking at the week of April 24th East Coast. We have been talking with a few companies that can potentially host. Unfortunately, those haven't panned out. If anyone on the line has venue space in their office that could potentially work, please get in touch with me ASAP. Otherwise, our events team is exploring paid space. We're hopeful to get something locked down by tomorrow, but it could be early next week. From there in June would be the next next hackfest. There's a couple things going on there that we're looking to tie together. LinuxCon China will be having its first year in Beijing June 19th and 20th. We will be having a hyperledger track there. Looking at likely having a hackfest run concurrent to that, as well as doing a hackathon over the weekend prior June 17th and 18th. Any questions there or initial feedback? I'm sorry, so you're looking for a location in China? The location we're just looking for in the week of April 24th on the East Coast. Could be New York, Boston or any of the surrounding areas. Okay. And that's during the week? During the week would be preferable, yeah. So we'd be looking for two days. I think we could even extend it to Chicago or Washington DC as well. Well, if no comments there, we'll continue exploring behind the scenes. Any questions? Please get in touch as soon as possible. Yeah, so I know there is another recent member who potentially has some space in Boston, but not the week of the 24th. Is there any possibility of changing the date? There is. Based on the feedback we got, it was pretty strong that people wanted to get together the week of April 24th. I think the week before was the second best for folks. Otherwise, we'd be looking at pushing a week later, which, you know, not ideal, but still possible. Right. Okay. I'll connect you and then we can, you know, if the dates could be fun to go, we might be able to do something in Boston. Okay. How many people do we have to host? It's typically around 75. I think the most we've seen is around 90. A fewest is around 50-55. Okay. Alright. Internship. Internship program. On the Hackfest and Acathon and Linux con in China, Brian, do you want to just sort of say a couple of words? I mean, I think we really do want to try and get a critical mass of the TSC in China. And maybe, you know, you want to talk a little bit about what we were thinking about for that. I know what you posted to the mail. Yeah, sure. So this was partly inspired by, you know, what was, well, by many accounts, a successful hackathon, but one that probably we felt could be more specifically about the core code on the projects or potentially building sample applications that would also be good additions to the repository. You know, in some ways it kind of became a business plan competition more than a hackathon, which I think is very normal for China. But what I would, Chris and I talked about was the potential of steering it very much back towards the idea of a competition between teams who would be brought up the learning curve on a given hyperledger platform and then tasked with tackling, you know, bite-size, you know, good beginner bugs in the issue tracker or small to-do items, things that are, you know, sharp edges that could be rounded off, the kinds of things that are good first-time developer activities. And then at the end of the weekend, basically the teams would be evaluated on kind of a subjective sense of, you know, who got the most done. There wouldn't be any obligation to upstream and accept patches during those two days, but the idea is during the next two days at the HackFest, we'd get developers together to actually evaluate what had been done by all the teams and see if we can mainstream them in. So very developer-focused, but it really only works if we have a nice critical mass of core developers on, you know, a number of the different projects. And so I don't have to hopefully make the pitch for China and just the way that it's growing there. And I think the strategic importance of us being there, I do know it's a bit of a haul, but I'm sure if there's questions about visas and other things, we could get that answered. But if we started planning now, my hope is that we could get a reasonable contingent out there for it. But I really want to hear from the rest of the TSC if that's something that they buy into as well. I think I'd like people to consider the ask and maybe ask your management chains about the travel and so forth near significant others. But I do think it would be worthwhile to get us all together in China for that event. I think, you know, having sort of a bug-sloshing, you know, type would be a good thing for all the project. I'd also invite you all to submit talks for the track, the hyperledger-related track that'll happen at LinuxCon Asia, that'll happen concurrent to the HackFest, and hopefully we'll get a space just right next door for the HackFest to LinuxCon itself. But that could be another another pull to come out and participate. Okay. Next up is the internship program, Todd. Yeah, just a quick note there. So we will close the call for applications at the end of next week. So please share this out to your networks. And I'll include a link for how to apply in the minutes that go out. That's that. Okay. And Senator Bawa, you're saying that the internship program cannot be applied from China? Why is that? I'm not aware of that. I can answer that. Yeah, I can answer that. So, I'm sorry, Bawa. I'll go ahead. So there is a law that was passed that came into effect at the beginning of January that makes it complicated for US-based nonprofits, including consortia like us, to operate in China. We work with that law and deal with it wherever we can. Right now, we don't have a way to do the internship thing around that law, really. We are looking at some possibilities, but we just can't commit right now to having interns in China because of that. So it's not our choice, not about resources. And it may get addressed, but not in time for, likely not in time for us to be able to choose China-based students. There's a small chance that we'll keep trying. All right, that's fine. So, Todd, it's currently restricted just to China-based students. Is that correct? For the internship program? There may be another country or two randomly that we can't work with, you know, North Korea, for example, but it's pretty wide open. Okay, but we only have one project, isn't that? That we would need to source with students for China. Is it just one project? And I think there would be... What sort of response do we get into the applications? Have any been submitted for the China project yet? I'll need to go look. We have had a decent number of applications. We have no geographic barriers in that someone has to work in the same city or same country where the project mentor is. This is completely virtual, so that shouldn't be too much of a limiting factor for folks. Okay, that's good. Thanks. All right. Okay, that's unfortunate, but let's move on. So, next up is a requirements work with charter draft. It's only gone. Sorry, just one question on the internship. Yep, go ahead, Dan. So, I started routing people who have been querying me to that link that you provided, Todd. I'm not sure what the hiring process is going to look like or the selection process, so I assume that when people reach out to us, we're supposed to give them clarifications on the project proposal, but that it's the Linux Foundation's decision process for who is selected. Yeah, and we'll definitely involve the mentors in that. This is not something we're doing behind closed doors by any means, so we'll kick that off after this closes on the 24th. But yeah, any logistics questions, whatnot, please just direct them back to us. Okay, and so you set a date there for when decision processes start. So, the call for applications closes on March 24th, so Friday of next week, and then we will work through that all the following week. Okay, great. Thanks. Okay, so I don't see Olegon. Is Olegon the call? Anyone else from the requirements group that can defend, if you will, the charter draft? If not, we can bump it. We have tons of stuff on the agenda. Alright, I suggest we bump it, Todd. Let's move to the go proposal from Securekey. Alexander, you want? Hi there, Troy and Alex are here. So, alright, let's review the proposal, and this is the link, Todd, in the chat. Yes, and if either of you would like to be made presenter, let me know. Otherwise, please. Yeah, I don't have the go to meeting or what we're using open, so I guess if we just go through the dock could probably be the easiest. Okay. Alright, so how do you guys want to work this? Well, I think you don't have to go through line by line and point by point, but maybe just sort of outline what the proposal is, and in particular, I think, you know, focusing on, you know, the resources that are going to be working on that, and then we can have a discussion. Okay, perfect. So, there's two major points in this proposal. One of the points is to have a go-based client for hyperledger fabric, and the second point is about extensions to the specification also written in go. The purpose of the extensions is to, for example, allow the peer to actually create transactions itself, so to allow a peer to itself be a client. So, in the reference tickets, as examples of this, there are several features that would have to be part of a go-based SDK to enable that kind of functionality. So, this proposal is really about both enabling a proper go-based client and also these extensions to allow the peer to also act as a client. There's a couple other things in here as well that we referenced, which was we also put a proposal out there about other forms of certificates where the client could potentially make its own kind of T-shirts. So, we're trying to say here there's a proposal for the go SDK, there's a proposal for the peer to act as a client, and also a discussion on other potential features in fabric-based clients. Did that motivation make sense so far? Yep. Okay. Do you guys want to pause for discussion on that or keep going? Are there any comments, concerns, questions from the PNIP Gallery? Keep going. Sorry Chris, I was just going to struggle to come off mute. I just want to add I support the notion of a go SDK, especially if we can get everything refactored, the CLI and whatnot refactored. I would say one comment about the T-SERC changes, I would suggest that whatever is being proposed there be worked through the SDK working group because you would probably want unity on the other platforms as well. Yeah. So those particular things, particularly the T-SERC change, should go through the various groups. It was just making a comment in here that to actually support those kind of T-SERCs that you'd have to actually change the client SDKs. So it was just kind of a related point that we've been thinking about and working on. But certainly something like that, as it changes the peer itself, has a larger discussion to be had. Yep. Anything else? Okay. So in terms of the resources, typically one of the things that we look for is, and I should have taken time to look at this, but one of the requirements of a proposal is to identify who the maintainers would be of the new project. I know there was a little bit of discussion in the mailing list. I think Brian's suggesting that we should treat these SDKs as sort of independent projects. So I think that makes a certain degree of sense. So one of the things that we will want to do before we actually approve this is get the names of who would be the maintainers and who would be the contributors to the project going forward. Sure. So on that point, so as stated in the proposal, we'll contribute to our initial code base. The link to the current code base is at GitHub and in this document. SecureKey itself is continuing to work on this code. So certainly we would like some SecureKey people to be part of the maintainer list as we're continuing to put effort into this. Do we have a difference between sponsors and maintainers? I mean, I see on sponsors three from SecureKey and two from IBM. A third sponsor from a third company may be nice, but I consider this probably diverse enough to get started as long as we focus on growing that over time. Should we just adopt the sponsors as maintainers? So we're okay with that. All right. So I just put out a note shortly before the meeting, which I'm sure nobody had a chance to read yet, but what we had done historically with SDK projects or really generally any project that was uniquely feeding into an existing top-level project was to fold that work underneath the existing top-level. And I think some of the reasons for that were that that top-level community has kind of the best say in the merits of that sub-work and then also there's kind of the chance of a perfusion of projects that aren't necessarily independent because they all kind of ride on the success or not of that top-level one. So from my perspective, I think it makes more sense to have some kind of sub-project where an SDK like this would feed underneath. The examples pointed out in the mail as well were within Sawtooth, for example. We've got a few different SDKs, but those are kind of underneath the main project. Yeah, my take is that the granularity of projects is an important question, something definitely worth talking about. And we shouldn't overshoot. I mean, it'd be hard to stand on top of hundreds of modules, but we shouldn't undershoot as well. The risk of having too much activity buried inside one monolithic project is details might get lost, important code coverage might be lost. I think you'd end up with a situation where an SDK kind of gets maintained by one active person and then it becomes theirs and people kind of ignore it. Whereas if it's a separate project, it can become clear if that project becomes more abundant because the activity, you know, it's easier to track from a health and activity perspective. And the granularity should really match to a scope for a project that calls for, you know, something that can be kept up and maintained by six to a dozen developers. Any more than that and it just gets kind of too large, smaller, and you probably have too many. So there's the question of things that start out specific to one framework and maybe over time can generalize. So like Composer is likely something that starts out with fabric, but could generalize the way that Cello has. It could even be the case that these SDKs do, but I don't want to trap that in as a requirement just yet. So I think we just go with what seems right. This SDK probably is complex enough and having an independent set of maintainers probably useful enough to have it be independent. And we could talk about whether the SDKs for Sawtooth should be independently promoted or maybe as a group promoted as one project, you know, the Sawtooth SDKs project or see if there's a way to merge them into these SDKs. But I'd rather go forward and approve this than subclass it in. And then finally, we do already distinguish between framework-style projects and modules. And we could probably, you know, when we list the different projects at Hyperlenture, we could probably list them differently such that Sawtooth and Fabric and Aroha stand out distinctly from things like the SDK projects, just as layers of a layered cake, so to speak. There's the three things in the front of my mind, but I would recommend going ahead and approving this. Right. And Brian, I tend to agree with that. And I would note that also the current set of SDKs that we have, aside from the Node SDK, which was part of the original Fabric, are all independent projects in the sense that they have a different set of maintainers based on, you know, how they were added because of the contribution. And I think, you know, that the point of if we were to treat all these as sort of sub-projects and Fabric, and the Fabric maintainers then become the maintainers for the sub-projects, then that, I think, would be, I think it would serve to potentially discourage contributions such as this from Secure Key. So, because then, you know, in doing so, you're sort of seeding, you know, control of the project. Yeah, I was actually looking at it from the opposite perspective that that the, maybe not necessarily the exclusively the maintainers, but kind of more generally the community around Fabric is the one that's more knowledgeable to say the relative merits of a particular SDK. For example, I see there's a little bit of a chat that there might be an alternative Go SDK implementation. And so that's where it's maybe the having the DSC as the gatekeeper. Yeah, I tend to agree. This is Leonard. SDKs can be quite complex in their own merit. So as a separate project independent, but I think closely tied for collaboration with the parent project, the most informed set of people to be disappointed. Yes. Wasn't there, this is Vipin, wasn't there a SDK working group proposed and sort of fallen by the, I guess, it didn't really take off. So, right, so we, that's right Vipin, we had a an SDK working group and they came up with a specification. And then when we were going through and thinking about chartering, you know, putting together charters for all working groups, the SDK working group felt, well, our job is done here, right? We wrote this back and everybody's going off and implemented it. But they didn't write a spec. I'm sorry, let me just finish Vipin. And so I think, you know, the decision a couple of weeks ago was basically to move on, but sort of, if you will, disband the SDK working group. Now, with the Secure Key contribution here and the proposal that, you know, not only do we have a go SDK, but also we started thinking about how it might be extended down the road. Then I think that it might be the case that, you know, resurrecting the SDK working group to coordinate between Java, Node, Go, and Python SDK projects to, you know, coordinate on what the specification was for the SDK kind of makes sense again. So, I suspect, you know, and I'll talk with Jim and Morali and Troy to figure out, you know, is this something in Bawa to see if this is something that we probably want to, sort of, resurrect and move forward with a formal charter and so forth. But Dan's point was, I mean, basically it should be something spanning the different DLTs rather than specific to a certain one. I mean, I get both points meaning, you know, if you keep everything under, sort of, subsumed under fabric, then we may not have multiple maintainers. But at the same time, they also do not get any incentive to start supporting other SDKs like sort of like Go SDK or whatever else. So, there has to be a movement also to bring those together because otherwise we are going to have a proliferation. So, there has to be some kind of thought put into that, especially in the proposal for, you know, some kind of a future action. I'm not saying that they shouldn't be allowed to be a separate project. All I'm saying is these thought processes have to be part of, you know, the initial proposal because I've seen several of those projects which are supposed to be spanning other, you know, other DLTs. Right. Do not, do not span because, and they don't have a motivation and they don't have, you know, maybe because there's no need or whatever. I mean, I'm not going to go into that. Well, so here's where I sort of, you know, plug for, you know, as Brian would call it, the duocracy. And, you know, my, my perspective is if you have an itch scratch it, right? I don't think that we should be necessarily in the business of trying to sort of force fit, if you will, some sort of homogenization of all the different under a lot, you know, top-level DLTs that Earl Ha saw tooth and fabric. I am fully supportive of efforts to try and, and have them, you know, sort of consolidate to a certain degree. But I don't think it should be forced. I think that if people are interested in driving for and striving towards some sort of a top-level SCK that can indeed satisfy, you know, that is consistent across all the different DLTs for hyperledger, that would be a good thing. But somebody's got to put some effort into doing that. There has to be some sort of motivation to actually do that work. And I don't think it's fair necessarily for somebody who's coming in saying, I have some additional capability that I'd like to bring to the table for, you know, like this go SDK for fabric to sort of force them into, well, now you have to do something for everybody. You know, I think when we get to the discussion on composer next, that indeed there is a strong potential for that to happen because of its architecture. And, but again, it's going to require somebody to actually do some work to make it real. Can't just sort of Well, this is coming from a user's perspective, right? This is coming from a user's perspective, which is proliferation of multiple things all over the place is very difficult to manage for us. In fact, that is a motivation behind working in all these working groups, architecture working group, identity working group. So I am proposing that the SDK working group be also resurrected and look at this at least, I mean, not say, okay, don't come into the, you know, into the incubation stage, but at least try to bring, you know, this kind of a breath, breath into the situation. And that was my message also to Roger Nestone about composer. And I'm glad that, you know, they're thinking about this. This is purely a user perspective. So, Chris, just there are two issues that feel like to me that are being conflated here. One is that the issue of do require projects to be cross-platform on that. And that just doesn't make any sense to me that we require lip service to being cross-platform. The second issue, which I think is the one that Dan's really bringing up, is the question of who has the insight to do an evaluation of the details of a particular project. So as more of these projects are becoming more and more specific to platforms, we're getting to the point where a subset of us is really the only group that has broad enough knowledge or deep, sorry, deep enough knowledge to actually make a reasonable evaluation of it. And going back to Brian's comment before about, you know, sort of layers of a cake or whatever, you know, it definitely feels like there's, there needs to be at some level a segmentation of these that would allow us to communicate clearly about the positioning of each of these projects, right? So someone's not going to go to the go SDK and say, you know, well, why can't I use this for a ROHA? They're going to understand that this is something extending the functionality out. So I completely agree with the distinguishing and separating the maintainers of the projects and the administrative structure on it. And I also believe we need to find some way of making sure that we're both evaluating and communicating the relationship of these projects to the platforms as well. And I don't see that right now. This is Leonard here and I think, yeah, I mean, definitely SDKs can be a separate project because there is inherent complexity and they have a tie dependence, as you say, with the upstream parent project for which that SDK will serve as a kit as a development kit. And that having been said from different points of view, the SDK working group is that body, which will do exactly what you just said to ensure that we can look at all the different SDK projects as we understand resources and the lessons learned from each SDK project and look at the best, look at best practices to see how we can standardize that new aspect of development. So I think, yeah, the SDK working group is important to have. It needs to be resourced and most likely it may be resourced from people working on the different projects contributing to the SDKs to start off. But I still think they're complex enough modules that should stand in their own rights as individual projects, but with tight dependency and collaboration with the parent project. Well, I think that that's sort of a given. So, thanks Leonard. So, Mick, just back to your point, because I was struggling a little bit with trying to understand where you were coming down. So I understood the first point and I think we're aligned on that. I think though that I guess I'm still not clear in terms of establishing this as a project, are you suggesting that it's not clear enough that this is a fabric specific project or were you just making a point of, well, I guess I'm not sure on that second point is what I'm saying. Okay, so part of this is that I'm trying to restate what I heard Vipin say, which is, as somebody, Vipin's comment, as I understood it, is that as somebody who is a user of this, the positioning of the projects and the relationship between them is not obvious. So that communication side of things, just sort of understanding and communicating the relationship between them just seems like a good thing. That's not a comment about the projects or the quality of the project, right? I'm perfectly happy with the proposal piece of it. My bigger issue is I don't really feel qualified to provide feedback on the details of this project because of the level of integration that it has with fabric. My biggest issue is that many of these smaller projects are becoming so specific that for me to really evaluate its usefulness and its intent, I need to be much more deeply involved in the fabric community at a level of engineering that I just don't, I'm sorry, I understand your stuff when I talk about it at a high level, but at the level of which I would be required to evaluate this, I just don't have that background right now. I mean, I could read to the document, the document looks fine, right? It looks like a valuable thing. Hey, this is Morali from DDCC. Go ahead, Morali. You're very faint though. Is it better? I think so, yes. Yeah, so I've heard Mick and Wip and sort of aligned with them in terms of I think these projects, it's good that we want to share these projects put forth in front of the TSC so that everybody knows that these things are being worked upon with collaboration with other companies, but at the same time, I don't think these need any approvals from a TSC members, right? So these should be shared and communicated, but not necessarily, these are not necessarily top-level projects which need approvals from TSC members, so which could be the balance that we can strive for. So let's do a couple things here because we're running short on time and we have another two, three things to go through and I'm not sure we'll get to all three unfortunately. Let's see if we can get a vote on the SDK and then what I would suggest we do is we tee up some discussion and some, you know, towards a resolution in the next week or two on how to deal with this sort of two levels of stuff if you will, right? Where you have a top-level organizing principle such as sawtooth or fabric or roja and potentially sub-projects underneath that that people might want to bring to the table and then we have the top level and do we need to sort of break out and have two levels of incubation if you will or two levels of review and so forth or maybe we can have a discussion about maybe the TSC sort of, you know, if somebody's bringing in a project that's specific to sawtooth or whatever that they go to the maintainer, the existing maintainers of those projects and ask their sort of advice and consent so to speak on the proposal. But for now let's just sort of go through and do the go SDK and if it doesn't pass and we need to have more discussion I'm happy with that I guess but I'd like to try and put it to a vote. I didn't hear anybody sort of saying that they had disagreement with the proposal or any fundamental concerns other than maybe not being, you know, as Mick and I think Dan were alluding maybe not deep enough to understand if the proposal is sound or not but I suggest we just sort of take it to a vote and see where we go from here. Yeah I agree Todd and just one quick question, do we have a project approval process in place? So if it's deemed a project it has to go through an approval process and that's where it's outlined in the the life cycle. So that's where a lot of the merits of whether it should be a project have it should be handled should be agreed on before it is approved that's a project. It's got the criteria and the criteria is outlined in Vippen's proposal template that this one followed. So Todd you want to call a roll on on the go SDK please? Okay sure thing. Ben? Yeah I think from the SDK point of view I'm fine with it I'm still looking at the set of items there that require the peers to be modified still hesitate to talk about that but you know in the spirit of the SDK itself I'm fine yes. Okay Chris? With the same caveat that Ben had I'm fine with the go SDK and obviously the other conversations would have to be had between the other projects. Okay Dan? So like I put in chat I think we had a very congenial group and it's it's uncommon for us to disagree on anything in this case though I think as a top-level project despite what looks like quality contributions from code and intent I don't think it really serves as a top-level project so I vote no. Okay Greg? So I understand all the points of view here I I think the SDK is useful I would want to have further review of some of the details like Ben and Chris have mentioned and and I can appreciate the perspective of Dan so I'm in favor of having the SDK I would be fine if it's a sub-project I don't know what the mechanism would be to to approve that or not so I'm just going to say yes but I'm fine if we want to make it a sub-project. Okay Hart? Yeah this this has been an interesting discussion I'm going to vote yes with the caveat that we have further discussion on uh dependent projects. Okay, Mick? Um and as I said before you know I can read the document the document looks fine I just I don't feel qualified to evaluate the nuances even if I mean even the comments that Chris and Ben just made or things I would not have gotten out of out of looking at the document in the in the description of it um so I guess I'm going to abstain on this one I don't feel qualified at this point to make a sound decision on it. Okay, Morali? Yeah so I'm yes for it but like Mick said I don't believe it's a top-level project that we need to vote on. All right, Shihan? Yes. All right so Chris that's a six yes one no one abstain. I think that passes so um okay and and whether we consider a top-level or sub-project I think we can um I like I said I'm going to suggest I I tee up a conversation around that so that we can actually have um you know an articulated policy because I I I definitely appreciate Dan and and Mick's position on this and I would feel similar you know if if somebody came in and said hey I want to start a top-level project for some you know Ruby SDK for for Sawtooth or something. Well yeah and and I and by the way I wouldn't be surprised if you start to see some things like you know especially with the architecture that Dan's doing you're going to see projects like we want to do the the GO based transaction family engine for Sawtooth and are you comfortable evaluating that that would be my question. Yeah I think exactly to your point and so you know again I think you know maybe it comes down to you know and again I you know I was I was I was going more for well I don't want to sort of just have the fabric team start up projects or sub projects and seems you know as if they're going around the process I didn't want that either and so again I think it's worthwhile that we as a TSE come to an agreement on what this process should be and how it should be managed consistently across the various top-level projects that that we add so I'll kick that conversation off after after the call here. So let's listen. No I'm just starting to say Leonard here that that supports Dippin's point in resurrecting the SDK working group because a lot of that might come under their domain so. Yes I agree. Okay so quickly because we're really running on the time here so Simon are you on. Hi I'm here Simon here. Simon great you want to go through the Composer Proposal and somebody. Sure. I'll put the link in the chat. There you go. Okay. Okay and so for those of you that haven't seen it Fabric Composer or Composer for sure is a layer of abstraction that we've been working on for a little while and it's a layer or a framework that sits on top of a blockchain or distributed ledger technology so we're not implementing another blockchain or DLC technology as part of this work. And we built it as a result of some work that we've done working with lots of clients around solutions built on top of Pat Brent and from that work we identified that there are a lot of common elements to all of these solutions or business networks as we saw it. We see a lot of work around modeling blockchain solutions using assets, participants, identities, transactions and registries. It's very difficult to take those business concepts from a real-world business problem and map them down into underlying blockchain code and it's quite a difficult transition to go through that work. So the motivation of the Composer project has been to accelerate that development process and by providing a layer of abstraction that allows business analysts and application developers to model their business networks and implement it at that level without having to worry about the underlying technology so much. And we're hoping that this will quickly expand the number of blockchain solutions that are out there. So any questions on that? So I'll continue. Oh, okay. And so if I start going through our sort of main components. So we built a custom modeling language that allows hopefully all kinds of different developers to model their business problems. We can model it at the business level so you can describe the structure of an asset or a participant and even model relationships between assets and participants and transactions as well. We have the ability to encode business logic that has transaction process functions and you can do that in standard JavaScript code. And we pick JavaScript because it's really quite a popular modern programming language that is used by many developers around the world. We've implemented declarative access control using Active Control List. And those rules allow a developer to decide what resources can be accessed by which participants and we automatically enforce those rules without the user having to write any access control code. We have some clients of administrative APIs in Node.js only at the moment, but we're not strictly tied for that. That's allowed developers to build applications around the business network running on fabric. We have a web-based playground tool. There's a bunch of links at the bottom to all of this, by the way, that allows new users to come along to Composer, start modeling a business network, learn the language, test it out for the safety of their web browser. And something we've done that we're quite proud of really is the ability to run all of the code in browser without having to connect it to a real fabric instance. So we can take our client code and our runtime code and run it in a JavaScript engine inside the browser. Because in a lot of cases when people are coming along to this and wanting to model their business problem, they don't really need that underlying technology until they're ready to go a bit further with it. We start rolling it out, we start doing a bit of testing. We're looking into REST API support using the Loopback framework so we can generate business-centric REST APIs from the model of a business network. And we have a Loopback connector that provides that. We're looking at ways to plug into editors. So we've got Atom and Visual Studio Code plugins that are very new. They just do syntax highlighting at the moment, but we have some ideas about how they could be expanded. And we're also looking at application generation using the Omen framework to sort of give a bit of a boost up and get them up and running so we can generate, we can take the model of a business network, generate a basic but functional Angular 2 application at any skilled UI developer could take and morph into a proper designed application. And so everything I just went through has been open source. We put that in at the end of January just before the Hackfest in San Francisco. It's on our fabric composer repository and part of this proposal is to move all of that code into the Hyperledger project. We're considering some big work at the moment. We're looking at first class support for events. So events outbound from a business network. So if something happens on the blockchain, an asset gets traded or created, then I want an event and I want to be able to hook that into my existing business processes. We're interested in links between different business networks. So having one business network running one fabric and another business network running on another fabric and allowing them to communicate with each other and share assets and participants across those networks. We're interested in complex query support as well. So being able to do both historical and complex queries over assets and participants that are recorded on a blockchain. And one of the other things we're interested in is if the community is investigating adding support for the other distributed ledger technologies under the Hyperledger project, so our Rohan and Sortie Flake. As I mentioned, we have support for running standalone in the web browser and to make that possible, we built an abstract and an adapter layer into Composer that makes it possible to switch out the bits of code that we always fabric or in that case, the web browser. So there is definitely a strong possibility that we could look at moving that to the other distributed ledgers. So in the how-to, we've got links to all our public documentation, our GitHub repos, our issue tracker as well. And we also do a lot of automatic builds and publishing to NPM and Dr. Huff, including a public instance of the playground on Bluemix. And we're holding a call next Thursday. It's on our wiki. I think I included it in the, or maybe I included it in the mail for the mailing list. It's next Thursday and it's sort of an introduction to Composer, so I appreciate it. Not everyone's seen it, so we've got an hour long call to go through in detail. So any questions? I have several. This looks really, really interesting. So let me just make sure that I understand sort of positioning how this fits in. So there are a number of kind of contracting languages that are coming out, Ivy, Damo, and some others like that. This feels like the beginnings of a platform-independent contract language. Would that be an appropriate positioning for it? I think so, yes. So we've only looked at fabric support, but yes, it could definitely be platform-independent. In fact, the code is, I would say, 90% platform-independent as it is today. And architecturally, you have the adapter that would allow you to map it down. I mean, okay, I wouldn't be surprised if semantics kind of bleed through because this is where we start from. But architecturally, your description looks, I mean, it looks like you've architected it in a way. It could be adapted down. So I guess my question is really the specification language that you have at the top. Yes, it is the modeling language. Yeah. Shall I show you? Can I share my screen? That's probably the easiest way. And I asked, I was looking earlier for some example. I was just looking earlier for some examples. The only one I could find was in the tutorial, which is really simplistic. Okay. So can you see my screen? Yep. Okay. So we do have some very basic examples, but we've been looking at working on creating very sample business networks that are stored on GitHub. If it's going to work, yep. It's getting there. Sorry. Slow network distance. And so this is a list of sample business networks that we built so far. So the one I showed at the Hackfest was the car auction business network. I don't know if you've seen that, but we've got one around financial bonds, one around digital property, which is the one from our Getting Started guide. We have our favorite models trading sample. And you went around perishable goods tracking. I'll just open up the perishable goods one. So Simon, this is Chris. We're running out of time and we're losing a couple of... Oh, sorry. Yes, the member is here. So what I would suggest is we pick this up next week. And you mentioned there was a call on Monday to go over this in more depth. Is that right? No, it's a Thursday call. So it's actually after next week's TSC meeting. Oh, after. Oh, that's kind of late. Okay. Well, that's fine. Well, we'll pick it up next week. And I think everybody, please do feel free to sort of follow up on the mailing list. Yeah. Any questions? Please give me a shout. Yeah. And I'm sure the team would be happy to respond and do take an opportunity to go and check it out and kick the tires if you have any specific questions. So I think an apology is to Dan and Mick on the Sawtooth demo, a net discussion and to Tommosh if he was on for the continued GSL discussion. But we're at end of job and a little bit over time actually. So thanks again, everyone. And we'll pick it up again next week. Thanks, everyone. Have a good day. Bye.