 Brian? All yours. Thank you. All right, welcome to another exciting edition of the Hyperledger Technical Steering Committee. Following the Hyperemergency Powers to Active Hyperledger, I am stepping in as the vice chair today, because our know is unavailable. This is Dan Middleton. And so for agenda today, we've got an announcement or two. And then we're going to have a discussion about some Ethereum-related topics, which should be interesting, including a proposal from Sean Young. And then time remaining, we can get a discussion started, at least, on some of the long-term agenda that we want to do for the rest of this incarnation of the TSC. There's also a quarter of the reports. I don't know if we will be discussing that in detail. I didn't see anything of anything that really might warrant a lot of discussion. So let's go ahead and jump into it then. I see Min is online. Min, would you like to talk about what you've got listed there for the mentorship? Sure. Thanks, Dan. Sorry, my voice is still a little bit strained, coming out of a cold. So yeah, just really quickly, I'm looking for 10 volunteers to review this year's mentorship project proposals. Originally, we're planning to close the project proposal submission this Friday, but thinking we have the Global Forum next week, it will be a great opportunity for the staff and the community to promote our mentorship program. So we're extending the deadline to Sunday next week, so March the 8th. Regardless, we need to form a subcommittee to review the project proposals. We have funding for 18 projects this year. So far, we've received 12. So I'm anticipating that we'll receive probably more than 18. So primarily, the subcommittee will be reviewing the proposals that we receive, making sure these are quality projects. They're clearly scoped, suitable for a mentee to work on. And also, it's advancing hyperledger technologies. So I posted the link to the review process and criteria in the announcement section. So I already received, I know, Angelo, you already said that you would love to participate. So I'm looking for eight or nine more people. So just let me know by email. So I posted my email address there by March 5th to participate in the subcommittee. Any questions? Just to give you a context, last year, we funded 17 projects. We received 27 proposals. So the committee went through the 27 proposals, had to eliminate, not eliminate, but select the top 17 out of the 27 proposals that we received to fund. So this year, anticipating, we'll probably receive a similar number of proposals. So we'll need to have the committee go through the proposals. It should be pretty lightweight, because the proposals are, it's a templated format. Just take a look at the proposal details and select the 18 that we think are worthwhile to fund. OK, thanks, Min. So if anybody has any questions about that later, you can see Min's email on there, and you can reach out to her as well. Thanks. So a related announcements that did not get added to the page yet, but maybe I can do that after the fact, is we have a mentor session next week at Global Forum, and we're still looking for mentors to attend that. So as the Global Forum kicks off on Tuesday morning, we've got interested, I guess, new contributors or mentees signed up to get a little bit of coaching from experienced people in the community. And so we're looking for some volunteers to help do that mentoring. And we can get a link put on to the agenda later for that. So we'll have that to reference. But we are about four or five heads short of what we need to make that a successful session. So we're looking for help with that. Brian, with Global Forum starting next week, is there anything else that we'd like to interject at this point? No, just that there's a lot of great content. There's 124 something like that speakers across 85 different sessions. And I don't know if anyone hasn't still on the bubble about coming, please do if you can. But yeah, we're all geared up and excited about it. So yeah, nothing else I can think of to mention other than that it's looking good. OK, great. Well, look forward to seeing a lot of you in Arizona next week. I know for where I live, that'll be a nice change in weather for me, maybe for some of you as well. All right, I see Bob is on the line. Mr. Summerwell, would you like to take us into the wonderful world of ethereum flavored wasm and some of the impacts that that implies for the ethereum community and maybe how that might help us grow things within a hyper ledger? Hello, yes, I absolutely can. So hi for anyone who doesn't know me. My name is Bob Summerwell. I am currently the executive director of the Ethereum Classic Cooperative but I've been part of the Ethereum, the broader Ethereum ecosystem for five years now, heavily involved with the start of the Enterprise Ethereum Alliance and have been a hyper ledger fan and supporter for many years. So the situation that you really have on Ethereum is I mean, the core of Ethereum is the Ethereum virtual machine. You know, this this concept of a a gas limited general virtual machine. Solidity is by far the most popular of the smart contract languages targeting the EVM, but you have historically had other languages as well. Viper is is about the the second most popular language. Now a Python based alternative where web assembly and specifically you wasm come in is that there has been this effort over the past goodness, perhaps three, three or more years now looking at the option of replacing the Ethereum virtual machine with an augmented web assembly really based on the observation that at the time the Ethereum project started. There wasn't a good off the shelf alternative which which met the sort of deterministic VM needs that the project was looking for. Web assembly started shortly afterwards and the observation was that if you augmented the code generation for web assembly with sort of wrapping quite equivalent really to exception handling for adding the gas counting that you could that you could target web assembly for execution of smart contracts and that relying on the the work of of Microsoft and Google and Mozilla and so on might have higher quality than things that we could do ourselves. So anyway, there's been a single primary compiler for for Solidity through all that time, the Salty compiler, which is maintained by the Ethereum Foundation. But what we have going on, both with Solang, but also with another project called Sol S-O-L-L is we're seeing the beginnings of alternate Solidity compilers initially, but that those toolings can really become part of richer compiler sets all really built around LLVM. So for anyone who doesn't know LLVM is is is the basis of a large chunk of compiler technology in the world right now. The whole of the objective C ecosystem clang C++ compiler, the primary Rust compiler, the Swift compiler, all of those are built around LLVM. And I think really maybe the analogy here is that Sol C you could think of that as sort of like being GCC era. You know that you're in the 1980s and GCC is your only option. You really don't have a lot of rich tooling. You're doing sort of print fd bugging and errors are our core dumps. That was sort of the era that we were coming from. What you really see with these with these newer approaches is things equivalent to the appearance of of clang and LLVM. So anyway, I've been brokering dialogue over the last several months here between groups within this emergent paradigm. So you have Sol, which is a solid compiler written in C++ LLVM, which comes with an E-Wazm back end. But there is an optional EVM back end there, which is maintained by each C core, which has just recently come to an alpha state. So what they have on that code base is they have ERC-20 token sort of compilation where the generated bytecode is live on the Ethereum and ETC mainnet. So you have a sort of an alpha. Actually, that was last October that was it's further on to alpha now. So you really have a state where force for constrained set of use cases. You have a viable alternate compiler there, which can be used live on Ethereum or ETC, or for an E-Wazm back end targeting Ethereum too. Also on Sean's side, you have Solang, a similar kind of approach, but using a Rust implementation with LLVM with a Wazm back end. They're targeting different flavors of Wazm, originally aimed at Hyperledger Borrow, but also now supporting Substrate from Parity Technologies and supporting Saber, which is the Wazm back end for Borrow and also supporting E-Wazm from Ethereum too. What you have with the LLVM EVM back end, which Alan Lee at ETC Core Labs have been supporting is what you've really got there is an alternate code generation back end for LLVM, targeting EVM in the same way as you would do it in the same way as you would target X86 or ARM or Wazm or MIPS or whatever you have. The intention there is to actually ultimately get that work upstreamed into proper LLVM so that you have official support for LLVM as a first class back end. That's the long-term intention for that. I guess the long and short of it is there's a goodly number of projects happening here and I've gathered those together as well into a Telegram group where we have representation from each of these different teams, also from the Viper team, from Consensus Diligence, one of whom is the factor maintainer of the Solidity Grammar, Roodstock trailer bits and so on. There's lots of stuff going on. That's the long and short of it. Great. Thanks for that background, Bob. Could you say a little bit more about the timelines involved if there's any sort of consensus on the adoption of bytecode into any of the flavors of theorem, kind of the time horizon that you see that happening? Adoption of which, sorry? Of WebAssembly bytecode. Well, so the thing to say about WebAssembly on the Ethereum side is that that is an Ethereum 2 feature. Now, when and how Ethereum 2 is actually going to happen is a matter of constant debate. It seems to be perennially on an 18-months-away time line, the beacon chain, which is phase one of the Ethereum 2 deployment, is slated for later this year. But beyond that initial beacon chain phase, you have phases in which shards are added as phase one and then phase two is the inclusion of execution environments, E-wasm being one of those. So the timeline for E-wasm within Ethereum is probably 18 months or so away. Okay. Thanks. But just the thing which can definitely happen and will happen earlier is if you have an EVM backend to one of these new toolings, you have an alternate solidity compiler which can be used with Ethereum 1 or ETC. And to me, that's one of the most exciting elements because it really gets us beyond having a sort of a single compiler as the monopoly on that language. There isn't a proper governance around how the Ethereum language is defined and updated and so on. So that's sort of a missing piece which I think can happen ahead of anything on the E-wasm line. Bob, just a quick question. What is the delta between E-wasm and standard wasm right now and what is the likelihood that E-wasm support will actually get upstreamed into LLVM? That E-wasm support be upstreamed? Yes, isn't that what you said earlier? No, what I said earlier was EVM. Oh, got it. Okay. Sorry. So what's the difference between wasm and E-wasm then? It's insertion of gas counting. So the key feature that you have within the Ethereum virtual machine is this gas mechanism where particular opcodes have costs and gas is the limitation on computation. So within smart contracts, you only have a pseudo-choring completeness because of the halting problem. You don't want smart contracts that can go into infinite loops or so on because they're denial-of-service vectors. So the denial-of-service attack factor. So what you have with the gas counting is essentially, you're on the clock for your opcodes and if you run out of gas, then the thing is aborted. So then that's the difference that you have between WebAssembly and E-wasm is when you're doing the code generation for an E-wasm execution, it's going to be inserting these gas counting elements around the blocks, which really are quite analogous to something like exception handling. You know, that you're adding this kind of commit rollback block handling. So this doesn't require a rewrite or anything of the back-end support, right? This is just calling extern. Yes, let me interject here. Gas cost is counted by the virtual machine. LLVM does not insert gas counting instructions. There's no special support needed in LLVM. The gas count is done by the virtual machine. If it was done in LLVM instructions, it would be very easy to cheat. Yeah. And that was sort of my second question was, I know we've been in the work we're doing with wasm right now. We're providing a bunch of optimized native code routines. We're not using wasi, but for the interfaces, but that's largely because of the people who are writing that, the wasm support for us. Are there stock packages that are going along with the wasm EVM for native acceleration of operations? And are those being provided? Intems? Like certain cryptographic routines, right? I don't really want to run those. Yes, I can compile my JSON parser and my crypto routines as wasm byte code, but it's horribly slow. So in most cases, we're providing native functions that can be invoked for accelerated access to crypto routines. Is there a stock package that goes along with the solidity wasm EVM support here? So in wasm, there are a set of functions available to the environment, like get block hash, contract store, but none of that. There are no crypto functions. So the crypto functions will have to be implemented as the wasm byte code. Yes, exactly. So this is what I've been doing in Solang. I have some C code. It gets compiled. Okay. Yeah. Thank you. I mean, that doesn't stop. So one of the nice things about starting to work with wasm and take, for me, close examples, obviously, but we have a set of, we call them natives. And it's entirely possible to support the core set of wasm, ewasm, externs, and add your own. So like the EVM has actually kind of weirdly, it has two concepts. It has pre-compiles that include a few cryptographic functions. For example, there's some elliptic curve stuff that got added more recently. And it also has op codes for things like SHA, which really ought to have been pre-compiles. But you can do something entirely analogous to pre-compiles and wasm. And I guess part of the purpose of bringing something like Solang into Hyperledia or to work with other compilers is to try and standardize what the CIS calls effectively that you have available to you. So you definitely want to do what you're describing. The natives package, having a standard stock natives package would be an incredibly helpful thing for many projects that way. Thanks. One thing to do point out, though, is that ewasm has neonated performance. So doing crypto in ewasm isn't as bad as it would be in EVM. Are you assuming jitted code on the back end on the interpretation? Or are you just suggesting that the bytecode really is that efficient? Well, the bytecode is really that efficient. The question is, of course, how the gas costs for the op codes relate. Okay. What about side channel attack resistance? Yeah, that's an interesting question. Yeah. It feels to me like probably, I mean, like for that and other reasons that it would make sense to have some set of natives available for some of the, you know, to get some core constant time crypto stuff. Okay. So I think that's probably a good switching point here so we can go step into Sean's proposal itself and we can continue some of this dialogue within the context of that proposal. Sean, would you like to display that yourself or would you like us to just bring that up from the link there? Oh, maybe the project proposal would be, yes, great. Thank you. Okay, so I've written down a few notes. Oh, and thanks again, Bob, for bringing some context to that. Yes, thank you, Bob. Okay. So the background, I'll try to cut out all the bits that Bob covered. So the SoulSea compiler isn't particularly open to contributions. I've tried in the past and failed. It's a very large C++ code base which has a handwritten parser and a compiler backend. And the compiler backend includes optimizing compiler parses. So writing a backend compiler is a very hard thing to do. A good compiler backend is one of those greats feats of engineering and PhDs and papers are still being written on that subject. So SoulSea targets EVM. E-wasm is work in progress. Because they have to write a new backend, this is taking time. And I assume once the SoulSea E-wasm backend works. Sure. It might be useful to people if you could just explain how front-ends and back-ends work with LLVM for some who might not be familiar with it. Okay, right. Okay, so the front of the compiler parses the source code, does a resolution of all the symbols. And then generates an intermediate language. The intermediate language is then read by the backend and the backend generates the code for that particular target. So be it x86, WebAssembly, EVM, one of those. So Solang and Soul are both front-end compilers. They do the parsing and resolution of Solidity and then generates LLVM IR. So that's an intermediate language between the front-end and the backend of the compiler. So Solang uses LLVM for code gen, has a generated parser. It's written in Rust, so it uses modern tooling. For Solidity language support will be ready in fall. It's funded through a web-free foundation grant. And that grant means that there's a particular roadmap which has to be met in order to receive the grant. Hence language support will be ready in fall. Else the grant won't, that's needed for the grant. So Solang runs a moment command line. It compiles source codes to optimize WebAssembly and generates the ABI files. WebAssembly is, as discussed in the standard, there are ledger-specific interfaces for contract storage, access and call data, block hash, etc. So depending on which target Solidity Solang is compiling for, there might be different language features available which just depend on what the underlying ledger supports. So that's the short-term, the long-term. What Solang would want to be is like a Solidity toolkit. We need various things to have a great developer experience. So we need a language server so that in an ID you get syntax highlighting. You can hover over symbols and it will tell you what they are. This needs to sort of parse and resolve as you type a playground on a debugger like remix. It needs to be implemented. We might need a sort of clippy style hints system or linter which will tell you that calculating length of a list and then comparing to zero is inefficient and is empty or so might be more efficient. We might want to do static analysis. So in static analysis, you need a different IR. You need to know variable lifetimes. Back references to symbols. So for these things, there needs to be a common access to Solidity representations. Earlier was a discussion about YOL versus LLVM IR. That's useful for front-end and back-end compilers but not useful for many other things we want to do. So a language server has no useful YOL or LLVM IR representation because much of the symbol information is already lost. Solang wants to be a set of libraries and tools to access symbol information and IR information of Solidity. So then with those tools in place, libraries in place, we can implement all those tools I just discussed. Lastly, I wanted to say that whilst implementing Solang, using Rust has been actually very good. So in Rust, you have enums and you can use match and iterate. So you can actually access a specific representation of the IR very easily in a single line of code. Solang is very expressive and this really helps for writing this type of code. Yes, I think that's it. Any questions? So let's say we've got several projects that are interested in using WebAssembly for different things. For them to benefit in some way from this project, would they also need to have a primary interest in Solidity? I guess a different way to say this is if you're not using Solidity, are there benefits that this project still provides? It would be a if a project would want to have support for a different language. So say Viper or another language. There are many examples. There are many ideas about smart contract languages. What those languages should look like. So this would be a great example of how to implement a smart contract compiler. And much of it can be reused. So you need an ABI encoder, decoder. You need to deal with contract storage and abstracting that over different ledgers. So this would be a great example of how to implement a smart contract language and parts of it could be reused to implement that. I can also give an example here that kind of motivates a lot of my interest in Solang and some of the early discussions that sort of led to Sean getting started on this. So we have a very large Solidity code base that implements the business process engine and has a lot of hairy bits. What we'd really like to do is we've been a lot of value tied up in that code and it's not going away anytime soon, but sometimes for the basics that the EVM and Solidity are pretty bad at like string manipulation and other things that no one would ever want. It would be nice if we could use another language, whether that's a smart contract domain specific language or Rust or whatever. And we started thinking about, well, you know, wasm so we put we have the wasm which is partially experimental feature that's in Burrow now. What Solang would allow us to do would be to target our existing Solidity code to wasm and then within Burrow there's a mechanism for cross engine calls. Well, we wouldn't even need the cross engine calls there, but we could call in the idea would be that we could call into other wasm code that was compiled with the same system target in there. So the same syscalls so that we could start to incrementally introduce and mix rewrites of some of that Solidity code base and all have it coexist in a single wasm runtime. So that's how I was thinking of using this. Thanks, I think that helps illustrate a little bit more breadth there. Okay, other questions for Sean while we have him on the line here. So I think in previous meetings we have discussed the lack of maintain a diversity to become a project. Is that a sticking point here or are we going to review that at some point. I think we want to always be a little bit balanced between having a requirement that in order to become an active project you have that diversity and and seen at a stage here where where a project is proposed that there's a path to get there versus demonstrating that you started with it already. And there's probably also a bit of a modulation of of what we would expect to see for a proposal, if, if the scope of that proposal is a tool versus a platform or something like that. So, with that said, I'm getting an echo from someone. But with that said, I am wondering what kind of features or adjustments to the proposal might help draw in other stakeholders so that we do have a good healthy start at a multi vendor basis for for maintainers. Well, I think one question, which was going to be my follow up question would be, you know, I think the majority of the people on this call are from hyper ledger. How do we see adoption of this outside of hyper ledger. Do we expect anyone outside of hyper ledger would adopt this code and use it as well. Certainly wants to compete with with this entity compile itself. So, once soul see gets a weapon support. It has his own compiler backend and it does not use LLVM. And LLVM is a state of the art compiler backend, it will be very competitive. So there is a real chance here. And I suppose the dependency here is only has Bob pointed out the it's always 18 months away you could have that on a plaque. So, so there is a there is a hold up there, like this compiler would, you know, provided development can use well very likely to wipe the floor with the source compiler for Ethereum usage usage but that that's not really going to come on stream until the wasp sport is there. Bob mentions the the the EVM LLVM backend. I mean, that is still pretty early. So, I mean, reference the the RCT to the RC 20 contracts like they are not the most complicated facility target. It's good that they can be compiled but for general purpose. The facility compilation the author of that backend is saying that it's it's not yet competitive results. So, I don't know what the timeline on that basically that either you'd need a theorem, you know, greater interest in the theory me was and there are test nets you doing you was and stuff now. So that would drive some adoption, or as a kind of transition period if that back end could get good enough. And be integrated with some so long then then you can see some adoption there from outside of hyper leisure. Some of the future features that you've got listed there are maybe in the ID space or related to what you would see in an ID kind of tool. Have you, if you thought about overlap with with other tools like ganache I feel like maybe that was on the mail list somewhere. Oh, I missed that. I don't remember if it was or I just imagine that but anyway just general reaction to the idea that maybe there's another development partner out there in that space. Well, I did this for some of these tools that there's quite a good bit of code to be be written for others there's less work. Any cooperation any sort of integration with existing tooling can only help. I haven't given much for to be fair. It's something to mall in the coming days here. Yes. I mean beyond. Let me just switch my device. Bob we lost you if you were planning to pick that up we left it off. Hello sorry I'm back. Hello. We've got you go ahead. Yeah, beyond Solang within this larger group that I'm gathering with more general interest. We've got tools vendors we've got people looking at a formal verification of grammars. We've got multiple different languages. We've got teams really who are so for example that root stock. So you know root stock have got their Ethereum virtual machine on top of on top of the Bitcoin chain. And they've been making obviously heavy use of the VM as well. So I mean I think from my perspective, most of the interest I'm seeing is really about the EVM itself in that you've had this situation for Ethereum where the EVM has been kind of like under maintained and very unloved really since about 2017. Based on this eternal premise of the coming soon, you know, Ethereum to the wasm pairing. What I think I'm seeing the interest from a lot of this group are seeing that that having the option of alternate celebrity compilers really kind of busts open that monopoly. And it opens up the door for doing very basic incremental improvements in the EVM which have been held up for two or three years, you know, such as adding support for op codes for sub routines. Looking at static jumps. There's another adding SIMD instructions. Okay, chime in a bit on that. In all corridors which is the call that governs a lot of the mainnet stuff. One thing is probably becoming in Berlin is sub routines. There's still work going on and improving the EVM some of my EIPs that I've submitted our works to approve that. But the big problem, however, that may not stealing with that almost dominates all performance discussion is dealing with the size of the state tree that they have for the mainnet contracts. And that is, you know, just such an overwhelming thing that you know looking at optimizations doesn't matter if you're going to still spend 80% of your time reading your state from disk. And that's the reason why EVM improvements have really escaped the interest of the core developers is because it's, you know, by two words of magnitude state tree has been more of the problem. There's nothing that the that the virtual machine can do about the state tree problem. Nope. The reason that so long targets wasm rather than EVM is because wasm has much bigger, much bigger community, better tooling. You can compile standards see to to wasm and then link it. So if you want to implement your own crypto in wasm that's perfectly possible in EVM that would result in code which is highly inefficient because it's hard to access. It's a memory byte by byte, for example. So moving from wasm opposite offers a whole suite of new options which are not available with EVM. It would leapfrog a whole set of problems. So for hyperledger projects, they would use wasm and not EVM. Another perspective in terms of like, I don't know whether like I put this more strategically safe for hyperledger projects and why I think, or the ways in which I think that hyperledger projects ought to be thinking about making use of security. So projects of integrated borough so far kind of seen it as well. So it is this other option which if you're not interested in some sense in public Ethereum, so it is probably a slightly curious option. I mean it has some advantages around it's it's got the built in address world view if you want that and that makes sense. But what I think this gets interesting is if other hyperledger projects want to move in a direction where they have some kind of connectivity in this sort of layer to scaling sense with Ethereum, come and run your your side chain, your, you know, semi public side chain your scaling chain on fabrics or to throw her whatever. It's actually shouldn't just be thinking about city is a language option but providing state compatibility function level compatibility so that you can ship code, you know, maintain a kind of single logical code base that maybe you have some some some bank contract on main line Ethereum but you're running some dispute resolution stuff that is on a side chain you can escalate like it's it's actually being able to run that same city code. So you could be running that in a wasm environment on on other chains, but I think there's a kind of missing missing a trick really if you're if it doesn't move us in towards some kind of public Ethereum connectivity, not just a language option which is not that interesting in itself. I agree I think a set of common host functions that we could plug in this execution environment into any of the other DLTs would move the smart contract space immensely forward. That's what I think is most interesting about hyperledger moving into the wasm space is it gives us a great opportunity to standardize what that would look like across DLTs. Yes, I agree. I've been implementing targets and so long and there's this huge the different host functions look very different on the different ledgers and by combining those seeing all of those in one project it's possible to see that a common set is possible and will benefit everyone. If Solang gets a few more maintainers and gets some success, would you see it as like mission creep to support other languages using the same smart contract model? None at all. I hope and the way I've written it is that a large part can be reused. The first part of the stage would obviously have to be replaced but hopefully can be reused and make language a new language support easier. To my mind that's a key feature really of looking at LLVM as a base is that the whole framework is really built for suites of compiler tools. It's not necessarily a complete switchable back and front ends perfect pattern but you really have got a situation where having alternate languages while sharing many parts of the pipelines is a key factor you get out of this. I see solidity really as source of being like the sea, the source of stage. Here is an initial kind of like the facto standard language but it's not necessarily the safest or the best or what you're really going to want many people to be using longer term. I think DSLs are really going to be like ruling the roost down the line but having a mature framework that you've got these things on is certainly going to be the best basis for moving towards that world over time. Okay and I think we'll leave it there so we've got next week off for further discussion on this point but a lot of us will be face to face in Arizona so hopefully some more discussions can take place there. And then it'll be the following week that we return for a TSC meeting where we could resume this discussion and see if as we approach that date whether we put this back on for a vote at that stage or further discussion. Real quickly, Sean and Bob will either of you be at the Global Forum? Hi Sean, yes I will be there, I'm in Las Vegas now, so yes. So I sadly will not be there but somebody who will be there is Michael from Second State who are the developers of the SOL tool as well. So I'm really hoping that he and Sean can meet and also that Second State can talk about potential contribution of their code base into hyperledger as well. So I'm really thinking that labs can be a place where we can do collaboration across all of these tools. Cool, yeah, no I was wondering we could do like Birds of a Feather thing potentially. Yeah I was just going to flag that there is one on the books, I think Sean put it on or somebody did but yeah have a look on the Birds of Feather there's a wasm table so hopefully we can all meet up there. I created one on smart contract languages and wasm. Okay we've got two last topics on the agenda for today one is the transact update. I see there's one written piece of feedback there that can be addressed offline. There's any quick questions we could hit that or I know Mark's been hanging out here on the call if there was anything that you wanted to point out urgently Mark. And if not we can switch to the other topic. Yeah, I'm not in particular Dan I mean I think the report speaks for itself and I did see Mark's comment about about the working from our detailed members. There's a general comment for actually all projects, you know, when you say no change from last month or whatever then people have to actually go off and look and see where if you just, you know, cut and paste from last month or whatever last quarter then we have it. A lot of projects to review. Okay, so let's go ahead and jump into the long term agenda topic. As anticipated really have a few minutes to go through this but wanted to at least start some discussion, so that we've got a more more directed series of agendas for remainder of the session of the TSC. We asked the architecture group with with kind of little notice to help prime us for this. But make was able to generate some notes from their meeting yesterday. I don't know if people have had an opportunity to read that. But that is linked within this new topic. And that is a good read to have some difficult questions there that we should be pursuing. So I think, given the limited amount of time that we have today. One thing that we can still accomplish here is just kind of run through the TSC members and get some initial reaction to this direction of thoughts generally. Excuse me. So as the I'll break the fourth wall while you're taking a drink of water and I just want to say to the TSC I really appreciate that you're taking a look at all this stuff today. This is awesome. Thanks for that interlude for me. I think I still might lose my voice here. Hopefully get it back for next week. So yeah, so I guess to get through it for TSC members. If you've had some thought to think about what kind of questions that we could do with the initial goal being let's let's frame out the big pieces the direction that we want to explore and not so much worry about can we define that direction today. What other sorts of questions will we want to add to this list. I think one of the things based on mixed mail my interpretation of it is, we need a stronger, like architecture working group we seem to spin up these cross platform projects without really taking into account when we do, you know it's like here's our interface you can use it or walk away it's not, let's figure out how we can start this thing and have a common interface for everyone to use that fits into, you know, multiple platforms. My view, anyways, I don't know if others feel the same way, but that limits adoption so. Yeah, and I think that that also pulls out one of the one of the ideas that I wanted to get some reaction to is. Can we bring the scope that we had originally given in the architecture working group, can we bring some of that back into these TSC discussions. And is there interest in us doing that. I would at least point out that I'm not sure that there was much of an original original scope on that. It's always been sort of a descriptive group for the most part on it. Just to second Mark's comment is that the given the inertia in the existing projects that it's always cheaper and easier to take what you have even if it's just good enough. So without without some sense of strong encouragement from the TSC or some other organization adoption of sort of comma modules broadly across the projects is going to be extremely difficult. And that's just the pragmatics of we all do what we do and we know what we know. And it's hard to look at something that we don't know that somebody else is controlling and be dependent upon it. I think that's an important point make for thanks for highlighting that further make the how these projects are funded and how they're driven. And it's implications that are hard for us to work in a way that's orthogonal to that. Okay, so we are unfortunately down to the last minute here. So thanks for getting us started on on this and we can bring this up at our next TSC session and again, a lot of discussion opportunities next week. I mean, all of you that will be there and if you won't be there I'm sure there will be a lot of things being echoed back on mail lists and chat forums and look for any other sorts of interesting updates that we might percolate back out to the TSC on the following week. Thanks everyone. Thanks Dan.