 planning for the hack fest. We've got the requirements working group charter now, well hopefully he's only nine. Oh yeah he's on okay good. So we'll go through that and there's the fabric from composer proposal that we ran the clock last week. So hopefully we can wrap that one up. And then there's the whole discussion of top-level project versus sub-project versus whatever and there's an email thread here. And so I think it'd be worthwhile to have a bit of discussion there and maybe come to some decision. We had I think some good discussion on the mailing list and then at least we can come to a decision on how we want to sort of wrap that up. Then there's again we sort of ran out of time when we were discussing the GSL the global sync log from digital assets and so I think that some people had some questions and so we can give Tomas a little bit more time to field some Q&A and then there's the internship program reminder that the deadline is tomorrow for applicants for the internship program. So actually Todd since we don't have corn once you put that after the hackfest planning and just cover those two topics up front. Yep sounds good. So really on the internship program that that's the major thing if you know any students or have any connections at universities let them know our deadline is end of day tomorrow. We've received a lot of good applications but it doesn't hurt to see a few more come in at the very end. And then on the hackfest front apologies for the delay here we do have a really good option we're in final discussions with them hoping to close on that. We've let them know by end of week if that does not pan out we will move to one of the paid options and get that secured for next week. But you know really hoping to host this with a company just to save some funds on that front. That's that for those two and so back to you Chris. Okay thank you. So requirements working group draft and apologies I've been completely flat out this week and last with travel. So I'm oh like is this the final draft is this the version that the working group has sanctioned and said we'd like to go far with this or is this still yes this is this is final that's what's been accepted by the group to move at our meeting. I just checked the the wiki I see that it's not on the wiki so last thing to do is just put the final uneditable version on the wiki. But the same as I presented last month we discussed your suggestions and we follow from through we added the close but collaboration removed close about disbandment and it's pretty much stays as it used to be and it is final. Okay are there any substantive changes since the last time we reviewed? Well I see I see kind of since it's a live doc about interoperability use cases I guess we can include it as well but otherwise it is the same. Okay all right I seem to recall I mean I think there was I don't think that there was any controversy the last time we went through this other than you still wanted to make sure that you gave the working group an opportunity to to noodle on it and make any any changes and come up with a formal proposal. So given that I guess we can open it up to questions from the Pima gallery for Oleg and the requirements working group on on the proposed charter and once we exhaust the questions we can take it to a vote or maybe send it back if it needs to be edited. So any questions from the TSC any concerns from the TSC? Okay is this thing on? Hi dad. Okay then I guess we can take it to a vote so Todd do you want to do the wait do we have quorum? No we're still one shy so just checking quickly have been Mick or Tamash joined at this point. I'm reminded that I think Mick is at a sort of research conference today. Okay so Chris we're one shy we can push this to an email vote today just noting that there were no no questions comments or objections from the seven TSC members here and hopefully we can close on that through email. Yeah thanks Todd I think that sounds like a reasonable proposal. Do you want to send the note or do you want me to do it? I can get a note out right after this call. Okay thank you. All right next up is fabric composer and again we sort of ran the clock. Simon I think I saw you on right. Yeah hi Simon. Awesome so you want to remind us all where we left off and and maybe a link to the proposal in the chat is oh there it is thank you. So we went through this last week. Can't hear you. Sorry can you hear me now? Yes. Great so we went through the... Simon you've got an echo echo echo. Are you on a headset or are you on my what medium are you using? Hey there. You're very faint right now. Okay so let me just try a different mode. Oh he's impacting the station. Oh that's not good. Is Catherine or... This doesn't seem to be working I can't don't think anybody can follow what's being said. I'm not sure if he's still listening or Simon is there. I saw him drop off the go-to meeting. So where's all the background now is coming from? I think it's independent. Simon is back on the meeting. I don't think he's the one who generates the background noise that we call we all listening to what the hell this is. Hi Simon here can you hear me? Oh great. Sorry guys we're a bit short of office is my desk phone is apparently pretty rubbish so. Okay but so there's somebody else who's generating noise it'd be nice if we could shut that off as well. Oh seems to good now so go ahead Simon. Okay Simon proceed. Okay so last week I covered the proposal document I think we went through all of it actually where we just discussed that composer is a layer of abstraction that runs on top of a blockchain or distributed ledger and it provides a level of business abstractions that make it much easier and quicker to develop solutions on top of this technology and so it's not a blockchain or distributed ledger by itself. I covered all the components that we built and some of our future plans and since the call last week we had a company called Ox Chains come in as a sponsor they're very interested in building formal verification to the proposal language to verify smart contracts or business network definitions and so are there any questions on the proposal left over I know we finished when we called it quits last week we were discussing the feasibility of porting it to other ledgers I think hopefully I answered those questions. Yeah maybe you can remind people of the architecture that essentially allows for a back end to be you know to have a plug-in so to speak maybe could. Yeah sure so 90% I would say of the fabric composer code base is platform neutral there's two parts that are platform specific and we we have fabric implementations of those parts the first part is the connector part which the client uses to communicate to the blockchain or to the platform rather we have a fabric implementation of that and the second bit that is platform specific is the bit we call the runtime container so we have a whole bunch of common runtime JavaScript code that implements data validation transaction processing but we obviously need to bind that to the platform somehow so we have a runtime container layer so in order to port fabric composer to other platforms we would need a implementation of a connector to enable client applications to connect in and a runtime container to allow the platform to host the composer runtime code. Hey Simon this is Dan I missed part of your presentation last week so I apologize for that in in looking through the proposal I it wasn't clear I had assumed that what composer did was it was like a code generation tool to generate chain code can you help clarify for me that role versus some of these runtime aspects where it sounds like you're directly connected to a live network. Sure so we don't generate any chain code we're not doing any code generation at all what we are doing is we have a generic composer framework chain code which we called the runtime and you can deploy business network definitions to that runtime and they are the business network definition is a collection of model files describing the structure of assets, participants and transactions in the network and also JavaScript functions that implement business logic and we call those transaction processor functions. When transactions are submitted to the business network running on the blockchain the runtime picks those up and executes those JavaScript functions that the user has built. So it's listening on the network for transactions and then it's no no no so I think Simon I think there's I think we need to have clarity about the fact that maybe I'm mistaken about this but I don't believe composer is involved in the runtime aspects of things we use composer to create a model and we populate a runtime we populate chain code with the JavaScript and then that just runs in the fabric right. So we have a common chain code that is business network independent and that executes JavaScript code that is stored in the business network definition which is stored in the world state on fabric. So our client APIs wrap the fabric client APIs for use of a connector and they submit fabric transactions to our chain code which in turn executes composer transactions and those transactions occur within the chain code that is on a fabric node or those are executing on some other node. Correct the transaction the composer transactions are executed in the chain code running on the fabric nodes. They interact with the fabric APIs through our runtime container abstraction layer to interact with the world state. Sorry I have to mute everyone I can't just mute a phone caller so Simon let me take you off mute and anyone else that wants to talk you'll need to go back in and take yourself off mute. Okay so did you catch my explanation or do I need to go through that again? I think I got that so could you maybe just speak a little bit more about the definition of business network in this case? Yeah sure so business network definition is a collection of three things there's a composer model file and that's sort of like a schema it describes the structure of the assets, participants and transactions in a business network. So the set of properties on an asset and the ID for example or the color of the asset and a set of relations to other assets or participants in the business network. So for example a car asset might be described by the make model and color and it will have a relationship to an owner participant and so the owner who owns the vehicle in that case. You might have different types of participants in a business network such as owners, regulators, in the UK's case the DBLA, manufacturers who create new vehicle assets and we also have a set of definitions in the model file for transactions so the inputs to a transaction. So when I'm submitting a transfer vehicle transaction I would say which vehicle is being transferred, who it's being transferred to and from and maybe the fee associated with that and those the transaction inputs are all modeled in the composer modeling file and we've built a modeling language that allows you to define that business centric and custom modeling language. The second part of a business network definition are transaction processor functions and those are written in standard JavaScript the way for our users to implement their business logic. When someone uses the composer client APIs to submit a transaction they provide the inputs to the transaction that have been modeled in a modeling file and in the JavaScript code that they've provided to implement the business logic executed on the blockchain. The third part of a business network definition are access control lists and we can define or rather the users can define which participants have access to which resources so you can say that the owner of a vehicle has access to the vehicle. The regulators have read only access to all vehicles in the business network and we enforce that access control automatically at runtime. The business network definition was the name and a version. Sorry go on. Yeah I was just going to ask you exactly what you meant by access is that visibility of the data is that ability to change the data? Both. Okay and then so the security properties are I guess abstracted over whatever would be intrinsic within the fabric controls? That's correct yeah we built our own access control layer around the fabric controls. Interesting thank you. Other questions for Simon? What are the this is Vipin by the way what are the you know will there be inefficiencies introduced with this meaning you know does the speed or scalability or any of those properties get affected negatively by interposing this business network on top of the fabric? Interesting question. We haven't done much performance analysis at the moment but I would say that when we've looked at chain code in the past the bulk of it is made up of really boilerplate load and so you've got boilerplate code for error handling access control data validation RPC between clients and the actual chain code and that's all stuff that composer takes care of automatically so you don't have to write that code we can work to make that code as efficient as possible and let users focus on their business logic and so for the simplest use case where you just want to do basic key value stuff within the chain code yeah composer probably doesn't help you but it's really going to help any sort of substantial chain code development by reducing the amount of code users have to write and I think the performance trade-off from them writing it versus us writing it it's going to be insignificant or not significant Simon hi this is Lenny good morning there's a composer provide functionality and to identify membership and to ensure that there is a layer of security over the members who are sort of interacting and generating transactions via composer I just want to understand if it's a modified solution as a high-fledged blockchain as a high-fledged blockchain solution or is it more for modeling and rendering so that users can understand the functionality behind blockchain and determine what might be the best set of actions to put together a production solution I'm just trying to understand and how will it be used if you say what's the other one corner and say so so the start of the question was around do we do access control and do we identify participants submitting transactions to the business network yes okay so yes we do we use fabric certificates and we can identify who is submitting transactions from the fabric certificates we map fabric certificates to participants that have been modeled and stored in the world state for the record of who you are is stored in a participant registry and we issue identity in this case is a fabric certificate we perform access control based on the participant rather than the fabric certificates we just use the fabric certificate to identify which participant you are and then we use the participant to perform access control over what which assets and and data you can read write and update so it's a modified solution overall the generation of the blockchain using composer provides a modified solution in comparison to say fabric or quarter in terms of maybe I just want to ensure that what could replace quarter say with the composer because they would provide the same types of functionality they yeah composer is a framework to accelerate the development of applications on the fabric okay so okay that describes any other question so coming background to the multi-platform aspect I don't have a particular bias about whether it it should strive for multiple platforms I would just like to understand what the what the intent is and that I think something a tool like this it kind of stands as a separate kind of capability that's not reflected elsewhere in in hyperledger to begin with so probably have some more discussion about this multi-platform aspect for project hierarchy later but I would maybe help inform that discussion too and to say what the intent is so we've designed composer to be platform independent and we started off doing that because we wanted to run it in several places not just fabric for instance we can run the composer runtime in a web browser to enable a web-based playground experience which doesn't require you having to set up a fabric instance to just get started and try it out and we can also do the same for standalone Node.js applications to allow things like automated unit testing with JavaScript test frameworks we're certainly happy to work with the community to pull this to the other platforms if there is interest do you think that the concepts like the interaction with chain code would be unique to fabric not sure the the interactions between the client and the fabric are very basic they simply invoke chain code with a list of string arguments which then get passed to our composer runtime running inside the chain code I would hope that's not too different from the other the other platforms let me try that a different way is is the intent to it would with the chain code be kind of the pivot point that any blockchain system that supported chain code that would be your target or is your target really more that you want to do composability for any blockchain irrespective of whether or not it supports chain code so our intent is to keep as much code as possible in our common JavaScript runtime and anything that can host that JavaScript runtime is able to use composer okay and then this is maybe a little bit too low-level but I'll ask anyway as far as those access controls the the data I assume has to be encrypted or something when it's deployed out to the blockchain and then there's some sort of key management through composer that would then provide that access not yet so we don't currently do any or help users do any encryption of data that's stored into the blockchain and that's something we're planning on working on soon we know we need to get there okay but that would be one of the mechanisms to enforce the the access controls I could be yeah Simon just my benefit is composing the integration within my pleasure already or if it's a proposal to to be intimated within the source this is a proposal to integrate it okay yeah it could be helpful I think because it has some unique and very remarkable features I think it's something that I'd like to see a demo of some so there's a call at 4 o'clock which will be an introduction to composer call sorry it couldn't be before the TSC meeting okay so how does the TSC want to proceed with this so other questions hearing none Todd I think we should put it to a vote Dan have you got all your yes thank you no unless I had a question okay go ahead Ram sorry I was talking to a doubly muted phone earlier so my mental model is that composer can plug in as a smart contract component if you think from an architectural perspective and so it is trying to implement the abstract smart contract and asset participant and smart contract modeling and execution environment so is there a well documented interface between the smart contract layer and the rest of fabric and you know is that a simple thing to extend that to the other projects can you talk a little bit about that interface yeah so as I mentioned we have common JavaScript runtime code and that runtime code a runtime container that runtime container is platform-specific so we have a fabric implementation of the runtime container and all that's it all that does is map our composer calls to put assets and registries and get assets out of registries to interactions with fabrics key value store so if we wanted to port composer to other platforms we simply need a new implementation of the runtime container what whilst it's not particularly well documented or described in our documentation the interface is pretty simple and so the the the actual transaction semantics is that tightly coupled to the fabric kind of model or just trying to understand how portable it would be or how much work it would take to kind of abstract this as a common smart contract module that can be leveraged across platforms so I think the abstraction layer that we built around assets participants and transactions is not fabric-specific at all and so I think as long as we could port the code to work on the other platforms it would be fine we wouldn't need to change the the abstraction layer so Simon could you explain the rationale behind the name fabric composer why is it being called because we have projects like Hyperledger Fabric and just trying to understand if there is some relationship of similarity so naming is a is a great question and so all the work we've done today has been called as being built on top of fabric which is why we initially gone with the name fabric composer we have gone through several other iterations of names as well thank you there was a names would be happy to do that yeah I think Simon I think you know Brian certainly I think made a point that you know maybe it should be called composers simply because it I mean especially in light of the description you gave for how I could have you know a binding to sawtooth or porta or whatever and so maybe just for you know to leave that option wide open and again encourage others to come and potentially build adapters and you know on time components for their respective DLP platforms that we just sort of name it composer yeah I think I think it depends on the project teams intense you know I don't want to have artificially encouraged people to look for kind of platform independent positioning if that's not really what the intent of the project team is so if the intent is really just to support fabric through the mechanisms that fabric has I was trying to kind of catch up on the reading in the chat log there it sounds like it's it might be a little bit more bound to the fabric architecture than I was understanding from the verbal description but I guess respective of what the state is today versus what it could be tomorrow I think it just kind of comes down to whatever the project teams intent is well so again I think I would have to characterize it this way Dan I think architecturally and you know Simon or if Dan is on you know incorrectly if I'm wrong but I think architecturally there really isn't tight binding if you will other than the fact that the you know the runtime you know the chain code that they wrote and you know that that you deploy that runs the JavaScript aspect of the composer model is platform specific and some of the concepts that we use our platform I mean well I don't know if they're platform specific but you know that the bindings to those concepts are certainly platform specific doesn't preclude that in something like Sawtooth that this couldn't map to a transaction family and that you could have a transaction family container if you will that could execute the JavaScript model yeah it was the the ACL linkage to the the fabric mechanisms that I was referring to but but I agree and understand that the state today doesn't necessarily reflect what the state could be tomorrow what I would just like to suggest is that the project team right go ahead I just wanted to follow up by saying that I think that you know if there were to be you know a mapping to Sawtooth that I would kind of expect that the Sawtooth community would be in you know the ones that are you know sort of helping to drive the bus in terms of the implementation you know you have an itch and you scratch it right if you have an interest in doing something then you roll your sleeves up and you and you start doing it so I mean I think that I think that it's fair to say that the initial intent of what we were doing when we were building fabric composer was to have something that worked with fabric but we also architected it in such a way that it wouldn't necessarily preclude integration with other DLT platforms and but you know again I think it'll it'll it'll depend as we go down the road whether or not you know any of the team that's working on fabric composer gets to be in their bond to you know map it to Sawtooth or Ohaha or Corda or Ethereum or what have you right yeah yeah no I totally agree that as far as getting any sort of integration and you have contributors that are willing to do that and there's no there's no interest in in my part anyway for the TSC to try to mandate that on a team it's more just if the intent of the project is to be platform independent then go ahead and reflect it that way and if the intent is to be fabric specific for now and then address some sort of platform independence when it does become a demand then I think that's has equal parents right and he's so on do you have any thoughts on that sorry so I think certainly the latter we're not planning on looking at adding in compatibility anytime soon if the demand is there and the community wants to help build that then great we're more than happy to help help out there alright then I suggest maybe just let's call it composer and then that way we don't have to worry about it don't throw up with any confusion how about high let's just say that the intent was to focus on fabric and to leave it that way I'm sorry Dan you were there was two people talking at the same time I couldn't hear yeah sorry what I understood Simon to just say was in suggesting the latter that it was the the intent was to focus on fabric for now and to leave it that way it is that's right but again leaving the door wide open for other collaborations I think that naming it fabric composer sort of closes that door that that's all I'm saying I don't know if it closes the door so much as it makes it it almost seems like there's a you know keep outside the door that's all sure sure so I very much hear your your viewpoint that you would like that to be open I think that you're reflecting a project team with you there I was proposing calling it a hyperledge composer because it looks like it provides some very interesting capabilities at a very useful within hyperledge in terms of the entire family of hyperledge projects all hyperledge projects would kind of implicitly have hyperledger on the front of them that's right but if we want to call it hyperledger hyperledger composer that could be fun too okay so Todd reminds me that we still don't have corn we have seven of eight so we're gonna have to take this to the mailing list and Todd will you send a note with the other well there for a vote on on composer and and maybe Simon you could just sort of you know drop in a note that I think we can call it whatever the team ends up wanting to call it and we'll just move to that okay so next up is the discussion on the subprojects which is sort of relevant here you know the top level versus subproject discussion and I put a link in earlier if you scroll up in the chat there was a link to the email thread that Dan started and then I piled on and then and I think hearts note is the one that sort of captured what I think a lot of people resonated with and you see if I can pull that note up here it's hearts that's hearts note and heart do you want to maybe describe the sort of the proposal that refined the what the you know what I was was sort of suggesting sure I just thought it would be useful in proposals to have project dependency designations and that would kind of solve all of this issue you know kind of it's clear all of the SDKs are dependent on you know sort of the the projects or whatever the main blockchain platforms they're working with and there should probably be some accountability that the SDK groups are responsible for you know going back and and working with kind of the top level projects and so I just thought a way to gracefully handle this this debate over what should be a project or not was just to have people list their dependencies in their project proposal this would allow kind of projects to proliferate and that's probably a good thing because people like ownership and it might encourage people to do more but what it would also kind of keep some accountability and sort of a chain of command in place that that's essentially a summary of what I said and probably too many words in that email now I thought it was just right I and I as I noted in the thread I think this is a really good way of addressing it and so when you you know when you create a proposal then you list the dependency on sawtooth or Roja or fabric or Cello or what have you then I think the expectation would be that you know before you bring it to the TSC that you run it up the flight pole with the maintainers of that dependent project and and then the proposal sort of acknowledges that that group was comfortable with the proposal and and then that would I think address mixed concerns of always not on it would address mixed concerns that there are proposals for or there have been proposals such as the proposal for the go SDK that we couldn't really decide at the TSC or some of the members of the TSC I should say where you know this sort of felt that they didn't really have sufficient context to do a an effective evaluation and technical merits of the proposal and and so felt uncomfortable making a decision based on a lack of context but if the you know if the project proposal has been run by the fabric maintainers previously and the fabric maintainers were all good with it then then obviously that would assuage the concerns on the part of someone like Nick who didn't have the same context so I think you know I think that what we could do is we could change the the template to indicate whether there's a dependency and and then provide some mechanism within the proposal template for the for the dependent projects to sort of sign off if you will so Chris this is our know I am sorry I was absent for a few minutes because as I was eating and mute button my whole system crashed and so she's both frustrating it's frustrating normally but just when you want to intervene it's even worse but so I don't exactly know what happened I we you know you guys were just talking about this question for composer as to whether you know what the intent really is and I was going to say well I think this this brings us into this bigger discussion of the you know how the different projects that we are being proposed relate to one another and so one thing I wanted to say with regard to our point I think it's a good idea to list the dependencies but what I wonder is should we also list the potential dependencies or what you could say the applicability of the technology and I'm a bit I think there's a big question that's TSC we need to consider is you know we are one of our responsibility is to kind of set the direction for the project as a whole and I I hear Dan and make they've been saying well you know I don't mean to push people into trying to be more like platform independent if they don't intend to and I understand that at the same time I think there is value in encouraging convergence and this will only happen if we do recognize when a component could actually be you know even though because of history like in the case of composer they started with fabric so it seems like well you could consider this to be a dependent project from fabric but maybe we'd be missing the opportunity to recognize the applicability is actually broader than that and there is value in recognizing this and encouraging you know the porting composer to other platforms and of course at the end of the day it's an open source project if nobody is willing to put you know to do the work it's not going to happen but from a TSC point of view I think we need to not fall into this this kind of like you know the risk of saying well it's not nobody wants to do it therefore it's dependent on fabric this is a fabric sub-project kind of thing and we would be missing the opportunity to to lead towards some convergence moving forward which I think is desirable I don't know yeah I just wouldn't want to to have people feel like they had to pay lip service to being platform independent that really wasn't their goal I think I understand that that's sorry I've only I've only been partially paying attention so I'm sorry I'm about to say something that's already been said but is there not just an easy assuming I've understood the problem on this is they're not an easy way to go through this simply by saying if the project currently works only with one code base and was built by people associated with that code base then it just seems obviously and naturally the case that it should live live under that umbrella and as it develops functionality either because people are contributed to it or there's been some refactoring whatever it is if it weren't it also works as a code basis and it's just emerged obviously and naturally from its from its behavior that it shows that it actually is now covering more than one code base it's an easy matter at that point to graduate it to top level in the same way as you know quite often you see projects spinning out of other projects when they take on an independent life of their own so it's case of I guess so rather looking at the intent look at the actuality but be completely willing and open to to to revise its classification when when the facts on the ground change things can be quite pragmatic in support of Richard and also to answer our most question I think hard already provides for this expansion by saying that the list of dependents could be expanded on the fly meaning like when the reality happens that they support both composer and I mean both let's say fabric and sort of Lake and Eroha then you can you can expand that list so that is already sort of in our proposal if you read it carefully and I suppose we should also mention it and change the template document to reflect this if everybody's in agreement I agree with it but my concern is that what we're talking about what I mean this mechanism of extending the dependencies as the project increases in scope I can see that but this is reactive right it's basically documenting what's going on what I'm trying to say is maybe we still need to have a way to express a desire in the direction the project should be taking or could take at least so in the case of fabric composer if we said well here the dependencies today depends on fabric I think that's a fact we could just say that at the same time we could say but you know it could also it's not completely bound to fabric forever but you know inherently it could actually apply to other frameworks and I think there's value in recognizing this and so maybe this like two least it's least the dependencies and the potential applicability or least of other dependencies potential dependencies I don't know you want to call it I don't think there's dependency when it's not there yet so that's why I don't think the word dependency yeah but it's more like applicability right yeah sure yeah sorry I agree that maybe the the section should be changed to include that possibility meaning what is the intention which is what Dan was asking earlier to write this is more like an intention signaling the future in some way so well but it doesn't have to be a commitment either yeah no but that's a very good proposal because we if I can say this is better this is a very good proposal because it could allow us to express and explore future relationships or dependencies or integrations and that's the whole thing everything is going to change and we have to manage change so that's one way of allowing change okay so again I think you know that the way that Dan that heart rather described it in his note actually does provide for the expansion as we discussed I do not think that it's necessary that you go in and get a mother may I from everybody that might possibly ever want to use particular thing if there's intent to collaborate immediately with that other project yes but if the intent is not there necessarily and somebody else comes along later then I think it's just like a charter revision you just expand your dependencies by you know collaborating with that project and adding the dependency I don't I don't I think we're maybe overthinking this is really what I'm getting I do like the dependency thing because that basically clearly connotes that this is related to that and that for purposes of bringing a proposal to the TSC if there is such a relationship then that needs to be expected you know explicitly made and and and then again I think that the the dependent project the parent if you will needs to basically have their maintainers sign off and agree that this is commensurate this is consistent with what we're trying to achieve so what I suggest for this is that I work on a tweak to the for the hyper ledger incubator proposal template and and then we'll look at that over email and then take a vote next week on the change thank you vipin I'll shoot you a draft and we can collaborate on that and then Simon I would suggest that you know you know this this is going to go out for a vote I would suggest you just sort of maybe get with Dan and Catherine and and and your friends at Ox chain and figure out what name you want to go with and obviously put fabric as a dependency since there's that and what I can you know we can do is we can get the fabric maintainers I think we've mostly seen this to to weigh in okay so Chris there was a related question though that I'm not sure what the answer is so if you if I could it's just because so I think there's no disagreement in listing dependencies there seems to be a good idea and we're all going for this the question that I'm not sure about is what is the decision process are we saying well if this is kind of like dependent on a top-level project and there is no intent to make it something more than that it doesn't come to the TSE or does it still come to the TSE if it wants to be a top-level project yeah if they want to have your own so if it's not if it's not if the intent is not to be a top-level project then it doesn't have to come to the TSE at all what's the process so for instance if you wanted to add a new feature to sawtooth that turn transaction families upside down or something that I mean so like the you know I see like Dan was talking about the SDKs I mean some of this I think I've come to the TSE they were a big chunk of code that were brought by sometimes teams that are not completely related to the core team of the project and they were brought to the TSE as new projects and what I'm saying is you know is the proposal that if something depends on the top-level existing top-level project then doesn't have to come to the TSE because you know so again I think that and heart correct me it's if I'm wrong about this but I think what yours you know what you were advocating for and I think also what I was advocating for is that look there are there are times when you really want to be a top-level project you want to have your own incubation you want your own set of maintainers you want you know the certain amount of independence but yet by the same token you have a technical dependency you know from an interface perspective on another project such as sawtooth or fabric or what have you one of the others and so therefore it is a top-level project it comes before the TSE however from a technical evaluation perspective as to the merits of the proposal vis-a-vis its dependencies that you really wanted to make sure that those dependent projects are basically also signing off saying yeah this makes sense okay so Chris this is very interesting the way you put it is that the actual process is that the process plus our project approval process that you just explained there if that is it has to be documented so it's clear to everyone because with process we have to simplify and therefore we need to ensure that everything that's been discussed there is covered because we can handle we can know about how we can determine whether this project gets approved as a parent or high-level project in a sawtooth or remains a sub-legit level project so we need to have this process and what you just said the constitutes a lot of that process so we need to define it and document it so that one understands Leonard I think it is defined already I don't think we need to change the definition I do think we need to have the dependencies but the process for proposing the project has been there since the very beginning where we had the project lifecycle that describes exactly how you go about doing that is good so if it now encapsulates everything we've discussed today it doesn't change and that's what you say so we'll add well it doesn't need some amendments based on the dependencies so we'll get that done and then we need to gather as a team to make sure that it satisfies all so I think that's great okay all right so we're two minutes over we got a couple of male things how much never joined so we're we didn't we didn't get to the GSL obviously but I think so so the other thing and for I apologize guys I messed this up I forgot that you have a change of the daylight saving and all earlier you just joined them we had all this time where we expected you to be talking it's really a shame but I missed a mister you have two weeks of difference in the daylight saving change and I missed it we were in constant a completely different discussion anyway that's right and no worries because we understand next time Thomas is on top yeah that's right so what was that what I was gonna say is so I will work with zippin on the template changes and any necessary other changes that we want to tweak into the lifecycle and then I will also sort of go back to the security team with the go SDK proposal and have them you know make that change and we'll get the you know the fabric maintainers to review it and so forth and then we'll bring it back hopefully next week along with along with it with the composer so again thanks everyone apologies for running a little bit over and we'll talk to you all next week