 Head and get underway them This is the hyper ledger technical steering committee call Everybody is welcome to attend this call so long as you abide by the anti-trust policy and Take care to be respectful to the other contributors and you can find out more about that at our code of conduct Which is linked on the agenda and a number of other places Solano, would you like to take folks through the announcements? sure so um Again ongoing the CICD committee with Dave Fusie if you want to join please ping him about joining They're having regular meetings and it looks like making a fair amount of progress We We're also upgrading our search especially then so we're looking for volunteers for helping with the upgrade I think we're good with the fabric one because we're looking at upgrading fabric to the 1.41 rough protocol But we would like to get sawtooth updated. I just had a really good phone call with a mall this morning at 7 a.m. Central Time And he's going to also be recruiting some people for us to help with that So if you know anyone, please let us know also Dave has posted the rough draft of the readiness report I would like to encourage everyone to go ahead and read and comment Because it'll be on the agenda for next week not this week. We've got a pretty full thing for this week. So Let us know not. Yes. Oh, I wanted to jump in here and comment on this I wanted to Come clean that I've been struggling with writing this if you go to that document You'll notice that I have like three separate tracks or you know where I've attempted to it So if you scroll down So that's attempt number. Whoa, that's Yeah, okay, that's attempt number three, but if you scroll down There's take two Which was my previous attempts and then that if you keep scrolling down, there's there's take one which was my previous attempt so The reason I've tried three times at this document is because I I have a lot to Say about product readiness and project readiness and a lot of Ideas about how we can measure this and how we can formalize it but every time I start writing this I realize I'm repeating a lot of what's already in the wiki about project lifecycle and exit criteria and all that kind of stuff so my most recent try which is the top I I just focused on the things that we probably should do next which is Primarily we need to formalize the exit criteria from each of the stages and including like the first major release and Solana had a really good idea of developing basically like a questionnaire form like the way the CII badges done and Focusing on that so if we formalize sort of like the criteria so that teams so it becomes like a self-service thing on the wiki teams Can go through and fill out all their comments, you know as a proposal of like hey, you know, we're good on this level moving on but The thing I want to ask the TSC is You know having a little more direction on exactly what you want out of this would help me take all those three previous tries and pair it down into something that Is truly useful for all of us Okay, so that's important context so TSC members, please do take a directional look at that make sure that that some or all of that is What was being asked for if there's any reference that you can give to the original question that's on that go for to send that to the list Well, that was the thing it was it was just hey, we need to take a look at project readiness and develop You know, what does it mean to be ready? What are we already doing? What should we be doing? and so that includes a lot of things like how do we measure and What, you know, okay, we measure things what our good numbers You know what if we have a bunch of numbers what what would constitute good numbers and then You know definitions of all the product project readiness stuff So like take two I started writing like an essay on this, you know Like an encyclopedia post and then I realized I was repeating a lot of the stuff It's already on the wiki when I started trying to pull in all the other pages and so it was like well, this is dumb repeating myself So anyway, the the original question was What does it look like to be for a project to be ready? and You know, it was very vague So, um, yeah, if anybody has any ideas on exactly what we want out of this I'm all ears the third try I think is closest to what we want, which is Some light definitions, but then you know, here's what we are doing and here's what we need to be doing and Yeah, and feel free to edit and put notes in there and comments and just dump anything in there But it's important that we get this right, but you know, we have a lot of stuff on the wiki already around project readiness It's just not necessarily Called out directly with a head nod to you know, if you follow the stuff that's in this document We'll help make the project ready. Yeah The projects themselves asked for this and some of the incoming projects have asked for this and that they don't always Understand what the rules of the game are and they want to understand that better And especially when they're trying to get ready We noticed that a bunch of them are like well, we don't exactly understand how to get ready And so I'm like, well, there's this this this this this this to read and they're just like, okay We think we've got it, but oh, we've missed this or oh, this is not right and things of that nature So I'm like, okay, let's clarify it with some checklists and you know, possibly a form and let's also, you know Make sure that we're not missing anything because I do feel like having it scattered like that means that we do miss things so That's why I asked for this proposal is because I actually had many different Projects and even labs that want to get promoted to becoming projects They care about this because you know in the end everyone wants to become an active release And so they want to under have they want to have more clarity on what that is and what the end goal is going to be Yeah, and that's why try number three is basically like we should make Questionnaires for each of these things and just and then the TSE can decide what goes on those questionnaires That and we vote on it right in the end the TSE votes on it and decides whether or not it goes through But right now there's not enough clarity for incoming projects in different ones as to they're like well What does the TSE vote on? It's like well, there's these things and they're like well, but that doesn't really tell me So Yeah, I would like to have that more clear for people to understand. Thank you. Thank you All right, yeah, it'd be good to have it clear for the TSE to just Okay, yep, I'll start a thread on the TSE mailing list and we can talk more about it there all right, so moving along in our Rather packed agenda here. We've got a couple of project proposals the first one has been circulated on the mailing list A week or so ago, so I hope everybody has had an opportunity to read through that. I'm gonna hand it over to Sean Amundsen to give an overview and then we can have Sure, so I'll keep the overview brief. I'm not gonna read the project proposal But I'll just kind of describe At a high level what transact kind of the role that it plays So it's a library That is intended to make the execution of Smart contracts easier and pluggable And so essentially what that means is Taking a list of transactions And and ending up with a list of Resulting transaction receipts, which are the state changes And then being able to use those state changes to Modify state So that that sounds simple, but there's quite a lot involved So in in transact You create a scheduler the scheduler Is it is essentially an ordered list of Transactions where the the scheduler determines what the actual execution order is There's two two types serial and that's You know execute one at a time essentially And then parallel scheduler where it uses hints about Places in state that will be read And written to To do out of order execution, but it guarantees the same results as a serial scheduler There's an an executor Component which reads those transactions from the schedule as it is Able to execute them So it's a very iterative process like the transactions flow through So the scheduler doesn't create a schedule upfront. It's it's iterative The executor Basically marshals it to smart contract engines so a couple examples of smart contract engines That exists currently are Seth which is Smart contract engine in sawtooth Within sawtooth currently it's called transaction processor But within transact it's a different terminology But essentially that one executes EVM smart contracts using borough And then another example is Saber That executes WebAssembly code And we can you know envision quite a lot of different smart contract engines over time You know one for damel for example, but you know the list is kind of endless as As to what what those could be And that's intentional because we're kind of taking the position That we don't know what you know the the perfect VM or Interpreter is to use and so they're pluggable The executor also services In any interaction with with state using context manager component and essentially How that works is that the transactions are Isolated in that there's a specific state that the transaction is is run against And the context manager helps With that isolation essentially Yeah, and then the the results flow backward from that all the way back through the scubbler to the calling code In the form of receipts Receipts can have a few things They can have The list of state changes Obviously because that's kind of the overall goal But it can also have generated Events That are Contained in the receipt and so that can be used to generate events for clients for example and then There's a couple other fields To support like Attaching arbitrary like data and stuff like that to send back to clients Now the calling code would take those receipts and apply them against against date So the calling code is is kind of in charge of maintain maintaining the the interaction with state So it's kind of the maybe quick Technical overview You know as a library project just a few more points and You can get into Questions and So You know as a library project the goal here is create Reusable component so it's really really heavily inspired by The code that we have in sawtooth today But the reason that we envision this as a library project is You know to kind of Make it easier for other projects to consume it We know two projects that for sure will consume it grid and sawtooth And and we hope fabric and other projects will will use the library as well So that's kind of the motivation Behind creating creating it as a library in a distinct component. Okay. Thanks Sean. I think Like to give Gary a chance to to Sort of wrap that up and then we can move into feedback from TSE members Like Brian will probably want to get in before the other TSE members, but Gary is not in the little bit me, but He's one of the other sponsors on this project. So wanted to Give him an opportunity to to say a couple words before we move into that You know starting to have some some common some common. I guess I'm unmuted now, right? Might want to get ready to meet me again now Having a common component And I think you know, we've we've looked you know in fabric at various things, you know different transaction processing models You know, we're very interested in things like wasm and other smart contract models and we've plugged in We've looked in the Borough as well so this looks, you know, very intriguing right in terms of you know devils in the details, but You know, I think we can definitely you know look to see a path forward on how we could do this and It makes sense for to try to get involved up front on this. So I think this is a You know, this is this will be if we can pull this off. This will be a great accomplishment Okay, great. Thanks Gary Brian And these aren't important points, but a we have started to talk amongst the staff about maybe reformatting the categorization between frameworks and tools into maybe kind of a slightly richer categorization So the suggestion that this is more of a library, you know Kind of in the same way that grid is kind of templates and libraries, you know is is very much welcome And we won't try to shoo on this into, you know the existing thing I think, you know, what we maybe want to do in a future TSE call is talk about maybe, you know What is if we were to make it four categories rather than two of projects? I pleasure. What would it be? So just bookmark that and then secondly If we could find a different name I think there are quite a few people who'd be happier about that And earlier as we've you know found in the past is better to try to sort this out So I don't know how what it attached people are to the name or if they're open to a an open process for picking a new one Of course, these are completely insubstantial in terms of the technical details of the proposal, but just wanted to highlight them now Okay. Thanks, Brian So yeah before we get into maybe some of those those details about how we name it and Put it into that Are there clarifying questions from members of the technical steering committee This is Nathan. I have a question First I'd like to echo Gary's sentiment that this project seems really interesting to us in the indie project and we currently don't have a Sandbox for transaction or smart contract Execution and as the proposal mentions, there's some interesting possibilities for including secure computing functionality through an interface like this in indies agent layer And then my question was in terms of support in a cross-project way Do you have any developers or contributors who are engaged in the requirements gathering process or supporting the project beyond sauteed? Yeah The expectation is the work with Gary on the fabric stuff and his team to to make sure that for example the transaction receipts That That we end up with can be translated into read-write sets and that it just generally makes sense in terms of fabrics architecture Yeah, and this is Jonathan Levi. I will probably join as well as a sponsor time committing So most of both from the fabric say That's great. I wanted to make sure that we did have well rounded support from from that entire part of the community Mr. Wagner has his hand up Hey, thanks, Dan So I guess what's not clear to me and it seems to have pretty broad support is how much of this is code That's being lifted out of something and how much of this is starting from scratch You know Sean made the comment it was heavily inspired from sawtooth I'm just trying to understand where where are things at are we trying to take something out of a and put it into B or You know, is it already there? It's a little blurry so Not blurry, but it's it's The the design is substantially The same as what's in sawtooth currently, but what we have in sawtooth is Python and sawtooth itself is moving to rust So what we've done is is kind of taken the opportunity Knowing that we were going to present this To Start a re-implementation In rust so that that's listed That the URL is in the back section. I think the last the last part of the proposal And so that code is does not contain all of the features for example, there's there's not yet a parallel scheduler But it is able to run sawtooth transactions now With with some work the APIs are slightly different. We're trying to make it We're trying to use the opportunity to make it friendlier for other frameworks and so The APIs are not not precisely the same and so we're focusing in that rust library on backwards compatibility But as we go through it the design Is really translating What's in sawtooth now and then updating it with With with the ideas Kind of driven by Being a more reusable library component Okay, thank you Right looks like the the imminent dr. Bowman would like to speak. Oh boy So I get so We've talked a lot in the past about sort of cross-platform projects and and I love Architecture and transact and the approach that that you propose on I think as you know, I think it's great work My as a as a high-level project and one of the the real Values in this to hyper ledger as a community is is again the sort of cross-platform availability That doesn't happen by accident as we've seen in the past with You know projects we've sort of encouraged to be cross-project that have not quite gone down that direction So I really have two questions a high-level one which which I think is is the same as what mark was asking and others is What will be done To encourage participation from other groups actively and the second question which is which is related is really Transact itself looks great. How much work do you expect? for a platform to be able to adopt it and who will own the pieces of this that's That's required to do the integration to fabric or indie or Well, so it's done, but So who who does that work and how hard is it? Yeah, so To the to the first one like how to foster like participation So I think like You know, we've learned a lot with with sawtooth and grid on how to essentially get More community Participation and so I would expect kind of continuing with some of the things that we're doing there the primary one is Writing up RFCs for changes in the in the framework and then soliciting Feedback in kind of a very very structured way And so that gives an opportunity That otherwise might not exist for people to to read what the plan plan to change is and then comment So for example one of the the things that transact doesn't have support for now that that we're About to write in our C4 is Multiple database support right and so like that'll be put out as as an RFC and everyone can can comment and then We can iterate on the RFC As a way to have kind of design artifacts Used as as discussion points and that's been working really well In In sawtooth, it's really driven better behavior for the the core developers to have to document their ideas Okay, and then to the second point a second question about who owns integrations That would be the the projects themselves because this is a library project It would not know about grad or sawtooth or fabric. It's really providing a capability kind of in the same way that Versus providing a capability so the maintainers of transact might not know the internal workings of All the other projects right so it would be kind of hard for them to maintain it for the The general idea of it being a library is it's making a certain set of functionality easier and so the the expectation That I have is because it makes it easier. That's the motive. That's part of the motivation for using the library so Within sawtooth right we'll have less code to do this right and so So there will be motivation to maintain the library From the the sawtooth community Like Nathan alluded to like they don't currently have This capability within indie agents but you know Hopefully this library will kind of provide like an easy way to get there without writing a Ton of code to do it where it's like real like literally create a Scheduler and add some transactions to get the results back. That's like you're like the API Should be like really easy to consume And I think the difficult part for projects is figuring out Not how to use the library but where it fits within their architecture Since the architectures are all very very different but but I think that's part of Keeping keeping the design philosophy of it's a library and we don't know every single way that it can be used We just know that That what it's used for is is running transactions and getting the results back And keeping it pure in that sense Thanks for presenting Sean I had a question. Do you guys have any API documentation? um It's not up it's like in the In the trans trans act repo itself the you can generate rust doc Where is it? I couldn't find it in your in your repo It's in the code. So like the the API documentation is like comments on the the documented Functions and stuff like that. So for those unfamiliar with rust, how would you generate that? Yeah, you're on the cargo Yeah, so we would publish that it probably needs more examples and stuff like that But since we know it's a library Made some attempts to make sure that the the functions are documented and that'll continue Okay, yeah, I think for At least for us. So one of the things that people have found useful was we have like a whole docs repo You know a separate repository for building the documentation that isn't Yeah Anyway, I was just curious about that we just sort of On the ledger integration stuff, but but I don't want to go too deeply into that here So anyways, thanks. This looks really cool. Okay. I think Jonathan Wanted to say a bit more Yeah, so I think in order to keep the nature of the project and the spirit of of trans I think I don't know. I don't want to burst into an open door But maybe we should allocate some time for transact to do what transact needs to do and then at some point If you really want to integrate with all the projects, we will have to set up joint milestones So that if let's say fabric 2.2, I'm just throwing a number here We need to change the ordering service or stuff like that that we look at the read-write set We'll be able to kind of look at the timeline of transact and then if something is mature enough Only then or maybe closely before that to change or a man Or basically interact with transact through the development process of each specific project So maybe to first kind of grow, you know, I develop the personality of the project So that trans I guess something a little bit more mature and only and Aligned with that we can influence a bit in terms of the API, especially the ones that know each specific project But at some point we will have to you know, because if you have like a common library that extends functionality for Let's say four projects then we will also need to impose some restrictions at some point later on down the line Right because we will rely will depend on each other, right? Imagine us using open SSL So if open SSL changes API, we need to change So we need to think about like a period of developing transact and then another period of having the cross dependencies In a way, you know, it's not gonna be completely clean when two parts are moving apart and just API Because it will be different levels and maturity of the functionalities provided that I believe right Transact in 0.9 and fabulous 2.2. What do we do, you know, I mean, so Just thinking mind in mind that we are designing and developing it is there have to be friendly for orders to embrace it Okay, those are good thoughts on how we manage dependencies across projects and how We wouldn't want to try to align their release milestones. We should keep those in mind as we Mature the projects A lot and then I saw that you have questions in the dock those might be too low level for You might be better just to respond within the dock on those. I'm not sure but I wanted to make sure that you're Able to ask those or if there's anything higher level Dan, I wanted to follow on to Jonathan's point a little bit if I could Yeah, yeah for the thanks Ben For for the question that I have there. I think we can take that offline or part of the dock As I understood more reading down the document here So I think my my understanding that the introduction paragraph there was was different now Now that being able to read more But but I do have I do have a question whether Whether can Jack pitch into consideration For multi-stage execution because in fabric at the time At the time the smart contract execute the transaction. It is a simulation to generate retry set it is not the time that the You know the transformation get committed You know the commitment of the the retry set would happen later on after the consensus Because the consensus will will take into account that retry set as part of The endorsement policy so it's actually multi-stage if you will execution Yes, whether Yes, yeah, so my my question whether that is if there's any capabilities or feature that allows traffic to do that kind of thing Yeah, so if you look at the the process or the there's a diagram in the bottom that has like the distributed ledger implementation second diagram The distributed ledger is actually in control of like when to apply The state changes Which would presumably be converted to read write sets of a fabric And and that's a conscious decision we made when Kind of refactoring this into the transact code from the sauteed stuff is to separate that step because in sawtooth The the scheduler actually applies the state change and and we are understanding of fabric Such that we thought that that wouldn't work and so we decoupled That step and so that you can generate the receipts and then what you do with the receipts is is up to the distributed ledger implementation Okay, great. Thank you Okay, go off please. Yeah, thanks then Basically, I think it's a good idea to have some shared library of course different projects The major concern is you know, we have a ledger have Already five frameworks they have been independent within different languages like Fabric is with go and sawtooth with Python and Also different protocols fabric using the gRPC and the other projects may using other RPC or REST API so I think it might be a challenge for the transact to define these Some unique API to be work with different Frameworks there. There's no details in such details in the proposal. I think we can we can improve with providing some API and How to like how to handle with different protocols or languages that there will be better Yeah If I could say Something on that one too. I know where you're coming from on that But I think and Sean, you know, you can correct please feel free to correct me where I'm wrong But I don't think the purpose was actually to you. I mean if you kind of read in the document, right? I think those things would all stand outside Right. I think if you're talking about working on specific entry points like in and out They should be actually protocol agnostic, right? I mean the the engine itself has kind of defined inputs of you know, based in the states and what's coming in and format That's in there smart contracts will have You know specific to their engine run times So, I mean, this is I mean a similar analog here would be if for some like there's like as an example Technically it would take labor There's probably no technical reason as an example that in fabric. We couldn't have taken You know transaction processors, right and figured out a way to integrate them in now Of course, we won't need to do that because we're taking the core underlying core, you know slimming that down to a More flexible component. So I don't think we would want to get into things like gRPC and calm and communication protocol here. I Think this is just wrapping additional layers around what would have been like how we how everybody chose to integrate in something like Like like the EVM for example, right? So I think that all that stuff all that plumbing is outside and up to the consuming one to To get traffic in and out and then all we do is you know pass it into here where appropriate Yeah, I agree with all of that And I think like if we if we need to do wrappers from Go to Russ which seems like the most likely I feel like that's something that we can we can Accomplish and like maintain as part as part of the project that if you're calling yet library code, we just have a go API that can be consumed by by fabric and sawtooth and Indie are both heavily rust at this point. So sawtooth is Partially still Python right now, but that's going to go away over time And so really we we only care about Rust and I think it's Go and rust are are going to be fairly compatible in terms of us Making that Through like an FFI layer Okay, thanks. So we're we're down fairly low, which is I think a good sign Mark did have a follow-up that he wanted on Jonathan's comments on the lease alignment I think that'll be the last Comment that we'll have an opportunity to take right now Want to give some indication on on the rocket chat whether you'd like Additional discussion in a later time whether you're satisfied with the discussion up this point Please take some time to do that and go ahead mark Yeah, thank you. Um So one thing and and this does not Go against this proposal at all In my mind, you know, it's not gonna hold it up in my mind, but in general, I think we need to be careful When we start doing libraries and all these different languages Because we will run into dependency held on the down the road if you know This goes into fabric and fabrics using a version to go that's based on a certain version of GCC and this is built on another one You you will end up in in trouble down the road So I think we just need to be careful of things like that over time I've seen that with some of the Ethereum products. I've tried to build So You know, like I said, I don't want it to influence, you know, I'm not saying we should change this or anything But I think it's just something we need to be careful of down the road Yeah One way to address that is to get into a regular, I mean like the eclipse community does right where they have like a yearly release where they do a major primary Kind of a regular kind of heartbeat of minor point releases Kind of adopting a quarterly release cycle here that maybe we try to sink But let's be kind of finding about that Support when we don't change API's and then we have like like the two zero will break some API's Yeah, I didn't mean to say everyone had to follow fabric. I was just saying that Yes fabric has that and I mean a long-term release cycle in general with a short term like where's the short milestones? Not to follow fabric, but just to follow the process. Maybe we already have one in place Okay, I think that's probably We were missing a few people from the car I suppose I should chime in for those who haven't looked at Silas did send a note to the mail list in support there. I think probably what we'll do is Go to the mail list after this But I want to allocate enough time for For taking a look at the next proposal So a few further comments on this feel free to hit the chat or the mail list and then we might take up a vote there if it seems like everybody is ready to deal with and We will know abruptly change over to proposal from Nathan That was posted on to the agenda Yesterday, I think so hopefully some people have had a chance to look at it. I personally haven't had an opportunity So Nathan if you want to maybe give us a bit of an introduction And we can go from there in our remaining 15 minutes Absolutely First I'd like to welcome a bunch of the maintainers on the project who've been working for quite some time inside of the indie agent working group We have John Jordan Steven Curran and Sam Curran on the call Along with a few others. So hopefully they'll be able to help with some of the questions you might have as well We have been Working on it for quite some time and there's as you might know There's two different types of interactions that occur occur within the indie platform right now The first interaction is the one that most of us are very familiar with in blockchain platforms where when you want to set up a network You want a trusted oracle for some information that's shared amongst multiple parties So you set up a bunch of nodes and then you start doing transactions and storing state in digital identity there's that's the interaction that's probably The wester of the two in terms of what it is you're trying to do to accomplish your use case At the W3C we call the part that goes on the ledger of verifiable data registry And what in these main focus is is to provide a blockchain that has the right qualities to accomplish that trusted oracle that lets one Context context to make cryptographic commitments for interacting with someone who's in a different context And then they can use verifiable credentials to share the information between them as we've built out that platform the portion for the two identity owners Making those commitments and then interacting with each other independent of that blockchain has gotten larger and larger And we find ourselves in a position where that portion of the code base is Dominating a lot of the discussions with right within India itself and we've started to find lots of applicability and use cases for that technology and that code in particular that spans well beyond indie and Needs to be used usable and used in places that Don't need to share concerns with this the portion that is in the itself An example of this is you might have a blockchain that wants to use decentralized identifiers or did support In order to share the information on its chain with people who don't know about its Genesis transaction block certainly the The indie portion is good for anchoring the credential definitions in the schemes and things to verify and validate that data But the protocol is required to sign those credentials and share that data across from one party to another party is Very different than the code that goes into building the indie blockchain itself And that's really the portions that we're talking about when we talk about splitting out Agent interaction or wallet interactions from in the end of this new project. We're calling Aries There's if we scroll down Rye to the diagram that's within the project proposal. That's probably the easiest thing to talk to for those who aren't as familiar with this project proposal We end up with inside of indie a resolver layer that lets you Interact the data model and anchor the right objects to the tool blockchain And indy certainly can continue to host those sorts of resolver implementations for both the indie blockchain and other block chains At hyper ledger as we see fit But more interestingly We end up with the credentials exchange protocol for doing this trusted information interaction And a resolver interface that lets us interact with the types of transactions that might be all on a ledger Whether they be the verifiable data registry set of transactions or whether they be value transfer transactions like transferring Bitcoin bitcoins or ether from one party to another We end up with a portion of the code that interacts with Ursa to gain its crypto functionality and then Does secrets management and interaction between more than one instance of the software to to be able to back up and recover those secrets and to be able to share information in a trusted way between between parties so There's a lot of notes in the project proposal about how we think the interaction with indie and And air between indy and areas work going forward and also how that interaction between areas in Ursa Happens to build a reusable framework that we can use kind of as an edge client toolkit to build a client that could interact with a fabric blockchain or Interact with a subject blockchain or interact with indie or interact with other systems That they do verifiable credentials information exchange So I think with that introduction Obviously the project proposal I think is about nine pages long when we had it in in Google Docs So there's quite a bit of content there. I think the the best thing to do is probably to take questions and And go from there So Nathan, I think one opportunity with this project is to bring in Other parts of the it's called the identity community that aren't necessarily engaged with hyper ledger Can you comment on the advantages that you see in this project for the ability to do that and maybe Also how Ursa may or may not encourage their participation Absolutely, we've seen a lot of interest in Ursa from the blockchain side of the community the verifiable credentials community is just Working on wrapping up the data model specification for verifiable credentials exchange And a lot of that spec is not currently in scope inside of Indy because Indy has a particular opinion about how that interaction occurs Separating areas out of its new its own project allows us to expand the scope of what we support to encompass a broader Set of what's going on in the standards body And we expect code contributions for resolvers for Some of the other ledgers that are working at doing decentralized identity We're also had a lot of interests expressed in supporting JWT style verifiable credentials Which will expand the reach of how the code can be integrated into other platforms around the web and By having Indy be independent of areas It lets those contributors know that that those pieces of functionality are clearly in scope And those contributions are more than welcome and also helps build that Compatibility with Ursa for that for Ursa to become more widely available to some of the digital identity platforms besides the Blockchain server side part of the system Okay, great. I hope I think you mentioned separately that you might have some There's some some meetings occurring next week. We might be able to draw in some support from some of those other Yeah, absolutely. In fact next week is the Internet identity workshop in Mountain View, California, and we're hoping to have kind of some preliminary approval at least on the project so that we can better socialize that this is a place that they're welcome to Collaborate and contribute to to help kind of build support for More cross framework Interoperability in at a library code level There's a lot of work going on in the standards Organizations to build that sort of compatibility, but not as much practical code being written as we would like and The Hyperlich community has been the best place. We've had to incubate that community The agent calls regularly have 20 to 30 participants every week And that is basically the basis for this community for the Hyperledger Aries project. So it all the The folks you see listed in the sponsors are already active when their organizations are making contributions either through documentation or Obviously leadership in terms of Helping gather requirements, especially with the work that's been going on in the identity working group So the hope here is that it allows us to pull more of those folks in to be actually writing code and shipping things that build the the basis for Applications and tools that sit on top, which is the yellow box here in this diagram Great. So if there's others participating in that meeting next week, I'd encourage you to help Get some more eyes and interaction on the proposal With Nathan a hand with that See Brian's hand is up Yeah, first, thank you for following the format for the project proposals that makes it easier to review and and and have this conversation And thank you for having a good name and for those listening who Maybe encouraged to support one of the proposals today and not the other I would suggest approving both that way We avoid having 13 projects in Hyperledger. I'm just for anyone who's numerically Super superstitious at least we got past four projects, which is a I'm looking number in China pretty quickly, but Yeah, I'm really excited about this and and would love to see it get started Okay, any other clarifying questions in our remaining couple minutes here Just to say quickly that I didn't mean that we should all follow father's schedule Just to try to see if that process works for all the projects Just to make sure I don't think we can all follow fabric schedule Okay, I don't see any other immediate questions From from anybody out there. So I think we'll go ahead and wind down and please take your questions for The second proposal to the the wiki where it's it's housed or to the mailing list And then I think we'll look at having more discussion on that Next week after people have had an opportunity to dig a little deeper and maybe there's more feedback from the conference next week And we will also turn to the mail list Wippin has his hand up there. So good thing you get to take us out here. Yeah I'm a sponsor on the areas project. I was very impressed with the presentation that Nathan gave at Identity working group meeting. So if you want a longer this course on areas, there is always the Recording to turn to the second thing is I think this Aries proposal is very powerful because it is taking us Towards adoption Which is the most important thing Okay, great. Well, if you wouldn't mind copying the link to that recording into the chat that might be for people to access Thank you everybody for your time and engagement in today's call and we will hear from everybody on the list and Again next week. Thanks