 Okay, let's dive in then. So I'm Richard Eswin. I'm Product Manager at Evernim, Director of Product at Evernim. I'm responsible for our contributions to open source communities, as well as best practices across our products. And I've spent quite a bit of time working on indie areas in Ursa, mostly indie though. And it's a lot of fun. It's a fun project. So I'm excited to share it with you today. Have a couple of slides. We'll move pretty quickly, but indie as a project is a public permission blockchain. And the thing is it's focused on identity and identity use cases. The contributors to indie are worried about what's called self-sovereign identity, which is a privacy preserving approach to transferring credentials, transferring us provable statements about a person between an issuer, a holder and a verifier. Now, indie is a blockchain system for those who wanna know how it works. It uses RBFT consensus, redundant Byzantine fault tolerance. And this allows it, if you're at a hyperledger conference, you probably know about Byzantine fault tolerance, but the idea is you have a distributed set of nodes. They wanna have a common view of the world, but you can't trust any particular node, how to resolve that problem and do it at scale. So that's what indie is good at. Indie, one of the challenges when we have a blockchain like that is getting responses quickly that you can trust. So indie signs, there's a state proof attached to every response that allows you to say, even if I only get it from one node that it's trustworthy that that node's not lying to me. And so that speeds up re-performance a lot. Indies also, the way Indies is structured in self-sovereign identity, it doesn't have to, most communication in an identity use case happens off the ledger. So ledger performance doesn't even factor in for most of the interactions, which is nice. And Indies fairly flexible is a distributed ledger. We put all the states, most of the configuration and all the permissioning on the ledger. And that's really nice because it goes through the same consensus protocol. It's very pluggable and it can be audited and you can see the history of permissions and state and all that kind of thing. And we followed a test-driven approach to development on Indie. So there are thousands and thousands of tests ranging from unit tests, integration tests and even fairly complicated system tests to validate that the system's reliable. So Indies run in production on the sovereign network for over four years now, about four years. And it's gotten quite a bit of real-world use. So we're really proud of it as a system. Now, let's be a bit more specific about how this works. So when you're trying to exchange a credential, you've got an agent that represents you and you play one of three roles. You're the issuer, the person who's going to claim something about a third party. You're the holder, the person who's holding the claim and wants to be trusted or you're a verifier. The verifier does not trust the holder but the verifier does trust the issuer. So when the issuer gives the holder this claim, the holder can then give the credential to the verifier. The verifier can check the ledger and see that the public key is correct and is signed with the correct private key and therefore knows that the holder didn't manipulate it and that the issuer does stand by what they're asserting about the holder. So the actual network then is this collection of Indie nodes and each validator node, it's really two projects at Hyperledger. Its node is the identity logic and plenum is the consensus layer. Now I should say, if you have any questions, feel free to put the question in the chat. I see that there's some questions about, well, we'll come to the questions a minute. I don't want to throw off my timing. So do put them in and we'll come to them. I appreciate C's questions and Omar's. So once you have these agents, or once you have this network that the agents can talk to, then you can do the credential exchange. And the actual project consists of the following pieces. You have plenum and node, that is the ledger. They use a cryptographic library called URSA that's shared across a lot of Hyperledger projects. And then you have client libraries that allow an agent to talk to the network. And there's two approaches used today. There's the Indie SDK that's been around for a long time but people have taken the Indie SDK and they've split it into pieces and rewritten parts of it and try to make shared libraries that the Aries project can use. So Omar asked, what's the difference between Indie and Aries? Indie is the ledger. Aries is the protocol by which agents talk to each other and talk to the ledger. So they're related projects but they're different. And so every Indie agent is an Aries agent but there are other Aries ledgers. So C-Chan asked about fabric. There are Aries projects that use fabric for verifiable credentials and we wanna expand that to other ledgers as well on the Aries side. But Indie tries to set itself apart. There's a few things that make it really good for identity. The first is the permission system I told you about, the auth rules that is very flexible to adapt Indie for the governance policies you want for your network. So if you're on a network where you wanna make sure that every transaction author is endorsed, you know, Indie sports that if it's a third-party endorsement to avoid spam or abuse. You can also say, hey, a new endorser requires three signatures from stewards or two signatures from trustees. Now that kind of process makes it really easy to adapt Indie to your ledger use case. Also is a pluggable architecture. So everything's implemented. Plum supports adding new transaction formats as a plugin. So people have done that to add tokens and other things. It's got a separate sub ledger called the audit ledger which keeps the root hash of all the components of Indie, the domain ledger, the config ledger, the pool ledger and that allows you to validate. You can always go back and say, oh, this was allowed at that point in time based on the permissions on the ledger at that point in time. It allows a transaction author agreement which stewards requested to be able to say for a public ledger that, you know the right to be forgotten is waived and some of these other regulatory requirements are complied with. So stewards aren't legally liable. Sometimes we, well, quite often when you set up an identity network, most of the transactions are read transactions. There's not a lot of rights because only the issuer has to write the ledger. And so Indie will go through and check every so often to verify that all the everything's a consensus and that all the status is up to date. So people are getting the freshest results. There's some extensive capabilities for network monitoring that Indie implements. So anybody with the network monitor role can see actual validator state for any of the other nodes. So you can have this decentralized monitoring but still also keep things private away from attackers. So there's a nice governance there. And then we made a lot of improvements recently that they really move forward in our opinion the state of the art in distributed ledger technology. In how catch-up works, how view change works, how the communication works. It's fast and resilient, it's been thoroughly tested. So that's the introduction to Indie. We do have a weekly, it's actually a bi-weekly Zoom call now. It's every other Tuesday, this week it was on. So in two weeks will be the next one, there's a link here in the wiki. We also communicate on hyperledger rocket chat. Hope to see you there. There's a process for suggesting improvements. You can get the source code. I have posted these slides in SCED, the scheduling software that the conference is using. So you can download these slides and get the links yourself. So that is the 10 minute intro to Indie. I see just looking at questions. Is it easy to deploy Indie as an identity ledger next to fabric? Yes. Well, I don't know why it ain't easy. It has been done. The people who have done it didn't, they said they'd write up their exactly what they did and why. But I don't know the details about, I didn't see that write up. So generally fabric does have an identity system. And you can use verifiable credentials on an Indie ledger to be able to plug into the fabric identity system. I'm not a fabric expert by the way. But the other way people do it is they just use fabric for a lot of things and then use Indie separately just for the credentials. It really depends on your use case, how you'd want that integration work. And as I mentioned, there are other trust block that's presenting here a hyperledger. They have added verifiable credentials to fabric. So that's another option. They've open sourced that work as well. But Indie's tailored to this specific use case whereas fabrics meant to be a general purpose ledger. Plenum could be general purpose but it's really only used for credentials. And so you'll find that there's some things that are quite a bit easier in Indie just because fabrics out a lot of other bells and whistles and things. So that's a bit about what an identity focused ledger means. It's got pre-built structures for credentials, schemas, DIDs, all these kind of things are all built into ledger so you don't have to create them yourself. But of course, if you go to trust block you can find that stuff. One of the things to recognize is when we created Indian Plenum for five years ago fabric was brand new and they didn't have any of this stuff. So over time fabric has gained some of these capabilities but they're fairly new. Even trust blocks code has only been open for, they've really done a lot of that opening over the last 12 months. And so Indie's got a lot more tutorials, instructions about how to do identity stuff. And it'll guide you down the best practices for privacy-preserving anti-correlation credentials. Any other questions? And see, did that answer your question? And Omar, did that answer your question? You can come off mute, it's not a big group. So if anybody has any other questions, feel free to post. I have, we got a couple of minutes. I'm on schedule, fantastic. Let's take you through a quick demo. So I still don't get the role of Indie versus Aries. So there's a, let's go back to this slide. Whoops, I went out of present mode. Indie is the ledger, come on, present mode. Indie is the ledger and Aries is the protocol by which agents talk, that's what it is. So I don't know if a five year old knows what the word protocol means. My five year old doesn't, but the all this tier up here, that's the actual credential exchange, that's all Aries. And this tier down here, the network is Indie. So you could have fabric here, you have other things. Similarly, there are other approaches to credential exchange that are not Aries, such as the one Microsoft uses or secure, secure keys actually move to an Aries compliant. But, you know, there are other ones that are not Aries compliant that do credential exchange that might be W3C compliant, but they don't do zero knowledge proof focused Aries compliant protocols. So hopefully that helped, Omar. So Indie versus Aries is we dig in, is you dig in the project, you'll learn more, but I'm gonna sidestep that in order to give you a demo. So this demo is like, what is a self-sovereign identity solution using Aries agents? So the backend ledger is Indie, but everything else you see is really Aries. So we have this site, I understand this is a developer machine, try to connect on me, connect on me is Evernim's mobile wallet that people can use. And here I'm sharing my screen, I've just got a fresh install, I'm gonna hit the setup button, you know, and I'm gonna put in a really super secure passcode. And I'm not gonna worry about biometrics for this use case. I accept the Evernim license agreement and we come in, now there's a scan button. So I come here, and I've got various organizations I can interact with. Let's say I've got a job at Suncrest Medical, so I need to get my staff passport. So when I take a picture of this, a QR code comes up, I come back to my mobile device and take the picture. I just realized I can't take the picture while you're seeing me take the picture, let me do that. Okay, so that cam comes in. So now I've got a connection and Aries connection with Suncrest Medical and I got my login information, Alice Jones, and I'm gonna accept this. Gotta tap it in the mobile device, not on the screen. And so you see here that it's creating that connection. This is running off one of my developers, one of my team members laptops. This is not a very fast machine. We're gonna get this posted somewhere more public in a little bit. So that comes through. And now it says, that's done. I'm getting a credential from them, my staff passport credential. And this is gonna refresh. Congratulations, you have this and you'll see it in your app. So now I'm gonna come in and get my proof of employment. And similarly, the QR code comes up. So I'm gonna take a picture. Now I can show you, that came through quicker. So here I'm a nurse practitioner and accept that credential. And now if I come up here, I can look at my connections. I've got Suncrest Medical in here and I've got my two credentials from them and I come through and see, those credentials, that kind of thing. So now we're gonna come back and let's use this to get a loan. So I'm gonna apply for my mortgage loan. I know they want me to know I'm gonna need to provide proof of employment and a financial statement. So I've got both of those ready. So we come in, create another connection. I just did something out of order on the demo. It says, hey, I'm missing a credential. I thought I got my two credentials I need. So I do not have my total withdrawals. Oh, that's cause I haven't got my credit union credential yet. Apologies for going out of order. And we're almost done. So I come in the credit union and I can get my financial statement and then I'll be able to do my thing. So now I'm gonna accept that credential. You can see that going through. And now I can go back and give those proofs to get my loan. So take my picture here and it's telling me I still, I'm still missing a credential. Which credential, my total withdrawals is on my, I go too fast. Oh, I did go too fast. You see my credit union one is still coming in. I come to my credentials. So my financial statement is in. This should be in now. Let's try this again. Okay, that time it worked. So they started the total withdrawals and I can go through and validate exactly what I'm sharing. I'm in control. I can select which credential it comes from. Some verifiers might allow me to enter a manual attribute, you know, a manual versus a verifiable credential. And then I can share that all of that. And I hit okay there. And then it goes through. So I've shared that information with large loans and large loans can now come back and say, look, I've got my loan. And then they can come back and approve it and give me an approval credential. When I click that, I'll get a push notification here. So we're out of time, but you can see my loan approval here. And I can accept. Any other questions, anything else you'd like to talk about or like to see, we don't have to leave the room immediately. Could Indie be used to calculate a summary based on a larger set of data and present it to verifiers. So the ledger is only used to store the issuer public keys and the verifier, well-known verifiers will store their information there as well as to manage the revocation registry. So Indie doesn't calculate summaries. That's something the agents do. And one of the goals of self sovereign identity is that each agent, each holder holds their own data. So nobody has a global privacy preserve, anti-privacy of view of the ecosystem. It's meant to be a privacy preserving ecosystem, make it hard for you to get that kind of global view that will allow you to build summary data of the kind of credentials that already has. Now each issuer and each verifier, they can keep track of the information that the credentials they give out and the credentials they verify, but you can't get it across the entire system. You'd have to use a different tool for that and for a different use case. So in the case of financial statements, what is stored? All your bank transactions and the processing partner request and gets the totals. The answer to that is the issuer, the bank, they store all their own data. The question is what data are they going to share with the holder in order to, that the holder can then give to a verifier. And so I can go through and see in this case exactly what is. And now if I'm a holder, I might get additional information from the bank, but I probably don't want to share it. And so it's really up to me as the identity owner to decide how that data should be used. What are the complications in upgrading a public permission ledger like Sovereign to reflect the latest releases of Indy? Well, currently the challenge with Sovereign is an ecosystem of lots of different stewards and each of those stores need an upgrade on their own. We're currently going through a fairly complicated upgrade because Indy was originally, it's designed to be platform operating system independent, but we've only tested it on Ubuntu 16.04 for the last three years because that's what all the stewards were running. Ubuntu 16.04 has been deprecated, it's end of life, so Sovereign's on extended support for that and we need to get everybody to upgrade to Ubuntu 20.04. So getting 75 different organizations to upgrade their operating system in addition to Indy is kind of complicated, I've worn that process. In general though, Sovereign does track the releases of Indy pretty close, usually within about six weeks of an Indy release, Sovereign does the upgrade, but the challenges communicating with the stewards, making sure they know what's in it, that they're comfortable, that they've had the opportunity to review that code and it was decentralized. Every steward can decide whether or not they upgrade. For example, we have a fabric ledger, it's easier to deploy Indy as the identity ledger next to, oh, we talked about that one already. So I think I answered all the questions and excellent questions. I appreciate C, James and Omar, all your questions. Any other questions you'd like to cover? Was that a useful demo? Okay, I'm supposed to end the session five minutes ago. So I'll let you all go. Thank you very much. Thank you, Andres, for giving me some reinforcements hard in a remote conference to get a sense of what people think. Okay, thank you. We'll see you in the next session.