 Hey, welcome Victor. Hello. I might, well, let's see how, all right, I'm not the host yet. I think it made me host, so I will try to pass it. How do I do that, by the way? Actually, you're not, I don't think you're a host. I think another member of the Hyperledger team will be logged in. Okay. I might drop out on second and log back in. All right. You know what, let me do that. I'll be back in a minute. Okay. Hey, Victor, how are you? Oh, you've got that. Okay, Tris. All right. Welcome everybody to the September 22nd Hyperledger technical steering committee call. Welcome to the new participants as some of us are aware, but maybe not all of us. Two things that we have to abide by on this call. The first is the antitrust policy notice, which is currently displayed on the screen. Basically, you have to conduct your activities in accordance with applicable antitrust and competition laws. If you have any questions, contact your company council or the Litics Foundation's council, which is Gessner up to Grove. So with that, the other thing that we have to abide by is the code of conduct. The code of conduct is linked in our agenda. Basically treat everybody fairly and nicely. So with that two announcements that we have the first one standard one dev weekly developer newsletter goes out each Friday. If you have anything that you would like to include in that newsletter, please leave a link on the wiki page that is linked in our agenda. The second announcement is just an update on the TSC to TLC charter changes. They are currently being reviewed for final comments from the governing board. And we are expecting a vote the week of October 3rd on that on those amendments. Any other announcements that anybody would like to make not seeing any hands or anybody coming off mute I will take that as a no. I have a number of quarterly reports. I did include all of the ones that were submitted prior to the global forum, just to make sure that we all had had a chance to look at that it looks like. In most cases we're down to four TSE numbers that are still outstanding on reviewing those particular reports. I guess the question is any questions anything that we should bring up on any of these reports in the TSE call. Hi, I mean there is the. So, Eroha, I, I looked at it before and then I reread it before this meeting and I noticed they had a whole bunch of things that are in the sections called questions and issues for the TSE. But as I said in my comment that I added earlier is like, I'm not sure there is much for us to discuss because they seem to have a solution already for every point they raise. But maybe, you know, people will have different opinions on that. I don't know if they really want us to do anything. It's not clear to me but I thought this was the one point, kind of sticking out from reviewing all the reports for me. Yeah, I think. Yeah. Yeah, go ahead. First of all, feel free to contact me. I found some people and I will add the information to the list. It's just I have some other work to attend to. Right. And I noticed like the looks like the first two paragraphs are about the Ursa conversation that we had a few weeks back. Any updates on reaching out to the Ursa maintainers and updates that you could provide to us on what's happening? The very least, the communication is happening. I've been at the very least Ursa meeting but at the very least we are currently discussing what to do about the Ursa security issues. Okay, so the ongoing conversations are happening. It looks like the. That's great. Looks like the other thing here is just a desire to get more people involved in the development of you, Roja. And that you're working with David as well on some. It will hopefully address that. Okay. Any other comments on any of the project reports that are available. If anyone wants to bring up in a Tc full. No, okay. I did see that the caliper one seems to be available. However, my task was more just complete. So just check that one that came in that was due today for next week. We'll make sure to include that next week. And we'll look forward to the other reports Firefly Ursa, they sue coming in as well. Tracy, I'm sorry I was looking for the right one. It's the grid one. I had seen this when I reviewed it. And I saw that all put a comment in the diversity section. They listed all the maintainers they don't give any affiliation, which is not very helpful. And so that all that said, please, can you add the affiliation and they haven't done so. I think it takes to ping them and get them to ask them to put that information in but it's something we've seen before and obviously this is the critical parties missing. This is a bit unfortunate. And they listed the affiliations for the contributors but not the maintainers that's really the curious part. Yeah. One thing if they just didn't list it at all but I'm happy. I'm happy to reach out on the grid. On the grid discord channel, just with a link to this, I think they're going to grab the link for this comment and ask them to provide some updates on that. And they put the GitHub ideas, which is nice but it will be nicer if they were links. So maybe we could figure out the answer ourselves quickly, but adding to copy paste the GitHub idea to go to the URL every for every one of them is a bit of a pain. Even though it's possible. I didn't feel like doing it. I have to say I was like, Oh, I'll get a profile my lab the information for that matter of the application might be there but it's not easily, you know, available. So, very, very possibly yes. So I'll make sure to send a message to the good maintainers on the list and see what we can come up with about that. So anything else, and then we should bring up. So if there's not. So we have two things on the agenda today. The first one is a presentation on Orion, which is a hyper ledger lab. And then the second one is a discussion on a potential new top level project. So, I know you had suggested the Orion presentation. Who do we have here to do that. So Danny my colleague Danny from the research center in Israel is on, and he will give the presentation. Hi, hi, nice to meet you. I'm here with until for my team. So I'm a manager of the blockchain technology team in IBM research in Israel, and we'll be presenting today or a work that become a hyper ledger labs project that we've been working on for the last few years, and I'm working for the, I think, mostly for the collaboration with the members of the community hyper ledger community around it. So, I will be sharing my screen right now. And representation on. Can you see my screen. We can see it. Okay, perfect. So the project name is say Orion hyper ledger Orion. And it's in general it's a centralized trust blockchain database and I will explain in a bit more details for those who are not less familiar with the blockchain database. So, as I said it's an open source project and it's been contributed and become a part of the hyper ledger labs. And so a few words in the background of what and why we are doing that. So, we all, and I believe all of you that on the school understands that trust is one of the critical issues to the success of many business ecosystem. There are a variety of research in that space indicating that improving trust can play a critical role in success of many business ecosystem. And what we have learned over time and I will show later on not only us learn over time that trust is a very complex aspect and there are many ways that technology can help to address the trust issues but we should take into account different intrinsic level of trust that is the business ecosystem today, and also the topology of this ecosystem, and we should be able to feed the proper technology for proper use, because as we learned over the past using improper technology or pushing more complicated technology or it's not necessarily needed actually creates challenges for its adoption, and rather than moving into the right direction and improving trust people saying that oh it's too complicated we will not go and not use it. So, just in few words that you know that from the topological perspective we can see ecosystem as kind of a centralized ecosystem. These are the ecosystem where there is at least one or more highly trusted parties again not blindly trusted parties but highly trusted parties and the ecosystem we when you can find a dominant or highly trusted parties. Also on the trust level you may see a various levels of, you know, intrinsic level of trust in the ecosystem so they're highly trusted environments I don't know like you, you know with your local grocery store that you know for many years. So then it's the recording of the data you can record on your side there you can record on their side and it's usually sufficient enough. And you know you provide the consistency resilience feature and usually classical databases are sufficient to address the challenges and technology gaps in that area. However, when the level of trust is we call it limited or goes down, you may be in the position that you still trust to some extent and other parties but you should need to be in the position that when you need, you can go and prove things. And you know post mortem you know the authenticity of things being, you know, temper evidence data lineage of what what so so you know just to be able to prove that you or someone has acted according to the agreement that it was in place and already is this kind of technology of capabilities can introduce additional level of trust. And finally we may enter the areas where at the end we have a low level of trust and we need you know to control things so we need to mutually prove things before they actually happening. Perform my even start smart contracts or parallel execution of things and even act in the presence of malicious parties. It's important to mention that there are different types of technology you we all familiar with hyper ledger fabric with the centralized ledger technologies that can address the full stock of these capabilities. However, the class of blockchain database usually very sufficient for addressing limited trust or centralized trust ecosystem and in our case, compared to many other alternatives on the market we also entering a bit in the control side and provide also mutually the point the main point here is that as you go in and use more complicated solutions like the centralized solution and require more things to be done on the trust side the complexity of the solution goes down. So operational cost which associated with that is also getting up and you hit the performance therefore it's very important to be able to feed the proper technology for appropriate use. So why we are actually a doing what what we are doing because you know today in majority of the ecosystem operates still under centralized trust assumption. So there is at least as one trusted party, it can be a cloud provider for many organizations. It can be government agency, as it by the, you know, low or other principle has, you know, a power or is trusted by the country and it can be even a very big dominant player in the ecosystem, who actually highly trusted by others it doesn't mean that other parties should trust that between themselves, but when we even talking about the centralized ecosystem. It still has a lot of place to enable improvements in trust. Okay, and it doesn't mean that we need to blindly trust the central part. Just few examples we can provide more transparency into data lifecycle within this ecosystem, we can prove of the integrity of the data and consistency to streamline for examples the auditing process which is very important for the related sectors. We should be able to guarantee that authenticity and enable multi party interaction to prevent also should be for example, and also very important we should be able to restrict the power of privileged user within the central as a trusted organization. Which is not, you know, or less possible today with you know classical databases. What is important to mention that the blockchain database technology can improve trust and is dedicated to build specifically for this kind of ecosystem. There are much more efficient than using classical databases. Yes, you can add a lot of you know cryptography like we did on top of the classical databases and you will get the same capability but it will be a waste of time so better to reuse someone else expertise. On the other hand if you're using the centralized ledger technology like for example fabric with, you know, even single also single organization deployment. It's usually highly inefficient and doesn't justify the increased cost and complexity of such solutions. We are not alone actually the Gardner indicated the market is very huge for this kind of technology. They believe that most of the permissioned blockchain usages will be replaced by ledger databases. And according to the study done by Ali Baba, which has their own and blockchain database, they have you know a significant improvements in cost 75% in the operational cost. So let's talk about what is a hyper ledger around so hyper ledger around is actually a trusted layer on top of standard databases that provides authenticity and non-repudiation so ability to prove that the data received exactly as it was sent by the source, providing the types of also should this would, of course it provide temper evidence like with classical databases and ability to detect any changes to protected object, even if done by privileged users so the privileged user can go and physically change the beat on on and be able to detect it in a similar manner as is done on the chains of blocks for example in fabric. We are providing provenance and data lineage much more sophisticated for example compared to fabric, which is an ability to record any information, everything that going along the data elements in the database. So who went and by whom, and how was a manipulated the entry. And one of the key differentiating capabilities that we bring to the table is also entering the area of control is an ability for multi seek capability, which is something that enables you to change the value of the key within the database only when there are several designated parties, and in such way you kind of give a control which which is very similar to a, you know, every day contractings that you get. And you receive all of that on top of standard database with, you know, standard database feature so you get you get in the queries. We are not decentralized but we are distributed database so for the resilience purposes and scale so and it's a database classical database. We support standard data model, so in order to operate and work with Orion you can take every, you know, kind of back and developer who know how to work with a Jason store coach DB Mongo whatever. We can immediately start working there is no need to learn additional kind of programming models, which you know you don't have to deploy we don't have a chain code of things that you need to deploy specifically. And of course we support a transactional API is directly. So providing a, you know, enabling you know to perform a set of read write operations as an atomic transaction preserving the integrity of the database. So just to summarize a, you get most of the blockchain features yes you still need in some way to try the central party to some extent yes they, for example central party can remove all the data destroyed but you know, even today when you know majority of us operate on some cloud provider and so on. Yes, in series the cloud provider can remove all your resources from the system they can destroy all of your data, and they can in theory even block some of the communication coming from your clients to your services if they decide to do so, but we usually trust them not to do so. And in many situations that's enough and what you get you get much simple. If you use, you get much higher performance and you get it is a lower cost both operational development and maintenance cost, and you're getting the core blockchain features within the, and this package, just in a few words, a, just how we are doing this In general, we took a classical database in that our sense we took the same database that was used in hyper ledger fabric level to be, and we don't edit the cryptographical layer on top of it, implementing high highly available and secure replicated database with with temper proof immutable ledger inside of it. We also provide data center kpis as I've mentioned with well known programming model to access it. And we provide a very sophisticated much more sophisticated than once type of a historical base query compared to other solutions on the market by leveraging the graph database that we have inside our system. And it's important to say that every transaction that you operate on our database is signed, and you get also a receipt, the receipt at the end, or a set of receipts that you may receive, and then may help you to perform proofs, and actually sees that between, you know, two states of the database the data. The integrity of the data and that no one access or perform the change in the ways that was not allowed by the protocol. One more unique capabilities that we provide and you know differentiate us also from other databases is an ability to manage access control for the database at the key level. In each one of the keys in the database you may specify specific policy who may access the database, who may read who may write. Also we supporting through this and multi seek capabilities. And by the way the admin doesn't necessarily have the access to to to to the keys in the database. So, we can in that way to guarantee or provide a more a privacy, a preserving an ecosystem and enable and users again every we we distinguish between different users and users doesn't necessarily have to run. There are no so do something so the deployment may have multiple nodes on some trusted party or several trusted parties. But every user of the system, which is a permission system so every user has to be recognized and signs their transaction operates may operate on their own without the actual actual additional requirements to install or do some you know sophisticated technical things. There is a list of the documentation and the examples and doctors that can simplify the work. I'm kind of asking you those who believe is that this kind of technology can be useful for a your clients or you are looking and we are we are willing to collaborate and not only back kind of enabling and supporting the use of it within together with your business partners, but also if your beliefs that you can contribute or work with us to further extend this asset at additional capabilities we have a nice list of additional things that can be added just to mention that this you know project is at a pretty high level of maturity it was developed as a product by by the team who has, you know, like sent here on the call, our main maintainers of fabric hyper ledger fabric so it's very educated and experienced team who has been working on that for several years and we have, you know, developed it including test examples, documentations and so forth it's not a product yet. But we are at the stage that we be glad to pilot and also to communicate and you know interact and cooperate with anyone in the community who believes this technology can be beneficial. And for them or like to contribute. I will summarize a my talk about, you know, with several examples that I have personally heard from different types of clients and we already exploring some of these opportunities as an IBM with our consulting services. I mean, to mention, you know, those that are publicly available so so we've been a integrating Orion within three EU ongoing project one is already ended and to others. OPA and I4P are still running in all of these engagements. The original when they were planned there was no Orion yet. So there was a plan to use hyper ledger fabric but when we discussed and expose the capabilities and explain the benefits and applicability of them to the current use cases and their environments the decision was to switch to Orion. And they're very happy for taking this decision and save the world of time and makes the interaction much more and easier. We are also integrated on and working with other hyper ledger labs project for example, our token SDK lab project is already integrated and can use Orion as a backend for example and also in some other ecosystem and we'll be glad to also have the opportunity and discover or discuss other opportunities around other ways for integration. There is a list of potential use cases so the classical one is around auditability security and immutable logging for data management master data management and other solutions that's the most easiest and the simple way to integrate and benefit in the solution you may take already existing ecosystem where you have parties that you know collect information from multiple parties, and in some way interact with them, and you may install or use it as a kind of we call it a secure and immutable log, which will preserve the part of the information or meta information, and that may be useful for your, you know, to improve trust in your ecosystem we see a lot of potential for this in legal space, you know classical contracting to run can play a role of a notary service because all the transactions are signed by all the parties and also signed by Orion so it's not reputable and the server itself can stay later on that something haven't happened and so on. It can be used in the insurance space. Of course, as I mentioned in the financial sector in various opportunities for government sector and everything that is you know regulated areas there and healthcare proof of vaccination credentialing and so on, definitely for various scenarios in supply chain and even as I said, in the entertainment domain and we are doing one of the our project in the Copa Europe is around, you know, media tokenization, reputation management and so on. So, as this is ongoing activities and same for smart manufacturing that we are doing with IFOQ project. So, I will pause here to hear if you have any questions or any things that you would like to raise and discuss and of course, for those who would express some more, you know, interest and for more needle discussion will be glad to schedule follow ups call we did give several hyper ledger talks in different geographies. And we plan to have few more in the upcoming months in the North America maybe in Asia as well and so on and so I'll pause here to hear some feedback and recommendations and input from your side that can help us to to promote the technology and work together. Thanks Danny Jim. Thanks Danny have a quick question on the immutability how that's achieved. Sorry, I couldn't find any information details about this, but don't want to dive into a rapid hole here but can you summarize like for example if I have the private key that signs on all the blocks then I can rewrite history anyway I want right. So how is immutability achieved if you can summarize that. So, so, so in general, when you, you know you have multiple users so I'm internally inside the database we have an immutable look. Okay, so in theory, yes, if you rewrite this log, then you and every transactions that you're doing with our system, you get a receipt. So, rewriting the log will kind of violate the receipts that I will, you know, that you will have on your side, it's like, you know, take for example, the classical, you know, shopping experience right so you went to the shop, and you bought something and you get a receipt now from the shop you can rewrite your books and say you never buy it or do whatever they want right in theory but you have some kind of a proof signed by the server so using his private key that you know this transaction did happen and the transaction and the receipt, including the information about the blocks that were signed. So, again, it may be a bit more explanation it may take you a bit more detail but and we can of course take it, you know, for a dedicated. Yeah I think I understand. Basically, if, if, if we ever getting to a dispute situation it's, it's a one to one dispute, I have a receipt you have a receipt. We have to prove who has the original receipt right. It's not necessarily that simple again it may be multiple participants in the same so you may have multiple receipts and you may have also several receipts from your side so you may have kind of an encore state of the block. And then you have another receipt and we as a database provides set of proofs or capabilities that enable you to prove, you know that the current state of the receipts that we have gave you actually was derived from the another state that you already have. Yeah, yeah I think I understand the underlying mechanism. Thanks. But if needed, you know more detailed discussions of course we can, you know, zoom in and have more detailed view, of course it's an open source you can also go and try. You may see how our approves works. So we provide a mechanism for you that will simplify and you can prove that something really you know the current state is a valid state. So so so that I think in general, the answer. All right. Thanks for that Danny. So I have a comment. It's not a question. It's on the naming, which is incorrect. Right. So on this page you actually say hyperledger Orion. I need to change this so it says Orion a hyperledger lab, which is the agreement that was had when we originally proposed labs as a concept within the hyperledger foundation. So it's just to make sure that there's no confusion between a couple of projects and projects that are currently in the labs area so you know just make sure that you update your documentation to reflect that. I hope one day this record. Yes, I mean, very possibly. And we may end up having to talk about naming I saw in the chat that Dano said that there may be some confusion with the naming with some of the privacy aspects that hyperledger base you had originally where their privacy manager was called Orion. As in when we decided that this becomes a top level project. You know we may need to discuss whether Orion stays or it becomes something else. Yeah, yeah so so so absolutely again we it was the names that we brought just you know trying to separate and differentiate from any existing probably you know that's a, you know, common name, maybe some collisions exist. It's no problem we can definitely rename or change it doesn't need for this at this current stage. My primary asked would be to see so so I know that this kind of niche in hyperledger around blockchain databases is an open area. I believe there is a huge potential there so I'm just kind of asking anyone who believes that this kind of technology can be beneficial for them as well to work together on that so first of all let's, let's enhance the community. We already have some interest from our EU colleagues and you know participating in the project and we trying to build people who are kind of contributors to that. But I will, and you know highly highly appreciate if there would be any hyperledger members who decide or believe that this kind of technology can be, you know, and leverage by them and we can all to be as a contribute to the success of this open source project. All right, great. So last question on this goes to heart. So we need to obviously close this topic so we can get to the second topic that we do have on our agenda so hard. If we could quickly go through your comments question. I just had a quick question. Thank you for the nice presentation. Do you have any kind of paper or anything on the security model of this, I think it'd be really interesting to compare to a blockchain in terms of what are the exact properties you get. This is probably too in depth for this call but if you have a paper or anything on this where you formally state stuff I'd love to look at it myself. I'll be glad to share with you so we currently working on the paper, and also including some performance assessments that we want to do and things like that so generally we were using a common and well known and, you know, security standards and in some ways we used the concept with that we were familiar from my other project like hyper ledger fabric, but we'll definitely, you know, we plan to release the papers this year, describing this technology in more details addressing both, you know, various issues, including the one that comparing, you know, the strengths of different security aspects of this solution, and with others. Okay, thank you. Well thank you. Thank you, Anthony. Thank you for bringing this topic to us. It's extremely interesting for us to see Orion and learn more about it and hopefully some interest will have been obtained from doing this presentation. So then, just to move on to our next topic. The next topic is a potential new project around an on credits and Stephen I'm going to hand the floor to you to give us a summary of what this is and what you're thinking about with this project. Okay. Do you mind if I share my screen. Please. I just did a quick presentation for this. You can see that. Awesome. Okay. This was hyper ledger in the beginning. Basically you had the blockchain ledger at the bottom. You had the capability to construct a credential. It could be given to a holder. Verifier could request a presentation, and the holder can construct a proof based on the verifiable credential they had or multiple verifiable credentials they had construct that proof, give it to the verifier, and the verifier could verify the proof so hyper ledger in the sort of encapsulated all of that. Over time it evolved. Ursa separated at the cryptography that was involved in that some of the ledger cryptography the cryptography around the non creds the signing of the credential and so on so that was put into Ursa. So Aries was started, not so much to replace components of Indy, but rather to enable the interactions between the parties between the issuer and the holder between the holder and the verifier. That really wasn't handled by Indy it sort of said, Oh, we've got these things now they have to be to be shared. And so Aries adds the messaging. The goal is to be agnostic to the ledger that's being used and agnostic to the verifiable credential format. It embeds Indy and Ursa, and it did have an impact on Indy in that the Indy included a secure storage element for each of the parties the issuer and the holder and the verifier and so that moved from Indy to Aries. So you could actually get it from either place right now but it makes more sense in Aries but that's how it's evolved so what that leaves is Indy is a ledger that allows you to store dids and other objects on the ledger. The issuer writes those during a setup phase they write a bunch of objects. And non creds is the actual the rest of the handling so during issue, the holder and issuer work back and forth using messaging to enable the creation of a credential and then the issuer creates signs the credential and gives it to the holder. The non creds part in presentation is the verifier requests a presentation of the holder constructs it using the credentials that has possibly with revocation, and then passes it over to the verifier for verification and then the last part of an non creds is revocation. And so what we're proposing is to take more or less these things out of Indy put them into a top level project and and make it so that a non creds can talk to a number of ledgers Indy being one of them of course and and for quite a while will be the best one to use but other ones can be used and and and enable an on credits to be used on a fabric network where all of the objects are stored on fabric on a Ethereum chain and various others so the point is to extract out the components of an on credit make it so that there's a ledger agnostic API sort of below non creds and allow and allow methods to be implemented that can use any sort of ledger Why do this and on credits is the crucial component of of the work of Indy I think it is the the core component the privacy preserving ZKP technology that is part of Indy. We've got a list of the features in there. Hopefully, I won't go through them unless people want me to so I can, we can get to the discussion but these are really important features that are not available in other verifiable credential formats and capabilities. Indy is is a mature and it's a de facto standard for authentic data processing and protocols so interactions between the issuer holder and the holder verifier and and and and really standard processing rules and capabilities so we want to take that and pull it out. So this is the important why do this is you know, the non creds is getting lost in some of this work and what we're finding is a lot of people want to use a non creds and they're not limited to people in Indy. And as, and as a result we've got a perceived dependency on Indy that actually hinders broader adoption. A lot of people think oh a non creds Indy sovereign, all tied together it's proprietary, you can't use it I think if you if you hear from DHS and I think he actually thinks that's the case that all of those are proprietary technologies and tied together and that's a real problem to have a reasonably large chunk of the community that thinks, you know these things are all tied together so we'd like to untie that and make it very clear these aren't tied together and they're not dependent. The ledger agnostic and on creds is really easy, surprisingly easy. In, in starting this work and as we've talked about it we've got six and counting, because I just got one on Monday that I hadn't even known about independent non Indy implementations that have been created. So people are putting an on credits on fabric on on a database on a file system. You know, in different places checked, which is another ledger without even doing anything to an on credits just using the libraries that are available through Indy, through Indy today. There are several changes to separate out the processing and the object and reading and writing eliminates that my ledger is better than yours, yours debate, probably should have been a long time ago. And, and as we see it it's really important because back to the previous slide. So that's the why and the why now. A little bit one last slide, or two last slides. What is an on credits project look like so an open source standalone and not in an on credits implementation in rust extracted from Indy more or less as is with the one change to make it to, as I say to, to make a clear interface to what objects being written that go to the ledger and and then being read from the ledger. Open source and on credits methods so that's borrowing from the terminology that did spec uses did methods and on credits methods are the things that allow you to use an on credits but then anchor your objects in something in any given ledger Indy did Indy. Fabric, I think a Bezu, or possibly side tree implementation would be a really good target early on. And then others in the marketplace that will do their own, such as the folks at check they're doing. It would include audience appropriate documentation if informational materials for the past six months we've been working on in a non credit specification and a non credits methods registry the method. And, and, and from what I understand and seeing the presentation that Daniela did last week, JDF based specifications are welcome now in hyper ledger which I hadn't heard of before so this kind of got added this week as a possibility. So, acubation of the non credit specification included it right now is a JDF community specification license version 1.0 specification. And so it should be able to just slide into hyper ledger, assuming the JDF background is good enough. And then, and then a big thing which is the working group on a non credits next which is new features and capabilities for a non credits and I think, given the broader point of a non credits through this separation, I think we would get more interest in saying oh this isn't just tied to Indie and and and that's it but we can, we can do more with it well, then I'd like to contribute to the revocation or I'd like to figure out how we could do a non credits with bbs plus but not lose all of the privacy preserving features that that the bbs plus work from a couple of years ago gave us. So, that's what the project would look like. I did look at a few other options and I'll just sort of leave this up but to us, none of these kind of fit and make sense. For the reasons you see on the screen so we just sort of think that a better option is to have it as a standalone significant project in a place like hyper ledger. That's it. All right, thanks Steven. I think you did definitely have some people with some questions here so come on first on the list. Yeah, so hi Stephen I think in terms of like a laser dependency for very powerful condition is really hindering that that is correct because there are many customers who want to implement the very very powerful to stick to the individual and but they are using some other legers in their projects. So, pointed like last year, one of the mentors a program I exhibited one of the main project in the mentorship program for using the fabric and areas integration. And I think my mentee is able to do use a fabric ledger to record all the very five and potential schema and everything on the fabric ledger so the question is like, because what is the difference between that kind of setup and creating a separate project to enable those things because this can be an email via simply adding some writing some smart contract or some kind of API plugins in the existing areas library, or it will be the what is the development using this new project. I mean, that's exactly the scenario I don't know if that was the project that got reported on recently at the at a recent Aries JavaScript meeting, but that is what we want to enable is, is both structure and on creds, the artifacts of an on cred so that it's dead simple to write the write the objects to a different ledger or to read them off of that other ledger. There's not a lot of code updates needed but it would make it very simple and right now what you do is you bring in the, you know, indie components and then you sort of neutralize some of the things that you do so that it can, you can make it work. So in other words, what we want to do is, is make it a first class project that is intended to be used with different ledgers and and you don't have to work around how it is structured for Okay. All right, thank you. So I am next in the queue the question that I have Steven, you said six and counting implementation is that exist out there already have you had conversations with the folks who have done the implementations and are they interested in basically becoming maintainers of this new potential project. Yes. So that is basically as we've done the, the, you know, the specification, and then we started talking about ledger agnostic and people, that's when people started coming forward to yeah yeah we did that. People are interested in, in exactly this. They don't plan on using this is why they sort of independently decided well let me see if I can just use this independent, you know, separately so I get the privacy preserving capabilities but I'm not tied to Indy, and that's why they were doing this they're very interested in being able to do that and support it in a number of places. Indy is, you know, a non creds is very successful a lot because of, you know, the non creds as as being used out in the world, you know what we saw at Hyperledger Global Forum with all sorts of previously unknown implementations even the UN using it. But not everyone wants to use Indy for it and so that's why they've been working around, you know, using the using the pieces from Indy but working around it so they can do it the way they want to do it. Thank you, Nathan. Oh, sorry. In the Aries Charter we actually called out that the non-creds protocol should fully move over into Aries because Aries's Charter was to be blockchain agnostic. But you've called out in the presentation something I found very interesting which was that Aries is more focused on the messaging protocol between parties, and that there's some value in the non-creds protocol being messaging format agnostic. You've been focused a lot on we need something that's independent of Indy but can you say a little bit more about being independent of Aries? That's a good question. I don't have skin in the game to make it independent of Aries but I know there are all sorts of other places that are being used. You know, OIDC we sort of haven't seen how the OIDC for VCs could work but that's one where I thought well they don't want to be tied to Aries, they want to use a non-creds, that's it. And so that's why I was sort of think of it that way. If a non-MO doesn't want to use Aries, they just want to use, they might, I think quite likely might want to use a non-creds. So that's why the positioning there. Okay Nathan, was there a follow-up? Your hand went immediately back up, I want to make sure if there's a follow-up to that, you were getting first before Angela. I have another question but it can wait in the queue till where my hand is now. Okay, great. Angela? Thank you. First of all, I want to say that I like this initiative and especially, of course, I understand there are many details that needs to be sorted out but especially if this means that this entire ecosystem can be brought to fabric and Bezu so that this technology is fully on these other blockchains, that to me these messages, it's very strong, so I really hope this happens. And for fabric at two levels, directly inside as an MSP or on top of fabric, that would be great. Great support from my side. Thank you. Awesome. Alright, thanks Angela. Nathan? The thing that I'm really skeptical on in this proposal is not the technical merits because I think the project independence for the messaging layer and for the blockchain layer make a lot of sense. The thing that makes me really nervous is do we have enough maintainers to support additional project overhead because we could probably recompose the project with less top-level project names and it would mean less project reports and less GitHub repository maintenance overall. So, the thing I'm really looking for when this gets to a project proposal is who's signed on to actually show up and do the work. Because if we're increasing our surface area without increasing the number of solid contributors, we run a lot of the same risks that we've been having on the Earth's side where a lot of people are interested but not a lot of people are actually shoveling code. I think without doing this you risk because of the hindrance of adoption of this because of the perceived tie with Indy that you risk going the other way if you don't do this. Alright, Nathan that was definitely a concern of mine as well. So, you know, we'll keep an eye on that. Troy? Yeah, I think I have one question and maybe one kind of point to raise. So, the question is, I think you mentioned spec efforts and I was curious if you're talking about now having a spec effort inside Hyperledger or the actual non cred spec is being done elsewhere and this new project would just be an implementation of that. So that's kind of the question. And then, you know, kind of the thing I was trying to trace through in my mind was you mentioned that the two formats the W3C verifiable credentials and the non creds. We have a top level project that's just about a non creds. What happens with, I don't know the W3C verifiable credential implementations. As an example, we've implemented the W3C verifiable credential in go within the Hyperledger Aries framework go project. You know, there's this kind of maybe I don't know if I want to call it strangeness but this this kind of inconsistency now that we would have some top level project for one format, and then another format that's basically implemented inside inside Aries itself. So that that that's that's kind of my question and I don't know if you'll call the other thing a concern or an inconsistency. But that's it for me. Okay, so the two pieces the spec, as I mentioned, up till this point has been independent of any particular organization like it's not in diff and it's not in trust over IP mainly because those that wanted to contribute it, didn't want it in one or the other and couldn't contribute if it was in one or the other so we went with the advice of the Linux Foundation and use the JDF community specification license. So that's number one. Okay, in talking to Daniela, I, and looking at the keynote from last week there was reference to JDF. And so that does look like it is an avenue of bringing this back in. The work to do the W3C specs like we're just so it's clear Aries is led verifiable credential agnostic the the both of the three out of the four major Aries implementations frameworks that are within hyper ledger implement, you know W3C specs. And two of them implement a non creds, or sorry three out of the four also implemented non creds. So, you know, that's not going to change the, the inclusion of a non creds is simply a recognition that it is still different from W3C so it doesn't really have to do with NW3C. And yet it is an important technology and it is the only, as far as I know the only, you know, if you will mainstream capability of zero knowledge proof verifiable credentials which, according to Gardner is still on the rising So it, I think it will be seen as a things that people are very interested in learning about making use of and if we can do it cleanly we don't have to force them to by the way you've got to shift your blockchain and your, you know all of that to be able to use it but rather you could just use a non creds. I think that's a powerful message. All right, so I know we're over time here. Try and see your hand is up. I think it would be worthwhile to continue this conversation. It sounds like there's still some more discussions to be had before we decide that this is a project proposal we want to bring forward. So, I'm happy to have you guys do that offline or in the TTC chat if that makes sense for this week. And I'm going to close the call and sorry Troy for closing you off but I do know other people have to get to their next meeting. Thank you. Thanks all. Thank you for the time.