 Thank you. Welcome everyone to the TSC weekly call. So I will go through the usual spiel, given that we have a few new people to the TSC call. I have to tell you that this is a public call. Anyone is welcome to join and contribute. However, there are two conditions to doing so. The first one is to be aware and lead by the antitrust policy. The notice of which is currently displayed on your screen. At least on the Zoom meetings window. And the other piece is the code of conduct, which governs all of hyperledger activities. Which is also linked from the agenda. So with that taken care of, we can move forward with the agenda. First, we will start with the series of announcements. And just as a preview, in case for, you know, people haven't seen it, the agenda today, we will spend a bit of time dedicated to a presentation from some colleagues of mine that have recently launched a new lab, which has to do with interoperability. So, but before we get there, let's go through the usual announcements and quarterly reports. So, first, there's the usual reminder. There's the hyperledger weekly developer newsletter. Please keep it in mind. If there's an open invitation for all developers to contribute to this newsletter, the more there is people contributing to it, the more useful it will be. And you must all remember that when we recently discussed how to fill in the gaps between the different parts of the hyperledger community, there was quite a bit of pointers to the newsletter as a possible means of bridging the gaps. So that only works if everybody makes an effort to consider what they might contribute to the newsletter to make it richer and make it more interesting to everyone. So, I forget who is that Daniela, who added the call for maintainers? No, that's me. So we're having, we're having a call on the 22nd, which is next Thursday. Immediately after the TSC call, we're going to do an introduction to insights to show maintainers how to get more information about their projects. And then we're also going to have a discussion about David, help me out. We'll talk about what other resources people want, and then we can document that and put it into a guide that can include other demos, like the one you'll do around insights or just, you know, explaining how to use different tools, processes, et cetera. So we love to hear from maintainers about what, what sort of things you would find helpful to have more information about. Okay, there you go. And then Daniela put the next agenda item in. Sure. Good morning. Good afternoon, everyone. And just a quick reminder that hyperlogic global form is coming. For those of you who submitted talks, thank you so much. You should have received your notifications. If you have any questions, please just reply back to the speaker email that, that came through the CFP process, or let us know if you're having any trouble doing that. So for those of you who applied and got accepted, congratulations. We're looking forward to getting you on the agenda. We did have some project talks that were accepted, which is great to see. And once again this year, like we did last year in Phoenix, where we had a dedicated space. We had a physical space last year, but a dedicated space and time for the projects to be able to talk about the work that they're doing, what has been going on, any updates, and do ask me anything type of event. So we're going to have 15 minute slots for the each project. We'll put the word out to the maintainers in the different project list. If we don't already have you on, on the agenda, or we already don't have you as with your hands up that you want to participate. So once again, global forum, if you go on the website, you find all the information, but it's going to be virtual in June. And please, if you don't see your project or that you're a maintainer for on the agenda, please let us know as well as soon. The agenda will be announced us on Tuesday next week, but everybody should get their notifications. We're looking forward to it. Great, great content. Really good talks that have been selected. So thank you all for participating in that process. All right. Thank you, Daniel. I have to say, you know, I think we're going to have a little bit of a break. Referring back to the global forum last year, which was the last physical event. Yeah. Attended before the world shut down due to COVID. It's kind of interesting. It feels like eons ago. It was a good event though. So hopefully we can have another good event, even though it'll be virtual. And hopefully the next one will be physical again. So I think it's going to be the last event that the phoenix, that the convention center had. And there were discussions as to whether we should have it at all or not. And I'm glad we kept it because it worked out well. And there was quite a few attendees. It was a good event. And as far as I know, nobody got infected from that, attending that event. So it was worth it. Anyway, with that being said, let's move. Well, is there any other announcements? Anybody wants to insert at this point? If not, let's move on to the quarterly reports. So there are two things we have the cactus report, which was already posted last week. I just put it back because we had a, it had been posted shortly before the meeting and not everybody had a chance to look at it. So I wanted to get everybody another chance to raise any point. They want on this. And I didn't see in the comments, anything specific calling for a discussion. So unless anybody raised their hand now, we will move forward. And we're going to face a similar situation with fabric, which was just recently posted. I, I made a last minute edit to the agenda to add the link to it. But I want to thank my colleague, Dave, who posted it. And so I'll just carry it over to next week. And so we keep the chance to discuss it next week. If there is any, any point that need to be discussed by them. All right. So with that said, I mean, well, as you know, I do want to highlight. We are still missing reports from Quilt and Explorer. So I, I will try to make a point of reaching out specifically. It seems like even my messages and my, you know, attempt to, to get people's attention or TSE mailing list. As you know, I've not been noticed. So we need to contact people directly, I guess, to try and see if anybody can step up and produce the reports for us. But it's always a bit concerning when we don't get reports, but hopefully it's just because they have a bit of attention. It doesn't mean much, but they're like, we seem to borrow, right? It was silent for a long time, but in fact, the project itself was very active. All right. With that further ado, I would like then to stop the presentation. As I was saying earlier, there was a, you know, I pointed out a couple of weeks ago, I think that, you know, I've extended the invitation that we have, that we made to the, all the other groups within a hyperledger to come and present to the TSE as a chance to again bridge the gaps between the different pieces within the different groups within hyperledger. And I extended that invitation to the labs as well. It's a bit more difficult because, you know, I don't have a mailing list I can send to everybody, but I did post it on the channel. And in this case, my colleagues who had just posted the, the lab created, launched the lab weaver, the LTE interoperability, you know, expressed interest in presenting to the TSE. So they'll be the first one to actually take advantage of that opportunity. So who is going to stop the presentation? I have some of my colleagues from IBM research, who have been involved in this project on the call. Yeah, this is Rama. So I'm going to be doing the presentation. Very good. So, right. Can you stop sharing so Rana can share his slides? Thank you. Before, before sharing slides, let me just quickly. All right. So thanks everyone. Thanks to Hyperlegia TSE for giving me this chance to present. So we launched our project as a, the Hyperlegia labs just about two weeks ago. And thanks to our not sponsored it. So the upcoming project weaver is about DLT interoperability. Not blockchain because one of our initial target platforms was called out, which is not strictly a blockchain. So, but yeah, we generally want to enable interoperability of various kinds between different networks. Primarily we've been shooting at permission networks, but our vision is not restricted to this network. We do envision enabling interactions between among commission networks between permission and permissionless networks and so on. So please feel free to go with our project here at Hyperlegia labs weaver DLT interoperability. And if you go over to the overview page, you should get a high level overview of what this project is all about. And then you'll find links to go into more details. So I'll show some of these in the presentation as well. So, hi, I'm Ramah, by the way. I'm a member of the IBM Research Lab in India and this project is a, began as a collaborative effort between different researchers working in various IBM labs from early India and Australia. And we've been working on this for almost two years at this point, though the group base that we've taken is a rather recent effort. What I'm going to talk about is, I'm going to cover the why. What is it, why we are, why we had this project, why we need it, what drives us. And then I'll talk briefly about the vision of this project. What are the use cases it encompasses? Our design that we have implemented as a proof of concept and what applications can be quickly. And within this I'll specifically talk about or a list survey in only 20 minutes. The data transfer across networks and I'll show how we enable data transfer between public networks as well as between fabric and cord networks. I'll give a snapshot of what our project roadmap is. At least for this year. And towards the end, time permitting mentioned what we're up to right now, which is asset exchange across networks. So why are we, why do we need interoperability? So the past few years, since we've had emergence of permission networks, what we see is that a lot of networks having built of limited hope and limited number of assets to manage like you have networks are just doing, I see networks are just doing insurance, some logistics payments and so on. In the real world, a lot of the activities that happen in one network don't just remain in that network. You may need information that decides on the ledger of one network to be used to drive the workflow in a different network. And I'll show you a case later on which involves global trade. But the thing is, really, these permission networks have emerged in the past few years. You get data and assets that are trapped inside these networks, even though it needs to be a way for these networks to share the information in order to drive their workflow. Within blockchains, and blockchains are created to enable distributed trust, right? The enterprise trust. What we want to do is to ensure that when two networks incorporate, we want to provide fuller levels of trust across network interactions as provided in the network today. So overall, what you want to do is to remove data and value silos and it also enables us to scale the vision of blockchain. So at this point, we're trying to find a number of different islands aggregated together. So before going into what we're doing, just cover what are the different views of what interoperability is. So not everyone necessarily agrees on what this would mean. When it comes to blockchain networks or DAT networks, some people imagine interoperability can be achieved by, let's say, shared peer among different networks. So if you have a peer that's coming to different networks, which has, is able to see the ledgers of those different networks, you can then write an application over that running on this on that peer that collects data from different networks, and produces something that doesn't be used. Sort of like an aggregator, but using a single peer as a conduit. But this effect makes this one peer sort of a trusted party for whatever it is we're trying to achieve. Not exactly, it is a kind of interoperability, but that's not what we're trying to achieve. Another view of interoperability is ensuring that peers as part of the network are not restricted to one particular environment or one particular platform. So you could have with one peer network running a common consensus protocol that there's some peers lying on IBM's has someone AWS or it goes on. Again, valid vision, but it's a bit orthogonal to what we are trying to achieve. Another way you can think of is there are existing blockchain networks like a link of a link, which is maybe driven by mess. They offer API sort of at a network level. You can imagine networks of API, APIs via the rest end points, allowing permission to flow between networks. But in effect, what we're doing here is boiling down the network into a kind of a touch-up or a proxy. That defeats the purpose of having a blockchain network in the first place. We want any interaction between networks to be at the network to network level, not between any case of proxies that are supposed to be speaking for the network. So that really is our vision of interoperability. We want to be able to exchange data and value across the network while preserving the tenets of distributed digital technology. And I'll just show what I mean by that in more detail. Our vision is another spectrum of what we need to cover. We can see in this diagram there are different stacks here. Some of these stacks are, you can imagine two different ledgers on a single network, like two different panels on a separate network. The interoperability involves exchange of data and assets between those two ledgers because in the fabric design we can have panels or memory isolation. And one step further, you can imagine data and value being exchanged between ledgers that are running on two different networks yet running the same DLT protocol, that is, say, fabric. It's a step beyond, but again, even though two networks are running fabric, it's making it somewhat trackable. But then further, we would also like to information and assets on the ledger of one network and fabric, say with another, with a ledger on another network that's running on Corda. So there we see we have other challenges too. So different levels of challenges that we envision, you can see this called out in the different layers. When it comes to different DLT protocols, we have to wrap our heads around how the finality is achieved in the different ledgers. When it comes to networks, you have to think about the different test models that the network used at the ledger level. It's about what are the data models they're using, CX2 account, et cetera. And at the contact levels, you have to think about governance and policies as well as the semantics of the data. And what cuts across the different levels are policy and governance, as well as identity issues. Lastly, we also, we don't want to restrict interoperability just among DLT-based networks. You can think of any information flowing from a decentralized network to an electric and circuit system also as falling in the ambit of this world. This is a diagram that roughly may emulate the precise stack. So you can see the concerns rising from sending bytes over the wire right up to policies and regulations at the top. So not just a technical matter. Our focus at this point is primarily what we call the semantic layer, where we are thinking not just about bytes and where we are not exactly talking about governance either. We're thinking in terms of the objects and the meaning of these objects that are resident on different ledgers. And how one would need to move them from one ledger to another while maintaining the properties of, what are the properties of contracts one that we maintain. The main challenge we see in interoperability versus traditional, in interoperability is like that in traditional service world have a single party that is holding service. So in a DLT based network you can't just trust a single party. You can't just assume that one peer speaks for the entire network or one proxy layer above the peer network speaks for the network. Given that the shared ledger reflects the consistency of a network what we want when we get some information out of a network is consistency. So that really is what we are trying to strive for or what we need to strive for to process interoperability and that's also the main challenge how to ensure the multi-party trust. So the way we, or rather the objectives we need to focus on there are anything where we need to verify the provenance of data as well as its velocity and its authenticity that requires some sort of so in comparison to traditional API based integration approaches we need to have not just data being communicated but also some kind of proof and each of the proofs may vary but at a very high level that's what we need in common. Another thing is the distinction between data and assets so we call assets or like a special class of data something that's recorded on the ledger but which has some ownership and at any point in time the asset cannot be copied so the asset that is spread out while maintaining integrity in other words in terms of cryptocurrency you don't want to spend that asset so the distinction between data which is something that you can copy but whose provenance you need to verify so it's assets integrity you need to maintain by having ownership that leads us to the three modes as we envisioned them and in our view these three roughly cover the space of blockchain probability there's clear transfer there's some data item or some information that's recorded in a source ledger or source network that a consuming ledger or a destination network needs to be used to drive its workflow so what we need is to be able to build a mechanism whereby a network can transfer data along with some assurance that the data is valid and the receiving network must verify that assurance as well asset exchange is about atomic exchange of assets in two different networks so most of you probably know about the hash-time-work contracts or the HTSC mechanism whereby you can do atomic swaps across different networks that's basically the use case that the asset exchange is describing as it transfers related to it you want to move an asset from one network to the other that is an asset disappears from one network appears another network again both exchange and transfer these have to happen in the coming so that's the difference between this and the data transfer use case so I'll just give a brief overview of fever I know I have five minutes more so I'll try to give you a short we have a bunch of design principles that we built the solution on one just to run through this quickly we don't want to tie mechanisms to a particular DRT we want to make sure that different networks are interoperating retain their sovereignty maintain control over their governance keep the trust footprint for the minimum not increase any DRT network already possesses we want to make sure that any communication between networks is kept private and confidential as much as possible and most importantly we do not want to have any intermediaries that is either some sort of a trusted proxy or some sort of good party platform that you can plug inside as the approach has been taken by systems like so what we want is to enable peer-to-peer ad hoc interoperation between networks and also again we don't want to allow or require any changes in the underlying DRT platform whatever we do we do it application layer or we do it through any plugins that are allowed by the system even any network that already exists the applications already running on a network or product network we don't want to impact its legacy operation we want to it's necessary we will adapt it a little bit to allow that application to use the capabilities we were providing but we don't want to force the developers to make any changes there this is this is describing our three broad cases as a transfer data transfer as a exchange and what you see here is this is the high-level vision networks communicate with each other for a particular use case via a module that we call the relay the relay is the component that's owned and maintained strictly by a network it's owned by the network's governance boost and that's something that we use to ensure communication so what in fact our protocol does this is the data transfer protocol because this is the first use case that we close and we have a data transfer protocol that's been implemented and if you look at our you will see the components as well as testing and demonstration of data transfer between networks what's going on here so this is like a public network the parts in green are additional components that we add so as I mentioned we have a component of the relay which is supposed to be a DLT independent clients any network can use to that we can plug in certain drivers that understand how particular DLT works like it understands how fabric works and it's able to drive transactions with fabric networks so that's the brilliant driver we have some SDKs and libraries applications can use to make please and receive responses and what we have are specifically like an inter-operation module and this by consensus performs certain functions related to parsing requests as well as parsing responses what's happening as this show in a second by the way it looks like a mirror image but this is part of the network which has similar components has relay and drivers it has these contracts or inter-operation module that performs functions that are common to all the peers and it also has SDK and libraries for any part of the system so just to go real quick the application in one network sends a query what is seeking information from this other network which happens to be on this network's ledger it goes to relays and what is sent is a query for some data item along with verification policy what the verification policy says is I will trust the information if you provide proof of certain standard and that is describing the policy the relay then figures out to its drivers how to take this information along the proof and what it does in effect it sends a request submit to the network and this network has to first do access control because the network does not necessarily want to share information to anyone so there are access control policies in maintained on the shared ledger so the access control rules are also enforced via the regular contract mechanism encoders and force rules so and actual policies once it passes the check it updates data so you have multiple generating signatures over data and finally we also encrypt the data as well as the adaptation because what we want is for the relays which are only somewhat trusted in our framework to not get access to the actual answer or signatures which they can excultrate from the party this goes back to the relay and goes back to the client which can then get the information along with the proof which is the set of attestations and then it submits a transaction with the information from the foreign ledger and this network via its own contracts you can verify that information so HPR verifies the proof that accompanies the data before the transaction is ready so in this case of this scenario let me just show you this use case we have a 10 logistic network roughly loosely inspired by trade lens and we have a trade finance network loosely inspired by Marco Polo which is running on Cuda or trade running on fabric so we have limitations that can demonstrate this so the trade finance network runs a letter of great work what it needs finally is a deal of leading to write the application from the buyer's bank to the seller's bank what is managing is managing confinement shipping seller needs some goods and describes this to carrier and the carrier is generating the deal of leading now what we have is we can identify two points of interoperation one is the chipper is not willing to dispatch goods without knowledge of letter of credit so the network here can via an interoperation channel obtain a letter of credit that was created in the trade finance network and finally towards the end when the deal of leading is created in the logistic network the finance network in order to enforce the payment obligation can fetch the deal of leading from the logistic network so this can be done via the protocol that that's it I think I'm almost out of time right how much time do I have left you can take another five minutes but try to not take too much longer because I suspect there may be some questions so yeah sure I'll try to have a look so this is our road map and we can find this in our repository so I'm not going to go into the details of this so first say that in the fall of last year we created what we call version 1.2 and that enabled data transfer between two fabric networks as well as between fabric and federal networks and that's what if you visit our project repository you can play with that and also we have two research papers as well articles that you can find links to in the overview document and at the end of this year we factored our board to a certain set of RFCs that we had been working on in the middle of last year and we envisioned these RFCs as the basis for sterilization so this is actually the project you're going to find in the repository right now and at present we are trying to we are trying to augment our protocol suite by adding support for using the HDSE pattern between two different networks our immediate targets are enable aesthetic scene between fabric networks and also between a fabric and a Bezos network and we're going to be demonstrating that using a delivery versus payment use case so what is at a high level if you already know this pretty well but what we want to keep here is that party X and party Y both have accounts on two different networks X owns asset M in one network, Y owns asset N in the other what we want to achieve is Y gets M from X and X gets N from Y in two different networks but these two have to happen atomically so both transfers happen and this is our mechanism if you visit our RFCs you can see the diagram there and for demonstration use we are going to target bond exchange in one network that's maintaining bonds in two different commercial banks exchange for payment via some central bank digital currency in a QDC network so the steps here you see are respond to the hash framework contract steps where we create a lock and asset in one network using a particular hash which secret is known only to the lock and the other party can use the same hash to lock asset in another network and the first party makes a claim on this network and by revealing the secret and the second party can then claim its reward or other exchange asset on the other network by using the same secret so this is what we are trying to do so so I take questions all right thank you I know it's a bit of a challenge to cover that much in so little time but you did a pretty good job so thank you I suspect it went a bit too fast for some but so please does anybody have any questions maybe you did a good job but nobody has questions either they are lost or you already answered all their questions yeah feel free to ask any questions and you know you can do that and please do visit our large republic at the court if you want to contribute if you see any issues and you can have a dialogue there all right Brian is yeah maybe a question as much for the folks involved with Cactus here as others I don't know if you've looked at Cactus and the work going on there but how do you compare it to it do you see the possibility of combining efforts in some way so thanks for the question yeah we have been in talks with the Cactus folks the past few months we have been thinking about how to effectively share some information and we haven't said anything at this point yet but what we felt was that approaches are pretty different even though I'll say that the motivation as well as a lot of the use cases is even going to overlap and also the fact that Cactus also envisions enabling particular interoperability among networks rather than using the shared infrastructure like cosmos apocadote similarities I see once you go a level deeper there are significant differences in philosophy as well as the system architecture but we are in touch with them and the dialogue that we would have over the next few months yeah indeed we had a few calls where we actually talked with several people from the Cactus team and I see Peter, Hart there on and I mean the sense from the IBM team is that it's different enough that we cannot just pretend we can just merge those two things probably end up with the Frankenstein kind of monster that nobody would like but they are at the same time some seniorities and the idea was that once the code is available because it has only been recently open sourced the Cactus team would have a chance to really dive into it and we could continue the conversation and see if there are at least some modules that could be you know shared between the two projects and so I don't know if the some of the people from the Cactus team had a chance already to look into it maybe Peter I know he was eager to see the code I don't know if he has any opinion at this point to complete but I haven't been able to do a deep dive just yet it's been crazy busy but that's definitely on my to-do list to read the code back-to-back and then formulate more opinions alright totally understand alright so there is no other further questions I guess we'll be done with this for now thank you thank you Raman for presenting and yeah you're welcome I mean obviously this is one of those projects that by nature you know kind of like cross different technology spaces and I think could be of interest to quite a few people and not you know it's not just an addition to fabric or something along the lines so so let's continue with the agenda then so we've talked about it quite extensively several times there is an open issue on the you know the proposal to eliminate the lab sponsor requirements so today to you know to submit to get your proposal for creating a lab you must have a sponsor on the website I'm not going to redo the whole discussion but you know I feel like okay I put a proposal together there's been a bit of back and forth I feel like everybody should understand now the pros and cons it's not perfect necessarily but you know at the end of the day I think it was Gary who commented and basically said yeah you know I trust that the stewards what this entails and if they're okay with it I'm fine with this sounds like a reasonable proposal so I think we should make a decision and decide one way or another but just get over with it so is there any questions from anyone any comments Hey Arno just to be clear we have total support from the lab stewards for this right well we'll find out I mean the lab stewards are basically on I mean yes I think you know I mean Tracy has expressed herself before unfortunately she's not here today to vote I thought she would but you know nobody has objected to it that I know of because as I said at the end of the day the you know even you have expressed there are anecdotal evidence where the sponsor has actually played a role and having this requirement has allowed lab people to connect with some people in the community but for the most part it's only used as a filtering mechanism which the stewards already provide so the stewards have affirmatively said they're okay with this I don't want to pretend I know the absolute answer from everybody is the stewards so but I yeah they have not said no I think the only reason that's important is because the responsibility for making sure the labs are going well then falls on the steward I mean I know the sponsors weren't necessarily you know active in their oversight role or their guidance role but if the stewards are comfortable removing a layer of in direction removing a layer of that and being directly responsible for the labs then I can't see there's a reason to object to it but it just adds some work to the stewards yes no so that I can clearly address that point the labs stewards do not rely on the sponsors to do any of this because we know that sponsors don't they've never been made responsible for that there were discussions at different points in times that what how much the sponsors were expected to do and the really is you know it's extremely limited and it's a discretion of the sponsors if they want to do it more but in no way shape or form the stewards can rely on the sponsors to do any kind of real hand holding past the point of the submission proposal the proposal submission sorry so I guess what I'm going at for me to be comfortable voting yes on this I want to hear a steward say yes this is a good idea I am one I think it's a great idea and I've served as sponsor on the more lab proposal that I should have because and I always felt well I'm doing this job twice as a steward and as a sponsor why would we do this and when I say and honestly I have volunteered sometimes just you kind of like out of pity because I could see they were interesting proposal put on table and the people were just not able to get a sponsor and I don't want to always volunteer but you know you're like okay let's just get it done put me a sponsor let's move forward and I don't know we don't have any evidence that this was ever detrimental to hyperledger in any way and the other questions Bobby my only concern I agree not having the sponsors is a great idea and it eases up on the pressure for the people who are organizing the labs but the only piece I don't want to go away is the maintainers and the TSC looking for new projects and feeling because they're not a sponsor they can't bring them to the labs wait I'm not sure I'm following your point there Bobby so I was a sponsor for a project and I brought it to the labs and then Tracy took it over and ran with it and now if that sponsor piece goes away for me I don't or for us I don't want the people who are hearing great presentations just because they're no longer a lab sponsor to feel that they can't you know reach out to you or Tracy the lab sponsor the lab stewards and say I have this great project you want to go look at it let's see if it fits because I think that's important that funnel and I don't want just because the TSC and the maintainers are no longer lab sponsors to think that they can't introduce projects yes no absolutely this is definitely not the intent is definitely not to block anything it's to help bring in more things if anything one proposal I had was to not remove the role of lab sponsor necessarily but to remove it as a requirement for lab proposal which means we could even still have it in the template and people could fill this out if they happen to have one and but you know it's it's not a must so we would the stewards would still accept proposals that don't have a sponsor and in fact the proposal would still standard because it says eliminate lab sponsor requirement which is you know not necessarily the same as removing the role then I agree thank you anyone else you want to call for a vote you'll need to find a second yeah I would like somebody to second it if they agree Arun welcome so how do we decide the team like for example the stewards how do we decide the stewards are like for example if we have a sponsor then they will look at the project and they will understand the project they will have their pitch as well in the proposal so if we eliminate that and then how do we streamline that process by with the pictures so I again I think you know so the stewards I mean you know we see technically speaking people submit a proposal by doing a full request where there's a small page which follows a template that is provided that basically ask them okay what is this about and you know who is involved in this who would be the primary you know the initial contributors commuters and then there is a question as to whether there's an existing repo that they want to bring in and then there's this question do you have a sponsor who is it and so today the stewards when they receive this they review it sometimes I mean you know we say sorry this is not clear you need to explain or do you know about this project that we talked to them we kind of try to do a bit of coordination you know look for opportunities to connect the dots with other existing projects and we make sure that this is you know this is clarified and it makes sense sometimes we have to ask them to change the title to make it more meaningful and and then we simply ask the sponsor to confirm that they are sponsor for the proposal and the sponsor just says yeah and based on that if there is two words that have said yes the proposal is approved so there's really not that much to it I want to be clear and and we've seen proposals that got stuck because they've gone everything else but we tell them well you need a sponsor and they say we don't have one we do a fine one and we've been through this exercise many times where this issue was brought up to the TSC we look for volunteers we look for a way to you know set up a list of sponsors from which people can you know find names and reach out to try and get them to enroll as sponsor we don't have anybody a volunteer you know in fact you know I feel like if you oppose this you should by default you know volunteer to be a sponsor because I think it's a bit unfair to say you need a sponsor but just don't come to me there's a very limited set of people who can qualify a sponsor and it makes it unfair you know requirement in my opinion so does that address your question Arun that you were talking about the process streamlining I think it's pretty streamlined from that point of view so we'll keep still the field just like we make it optional for now we can definitely keep it on the on the yes on the form on the templates sounds good I'll say also say I went back and looked at some of the original discussion one of the reasons we had a lab sponsor was to try to make it harder for people to start labs that we wanted people to have like some connection to hyper ledger I think this like there's I believe a Chris Ferris thing that like well we don't want labs to you know to be totally unrelated to hyper ledger but I think kind of our thinking has changed like that which has changed around this and that sort of now we think labs are like a good avenue for people outside of hyper ledger to sort of join the community so if we sort of accept that rationale then making the lab sponsor go away makes perfect sense all right thank you anyone else okay anyone else for second can second the motion so we can have a vote I know okay thank you so does anybody want to object does anybody want to abstain so this passes thank you all right we'll update the documentation and we'll keep the sponsor field in the form we'll just not make it a requirement for people for proposals to be accepted all right thank you oh we're almost out of time I didn't think we would spend so much time oh well let's see well I guess we'll stop at this then there's four minutes left there's not enough what I wanted to do and we'll keep crying obviously with the presentation now so it took quite a bit of time but I think it was I hope you agree it was time well spent and what I want to do moving forward is go back to the decision blog and do a little bit of housekeeping I think there are some entries there that can be probably disposed of and just say you know we we throw them or some I think are kind of dependent on others and could be disposed of you know pending resolution on some others so for instance there are you know several entries regarding how projects evolve how we review them if they've derived from the charter and stuff like this I think some of this can be addressed once we have like badging proposal which provides us with like this ongoing review process and so I'm hoping that we can kind of close some of the related issues so with that I think unless anybody else has anything else they want to bring up now I'm going to give you back two minutes and close the call of this as call another drama I just wanted to mention that we had a proposal at the Global Forum so if you're interested in finding out more about interoperability and challenges I had you okay that's a good point I mean I don't know you were breaking up a bit so Rama is just advertising that there are sessions related that interoperability at the Global Forum so if you haven't heard I hope this clarifies so look for those sessions if you're interested in that topic alright let's close on this thank you all for joining we'll talk again next week