 So the live stream is going, so let me get the recording going. So take it away. Oh, welcome everybody to this meetup. This meetup is going to be a lot technical. I saw there was a meetup the past week about hyperlayer areas. And I think that hyperlayer and on credits was discussed in that meetup. So the idea is to see what are the components of hyperlayer areas in terms of the trastrine wall. So there is an issuer, there is a fire, there is a wallet involved. And what, how can we leverage the hyperlayer and on credits in order and some code that they use in order to, to have a wallet with hyperlayer areas in order to run this in the browser. Because until now, every demo that I have seen with hyperlayer areas is about mobile, you need to have a mobile application going to run it on the server. And I think this makes things more complicated because development is way more expensive in the development, in mobile development rather than in those programs. But well, let's start with introduction on the idea of the city of Confusor, what we are specializing in hyperlayer technologies from Spain. The main speciality that we have is hyperlayer fabric, but right now we are exploring and doing some projects in hyperlayer areas. For example, we have been working for three years in part one of the most popular projects about hyperlayer fabric. The sixth hyperlayer fabric is the fabric operator, which is part of the web, which allows you to create networks way, way more easier, easier than the common approach which is to use documents that are custom manifest in order to deploy the hyperlayer fabric. We have experience with areas for one year where we are still learning a lot and seeing the possibilities about this project. This is one of the reasons of this meet-up in order to have a better and explore this new approach to develop into developing agencies in areas and how can this be integrated. I'm the maintainer of the hyperlayer, and if you want to contact me, I'm David Viejo, so just type it in. And here at the bottom left, we have a QR code. This QR code is for repository, that holds all of the code and all of the instructions in order to run the code. So for people that don't know about hyperlayer areas, hyperlayer areas is a set of RFCs, a set of standards, and there are multiple implementations. One implementation is the one from the Aries-Frengo JavaScript, but there is also one implementation that is in Python, aka Py, which is one of the most popular, but aka Py can only be executed on the server. And Aries-Frengo JavaScript can be executed in the mobile, it can be executed on the server, and with these changes, it is possible to be executed on the browser. So the context, we are going to see the code will use hyperlayer areas, code will be used, there will be three applications, the issuers, the un-credits API, this is an API that is used in order to manage schemas and in order to manage the credential definitions, and the workforce, which will use hyperlayer areas, and the code from here, in case you want to start looking at it. So when doing the projects that we have been developing for the last month, we found that making a mobile, or making a wallet in a mobile is very expensive in terms of development, in order to showcase what is really possible. So one of the reasons is to be able to make a proof of confidence, to develop a proof of confidence only in the browser with the web technologies, which have been way easier to deploy, to change, to test overall. And there is no set up, no need for complex setups, or installations, or policy to the app repostor, or to test flight, or to repostor, and this simplifies a lot the user experience. Of course, there are limitations, because it's not as secure as the mobile, but right now almost all of the projects are proof of confidence, so I think it makes sense to make the development more in this case. Also, there is one thing that is not here is that this will allow to develop a Chrome extension that can be used across multiple websites. We haven't started the development yet, but this is something that we want to explore in the near future, so to have a web extension that can be used in order to present credentials, stop credentials, or interact with other agents, because hyperlaboration is an agent that can communicate with other agents, and this is done via performing a connection between these two networks. And once the connection is established, then you can exchange messages. So in order to give a general picture about the architecture, so we have at the left the browser, and this browser uses the web wallet module, this web wallet module is in the repository you can see, and it uses a repository that stores the data in the stable, and this is how we change the documentation, because while using hyperlaboration as part, this data was being stored either on the file system or in a Postgres database, so we wanted to change this, and luckily the hyperlaboration framework has a possibility to do this very easily. So we have created a module that acts as a wallet and all of the data is encrypted in an store in the index. On the other side, there is an Anoncrets module that has a browser, Anoncrets, and this browser Anoncrets interacts with the web assembly, and this is one of the things that we needed to do, because in order to run Anoncrets in the browser, we needed to compile the Anoncrets, which is written in Rust, to JavaScript in order to be able to use it. We tried the same with Haskell in order to not have to write a wallet implementation, but it was impossible. This is the general architecture, and the Anoncrets module has this browser Anoncrets and also connects to a registry that has the schemas and the clenical definitions. In this case, from the browser, you only get the schemas and clenical definitions in order to see the integrity of the Google but you don't restore any schema and you don't restore any clenical definitions. This is something that they issued to us in this case. I'm sorry to interrupt, David. I don't know if you saw the comment in chat. People are asking if you can get the code, the link to the code. Yeah, it sounds like there might have been a little bit of an echo earlier, but it seems fine to me. I don't know if I can check the rules now or better now, at least let me know if I can say this. So any questions at the end now about the Anoncrets, wallet implementation, et cetera? We will see if we can clear the code. Now it will be better. Let me know if it's not better. David. So we have, this is a typical slide about the trash triangle architecture. So I wanted to do the same in order to illustrate what is the component that we'll add in this trash triangle. So we have the Aries-Wiesel interface, which is on the browser. This is the holder. This is one that... Okay, perfect. Now audio is very good. I had another input as microphone. So we have the Aries-Wiesel interface on the browser, which is the holder, which has this wallet in the browser and the Anoncrets using WebAssembly. We have the verifier API, which in the code it is in the same server in order to simplify the implementation and in order to be able to understand it better. This verifier API and this issuer API read and write from the Anoncrets API, which is a very basic API that is used to manage schemas, create definitions. A great definition is the link between an schema and an issuer, and also a revocation registry. This revocation registry we will see later. This is not implemented right now. This is a proof of concept and this is something new, but the idea is implemented in the long run. And there is a trust between this verifier and this issuer. So for example, a verifier can check if a credential is not evoked. So the verifier will have to contact the issuer or there can be an issuer registry that contains the list of issuers that are allowed to issuer credentials. So this trust is a simple line right now, but there can be many APIs involved in this process. And at the right we have the issuer, and the issuer interacts with the holder. This communication is bidirectional, and the goal is for the issuer to be issuer credential, basically to the holder. So in order to recap, our issuer interface for the holder, the verifier API for the verification, the issuer API for the issuer of credentials, and there is an unclas API, which is used by everyone. And well, I forgot to draw a line here, but the areas by also access this unclas API, which is a verifiable data registry. So the components that we saw before, the areas issuer API, the unclas API, and the areas user interface, we will not get any any depending this because we have already explained it. Now, in order for the browser, for the agents in the browser to communicate between each other, or for an issuer to communicate with the agent that is in the browser, there needs to be someone between some component between these two. And this is the mediator. There is a, we have developer mediator, which is based on AFJ. It is from JavaScript, which is in this URL. So you can use it if you, if you wanted support to services, HTTPS, and WSS, so secure web socket. And basically what it does is that the user one establishes a connection when it starts with the mediator. And then all of the requests that need to go to the user will go to the mediator, and then they will be routed to the user. There can be multiple users connected to the same mediator. And there is a routing key that is used by the mediator in order to know where it needs to send it. The mediator has a database, which is Postgres. And if the user is not online, then these messages store in this database. And then when the user reconnects with the mediator, then it downloads, it downloads or downloads all of the messages. So that is how basically works. We will see this in action when we see the demo. And that's it. So if you have any questions, please feel free to ask them. Otherwise, we'll keep going. But this is a simple middle word between two agents. And the user also connects to the mediator in order to send a credential or send a message to the user. So what is the goal of a native agent? Establish connection with other agents. Issue and verify our credentials. So if we have some credentials that we want to issue, then this is possible with this agent and also requesting proofs. So a proof can be that I want a credential with this schema. And the schema has, for example, a property that is the age. And I want the age to be at least 30, for example. So this can be a proof that can be requested in case that this is possible by the holder. So in case that the holder has a credential that matches the predicate in this case, then the holder will reply. If not, then there will be not not any reply in this case. And the issue and verify our credentials right now is for the demo. It's very simple. We just set the connection ID that has been established between the user and the issuer. And we state the name and the age because we have a simple credential and that's it. So we will see this in the demo. Now for the unknown creds. And I think the next slide are about the unknown creds. So maybe I will move this a bit. Better like this because these are the schemas, the entities that are using unknown creds. So the predate unknown creds stores credential definition which we have seen here. And this is this part, the verifile data registry. This is why we need the unknown creds API in order to store all of these entities, the schema, the public credential definition and the revocation registry. This is not implemented right now. And unknown creds is used in all of the components, the holder, verifier and issuer. In the issuer, there is this private credential definition. In the holder, there is this link secret. But the main entity in the holder is the unknown cred credential, which has a link to the scheme ID from the verifile data registry, the credential def ID, the attributes value use, the signature, et cetera. And the verifier only has the unknown cred presentation, which there can be a presentation that has multiple credentials. And that's it. So in order to run unknown creds on the browser, we only implemented this part, the holder, because the issuer and the verifier will be executed on the backend. So there is no need to implement an issuer in the browser yet. I don't see the use case. But for the holder, yes. So we have implemented the link secret, the blind link secret and the unknown credentials. And the rest is not needed for this. So the reason why unknown creds in the browser, so we have the... Indy was used as a verifier data registry. And this is another possibility for the wallet. But it was split into WASCAR, which is right now the recommended approach for the wallet. I tried to compile it to WebAssembly, but it wasn't possible. So this is why I decided to go for a WebWallet. And the unknown creds was developed to handle schemas, credentials, zero-nose proofs, credential definitions and presentations. So these two projects were born, basically. And in the future, I think that ASCAR will need to run also in the browser, but not yet. So the unknown creds API, we have mentioned it before. It supports schema creation and management. This is... So if you take this code and want to put it into production, you want to be able to manage the lifecycle of the schemas so that no one, not no one, but only the ones that you want can create a schema. For example, in EPSI, in the European Blockchain Services, not anyone, not everyone can create a schema. So you need to be authorized in order to create a schema. And there is a process. So this... What we're going to see here is not what happens in the real world. There is a workflow in order to create a schema and also in order to create a credential definition. And the users and the holders will need to integrate with this API. So this can be in form of an API or in form of a Blockchain network, which is the case for Indy. So in Indy, you just connect to the Blockchain network and since everyone can read, then you can fetch the schemas, fetch the credential definitions from this Blockchain network. But with unknown creds, you can also implement your own workflow in order to fetch the schemas from whatever you want. So we go through the address user interface. It's a website developed with beta and type script. It uses AFJ 0.4, 0.0. It uses a custom implementation of the wallet to store data encrypted with the wallet key. The wallet key is the one that we... And it can be changed, but for now not, but it is the one that you specify when creating the agent. And we will have to specify this when entering into the application. There is a custom implementation of unknown creds that interacts with a web assembly module to use the unknown creds project in the browser. And the schemas and credential definitions are fetched directly from the unknown creds API. So this is what the address user interface does. Limitations found. If the user changes the browser of not from TAF, but if it's on Chrome and you want to get the same data from Safari, then this is not possible. There needs to be a way in order to recover the account. Either store it... There is a way to store the data in a remote database. This is also possible because the data is encrypted with the wallet key, but at the moment for this demo, it is a limitation. And for security reasons, the user has to enter the wallet key every time the data is refreshed. This is for security reasons, as it states. And in the mobile, this doesn't happen because you have the mobile open and the application open, and you don't usually close the application and then start it again. So this is something that I found that is very bad for the user experience, because every time that you want to initialize the agents, you need to enter the wallet key. This is not good. So it well goes to the demo. Skills needed for this work. But before, let's dive into the skills needed for this workshop. You need basic knowledge about cryptography, public infrastructure. There is, in fact, all of the identity areas work. Realize on cryptography. So you will need that. You will need React. You will need Node.js knowledge about Node.js with TypeScript, basic networking concepts, because we will connect to the mediator using WebSocket and HTTPS and Rust WebAssembly, not a lot, because I'm not proficient in Rust, neither WebAssembly. But if you want to dive in and understand what has been done, then this is good to have. So I think we're close. So before going into the demo, the changes to an on cred. So basically we have to fork the project, another new interface for WebAssembly and compile it. And you can check also the repository here. And with this command, cargo build, no default features was, then you are able to generate the JavaScript in order to include it into your project and be able to use an on creds from the browser. I will paste it here in the chat in case someone wants to do it. And the functions, sorry, this will be supported in the last minute. So the focus of this project is to support the functions in order for the holder to be able to work. So these are the functions that are implemented, verify presentation, create credential definition, create presentation, and process credentials. Any other function is not supported. There are some functions that are helpers, so this is easy to support, but we haven't implemented every function in this case. And special thanks to Berend, SleetLets, from Animode, which helped me in the guidance in order to help me to get this implementation completed. So let's start with the demo before let's go to the goal. The goal is to have two tabs opened in the same browser or different browsers. These agents will connect to the mediator in order to send messages, receive credentials, etc. And there will be an issuer on the right. Right now we will emulate that we are an organization and this will send the credential through the mediator to each of the user one or to the user two. The link is returning 404. Okay, so let me try to why is it returning 404. Yeah, for me it works. I don't know why, but at least he is returning 404. Okay, okay, okay, that's right. Perfect. So yeah, this is the link, not the one. Perfect. So this is the goal, the issuer to send the credential to the mediator and then the browser one and browser two connect to the issuer and between each other. So if there are not any questions, then we will move forward. Now is the demo time. You can scan this code or go to this Github repository. No questions? Okay, let me get the business code. So here we are. As you can see, well, this is the, we'll make it a bit bigger. So this is the structure of the demo in the components folder. We have the Anunculus API, which we have seen before. There is issuer and there is user interface. If we see the Anunculus API, it is a simple server with like a hundred lines. So it's very, very easy to navigate and we're using type ORM in order to save or to store the records in SQLite. So in this case, this is what we have done in previous projects is that instead of saving the data in SQLite in a normal database, we store it in a blockchain and this blockchain can be hyperlabeled because we have found that there are many, many companies that have hyperlabeled that was running and starting a new blockchain network like Indie. There is a lot of cost involved because they need to know how in the works and with hyperlabeled they usually have a network and multiple participants. So it's easier to build a workflow there. But this is as a simple implementation, but keep in mind that the data source can change. What remains the same is the API, which you can implement as you want because one thing is the API and the other thing is, in this case, the issuer has a rest and on credits registry. It has an agent, a resource, and then it has a registry, which this is an implementation from an on credits and this is an on credits registry, as we have seen that the revocation is not implemented, but there is a get a schema function, a register schema function, a get a credential definition function and register credential definition. So with this form we're able to work. And if we see an implementation of a get a schema, then what this does is it goes to the endpoint, the endpoint is static right now for the demo, this is the port of the on credits API and it tries to fetch the schema by the ID and then it returns the data. And they're the same for the register schema in this case, in this case it's a post, but this is the idea. So and this rest on credits registry is the same in the browser as it is in the issuer. So you can implement your own on on credits registry, this case, the default one is the one from indie, but if you don't have an indie blockchain network, then you can implement your own. Since you will be developing the agents and you will be developing the agents in both in both sites in the mobile or in the road and in the browser and also in the server. So if we go to the on credits API, we are going to see the code more or less. We have the data source, we have the repositories for a non credits schema on credits credential definition. And this is a basic type or entity, the credential definition has the tags, has the issuer ID, has the type and some auditing columns, get that updated that and the value, which is is a lot of numbers to be honest. And I don't really understand the value, but we will see it later. And for the non credits schema, it has the name, it has a version, it has the attributes that are allowed to the in the credential, in the credentials that are issued to the to the holders. So in this case, Google see in the issuer what attributes we have the schema, it has the issuer ID and it has the created that and updated that some auditing and also the credential definitions. So this is for the non credits API, it has the same points, the schemas to get the screen up by ID to get all of the schemas. This is for debug purposes. Well, delete all this is, if you want to start from scratch, since this is a demo, we can also delete it to create a schema, there is a post to get the credential definition by the ID to create a credential definition also, which it has all of these values. And that's it. So very basic implementation for our favorifiable data registry, excluding the revocation registry. And for the issuer, this is a bit more complicated because the issuer has the hyper layer areas agent. So it has like the 300 lines. You can see it on the grid have better if you want. So it has all of these libraries. And we have the endpoints, which are based on the port. This demo works only in localhost. So this is hard coded. If you want this to be parametrized, then you will need to parametrize everything, the protocol and the host and also the port. And this is a function that initialize the agent, we will see this later. This is a function that gets all of the non credits modules, all of the modules for the areas, which includes the Asgard and also Indy. So we have a module for the connections. We have a module to handle credentials. We have a module for proofs, a module which here we specify the non credits registry that we saw before. This is the client in order to fetch the schemas and to be able to register the schemas. And on credits areas, this is for the implementation. There are multiple implementations. There is one for the reactive, I mean supported implementations. There is one for reactive and there is other for Node.js. And we will see later the one for the browser. But supported and official, there are only two implementations. And for the DIDs, we have the resolvers. We can resolve one in the SOF DID, PR DID and a EDID. In fact, we will not need this resolver, but it doesn't hurt. And for the wallet, we have the wireless in Asgard. And Asgard saves, in this case, saves the data in the unified system based on this wallet name and based on the wallet key, it will encrypt some data. And this function will be invoked later. And we have here the main function. So we're going to create an express application. We're going to implement some endpoints, which are basically every endpoint contains the method get. So this is to generate a link for an invitation. This is to get all of the connections, to get all of the proofs. This is to get a specific proof. This is to request a proof. And it has some parameters such as the mean age, the minimum age that it needs to have, that it needs to request. We'll see this in detail later. We have another endpoint, which is offer credential. This should be paused, but in order to ease the testing of this demo, then better to leave it as get. And this offer credential has the connection ID, the name, and the age. There is a default, but you can specify the properties of the credential. So the agent is initialized and there is a link secret created, and then we're creating a TID key method. And based on this TID key, we're creating a schema. And this schema is named, the name is personal info version 1.0, and it has two attributes, name and age. And then if the schema is not created, then the schema is created using the unknown credits. And the same happens for the credential definition is if the credential definition, or if there is, there are, there is no credential definition for this schema, then one is created using the unknown credits register. And then after all of this is created, then we can, we can start the server and start to interact with the server. So this is basically the agent part, which as you saw, we lacked as an issuer offering a credential and also as a verifier, you know, to simplify things. I don't know if there is any question. Now what I will do in the meantime, well, there are some questions because I don't want to deep, to go deep into the areas user interface because there is, there are so many files, because they contain the unknown credits assembly. Also, it contains the wallet, which there are many modules, so it will need a deeper explanation and I don't want to deep into this just yet. And many, many files and pages, but this mostly is react, but there is a huge part of areas. But we have the, the read me, we have a lot of hyperlayer areas in the browser with hyperlayer and on credits. So we have a getting started, which it has the components which we have seen before. The prerequisites will need an npm and not the yes version 18th. This is very, very important because if not, we will not be able to run as car. And the first step is just install the dependencies. So we will install the dependencies, which I have already installed, but make sure you do it. And we need to open three tabs. So the first tab will be for the areas user, which we will start, and this will make sure that we, that it will register the schemas in this case, already exist, the pencil definition already exist. This is the URL, the URI, for the not URL, the URI for the pencil definition ID, the ID, and the agent is listening on this port. So we will create another terminal for the non credits API. And this is listening on the the 3.5.5.4 port. And last, but the most important, the areas user interface, which this is Vite and it will run automatically in this port. Okay, so first we're going to see how this works. I will start it in an incognito window. And we have three fields. And this three fields are the ones that will need to be filled in every time that we want to interact with our agent. The default agent ID is agent ID, but we can change this to this case, David. And the agent label is how the name that will be transmitted to your connections. So this is a label that if you establish a connection with me, your label will appear to me. So you want to make sure that this is descriptive about who you are. And the agent password, which we can just say one, two, three, four, five, six. So this is not there is not a minimum amount of characters. I think it's three or four. And once we sign in sign in, then there is a mediator connection that is automatically created. And we can open another tab. And then I will say pose. And then there are two different agents in two different tabs. If we see, and if we go to the application, we see that there are two different wallets, wallet David and wallet Jose. And each wallet has three databases. One is for the config, which this is, this has the profile key with the key encrypted. And there is another for the keepers, which the same is encrypted with the key with the password that we have entered before getting into this screen. And there are the records and the records include the mediator routine, out of band record, the DIDs that were created, et cetera. So this is a database that will grow a lot. If we have a new credential, then it will appear in the records. If we create a new DID, then there will be a new keeper. I think the config will only have this profile key as far as I know. But we see where the data is stored. If I open right now another tab and I put as an agent ID Ivan, then if I open the application, then I will see three wallets. So this is basically multi tenant. You can have as many wallets as you want, but each of them will have different connections and different records. So imagine that we'll create, we'll put this side by side, because right now what we will do is create a connection between these two. So the one in the left will get the invitation URL and then the one at the right will accept it. And I want to have these DevTools in order to be able to explain what is happening. So right now this is Jose, where I will remove Ivan here. This is David that established a connection with Jose. And in this case, this is a mediator connection, but this is not a mediator connection. This is just a normal connection with another agent. And if I enter here into the connection from both sides, then there is a chat, chat with Jose and chat with David. This is the requester and this is the responder. So if I say hello, Jose, it will appear here. And all of this happens because there is a mediator. So if I enter again, hello, hello. I will show the DevTools and then I will enter in because I lost the WebSocket connection. But basically when I type a message, there is a request made to the mediator. And this request is encrypted using the connection that was established before. And this is the cipher there, the protected, the tag. In fact, we can see the protected. If we copy this chunk and then we go to JWT IO, we will answer here. This is base 64, this is not a JWT, but you get the idea. This is the recipients. These are the recipients and the encrypted key, which is then used. This is a lot of technical details, but at the end, what the data that is sent between two agents is this. It's the cipher test, which is the data encrypted, the protected, which is a base 64 in order to know how to interpret the message. This is useful for the mediator to know where to route it. And the tag is metadata. So this is the idea. And if I refresh the page here, and I enter in the data, then I will see that there is a WebSocket connection made to the mediators. There is some data, so if I from the left type another message, it will appear here. You see? And it has the same and it has the same format as if the data was sent. So it has the cipher test, the IV, the protected, and the tag. So this is the basic properties that at the end go from between two agents. This is for the basic message. So apart from this, so this is basic of this chat and you can deploy this whenever you want. And in fact, I have the same implementation here. This is a simple areas chat UI versus .app. It's the same. So you can try it out, test it, play around with this. This is based on what it's in the demo. It's based on the word that was done with this. So in order, so let's go with this. This is the one from David. So we have the connections here. I have one. We have the credentials, which I have known and the proofs. So what we're going to do now is invoking the issuer. Well, first of all, we need to get the connection, get a connection with the issuer, which we can do using the same point, invitation, because what we did before is to establish a connection between two agents. But we need to now establish a connection between an agent and an issuer. So from this agent that we accept the invitation from the issuer, and then you see that the label is different, issuer meetup areas, which is the same string that we had here at the top, issuer meetup areas. This is the same agent label. The wallet name is not set, only the agent label. So once we have established the connection, I will put this business code on the right, because right now we need to get all of the connections. There are many, many connections. So let's try to find the one that is recent. So this is from this is the one that we have just established. This is from 18th of July. So I will now try to offer a credential to this connection ID. And as we saw in the in the API, we can also establish a name. It's from where we put David and it's also instead of the default that it was there. So this will offer a credential to David. I don't know why this didn't work for a moment. There needs to be an error here. Not found the schema with your, okay, I think I deleted the other day. Let's try to spin it up again. Okay, this has a new credential definition ID. Now let's try with Jose in order to have a clean agent and only have one connection. So it's from meetup. Okay, now we're completed. Okay, so let's try to get the connections. Okay, so let's take this one and let's try to offer credential 28, offer the credential. Okay, so this means that the credential has been offered and then if we check here, offer sent. Okay, and here we have the credential. So now I don't think this was from another. Okay, perfect. So we have too many tabs. One moment. Let's try again. David, okay. Let's try with other. Okay, now we don't have any invitation. Let's accept invitation from the issuer. Okay, now it's completed. Now we go to the issuer, then get all of the connections and we see that we try to get the last one. In this case, then let's offer a credential to that. The credential has been, in this case, you can see that the credential state from the issuer is offer sent. So it hasn't waited until the credential has been offered and stored by the agent. And then we go to the credentials. Right now we have, we saw this credential done. And if we go to the credential, then we will see the scheme ID, the credential definition, the name, and the age. If I change and create another credential, offer another credential to the same, to the same connection ID, then I will have here two credentials. This is a request, but now it's done. The two credentials are done. This is sorted by the date of the creation. So if we go to the last one, then we will see that the credential contains different data. The scheme ID and credential definition ID is the same, but the data for the age is different. So try now. And this data is, we open the DevTools. This is the wallet for the AB2. If we open the DevTools in the records, we're going to be able to find credential records. And this is the credential record with all the values, the credentials, et cetera. There is metadata. So this is at the end what really means having a credential. Now there is the verifier who needs to verify the credential. And if we go to the Visual Studio Code and to the agent, there is a request proof which we saw earlier. And the request proof has the connection ID as a parameter and also the minimum age. The minimum age by default is 18th, but we can specify any minimum age. So let's go, let's try this also. So let's request a proof instead of offer credential. Let's invoke the request proof and the minimum age will be 25, for example. So if we go to the proofs, the presentation has been sent and then the status is done. So and this all has been done through the WebSocket and the protocol that Darius has. If we refresh and see the the mediator messages, we will be able to see the message that has been sent. But this is not possible because the data is encrypted, so it's very hard to debug. So in case, so right now since I have two credentials, one with 28 and the other with 30, 8 of 8, then the presentation is sent and everything works. If I try 29, then it will also work, presentation sent. But if I try with 33, then the presentation will be requested, but it will fail in the client, in the browser, in this case. It will say that the predicate is not certified. So this is basically the reason. And the issuer, sorry, the verifier will not get this proof. If we go to the endpoint to get the proofs, which is slash proofs, and we go to Visual Studio Code in order to sit in a pretty, with a pretty format, then we have this proof that has been done and this verifier is true. We have this proof that the status that the request has been sent, and there is not, and it's verified, so it hasn't been verified. And it has another presentation, which I think is the one from 29th, that we requested that it is at least 29th, yes, and this is done. So this is the demo that I wanted to show. There's more technical details to show, but if you have any questions, please feel free to feel free to write any questions in the chat and we will see it. Yeah, Dave, go ahead. Yeah, for at least messaging and connections, would this interoperate with Acapai or AFJ? With AFJ, yes, because this is what has been used for the issuer. So at the end, the same libraries are being used. What has been built is a wallet, which these are the files for the wallet, but if you see the browser storage service, we'll store the data in indexdb, so it's this one, the indexdb storage service, so it's interoperable. With AFJ, I'm not proficient in Acapai, so I haven't used Acapai more than a proof of concept and trying to spin it up, but with AFJ for sure 100% is interoperable. And as long as Acapai follows the standard, I think that it's interoperable. Yeah, I'm more interested in the AFJ compatibility. You could always try running traction to get you an Acapai up and running. Traction? What is that? That's an open source project by the province of British Columbia, which gives you an issuer and verifier that's multi-tenant. I can put the link into the chat. I guess while I've got you here, I'm looking at building a verifiable data registry using Hyperledger BSU, so it'd be Ethereum compatible. So I think where you're writing to the ledger, you're actually using database calls. So if I could fork your code and then add in a piece to talk to, let's say, a BSU network, is that correct? Would that be the way to do it? Well, for production, you will need more security, let's say in the anonymous API. But yeah, it's like that, so you will need, it depends on your use case, but usually you want the credential definition to be public in order to fetch a credential definition and to see the data. And what you will need to do is instead of writing to the database, then write to Ethereum in this case, using BSU. The same applies for Hyperledger Fabric. If you want to store it in Hyperledger Fabric, then you will need to invoke the chain code and the smart contract and that's it. So, but you will need to take care of the security. Okay, so where you're using sort of type ORM database calls, I could just replace that with the blockchain specific, got it. Thanks, this looks great, I gotta say. This is really good, good work. Yeah, so we put in the pieces together, but it's not common to see something like this. So this is what I wanted to, to sell it in order to see if there is, if there are more ideas of the community and to exchange ideas, basically. But yeah, I mean, we're not using this own production right now because the browser has a lot of limitations, as I stated earlier. So, because if you, I don't know, you are on the desktop and then suddenly you switch to the mobile and then you have different data. So I think this is something that needs to be solved with this implementation, but this is just the start, I guess. Okay. And then you will need to do something like this and run on credits registry for the clients in order to go to your API. Okay. So this is what you need to, and maybe this, an on credits registry will need to, and this is something you need to decide, you will need to go to the Ethereum directly or to go to an intermediate API. That is up to you. So I don't know if there is any questions or things you want to discuss or work here. There's a question for you, Dave. Maybe you want to expand on that. Yeah. So there's some concerns with Indy right now in the fact there aren't many maintainers and there's a lot of work to be done with it. So there's a lot of work on alternative VDRs. And so I'm working with a group at Veridid and we're creating an Ethereum-based one, so an Ethereum private network. And so your tool here would be great for us to use for building that and for testing it out. So this is really complementary to what we're doing. I really appreciate the work you've done. Thanks. In fact, maybe we can have a tour later, but this is something very similar. In fact, I needed to remove the fabric code in order to make this demo because I didn't want to get the fabric involved. But that is the right way to do it, to be honest. Because with Anoncred, with Anoncred's project, I think Indy doesn't make sense to use it. Yeah. Fabric would be really useful too. I'm doing a couple of projects where I was trying to use, let's say, something like the Sovereign Network. But Fabric just isn't really good at reaching out and doing things that are off-chain. So if you do the credentials or the schemas and the credential deaths on-chain, then it makes life a lot easier. And I thought that would have to be done by adding to, let's say, the nodes, the node code to handle that, but putting it right into the chain itself certainly solves all those things. Yeah, I'd be interested in following up on what you've got going there. Yeah. Well, we can check later, but I think we're in the same page on Anoncred and Indy. I didn't know that Indy was. There were concerns about Indy. Yeah, because the only project that Plenum is being used in is Indy. So there's a whole Indy layer plus the Hyperledger Plenum. That's a lot for a small group of people to take on. So I think it just makes more sense to move to a different blockchain. Now, we can still have Indy. We don't have to get rid of it, but alternatives would be very useful. Yeah, but there is a lot of work to be done, or there is a lot of effort for Indy just to restore a few credentials, a few schemas and credentials definition. I think, I don't know if this is used for more because I think you can register the IDs, but I don't know if you saw EPC, the European Blockchain Services, which they have a lot of APIs. So it's another approach that having multiple APIs in order to register the IDs and to add attributes to the IDs versus having a network that handles all of that. If it's done properly, then I think a network is great, but I think the complexity is not about Indy. Yes. Of running a node, I mean a blockchain network, if you have already Hyperledger network running already. So it would be good to plug what Indy stores in a smart contract and then being able to deploy it in a Hyperledger network or a Hyperledger visual in order to have kind of the same functionalities. Because there are a lot of companies that are right now proficient in Hyperledger Fabripa, nothing Indy, and this will accelerate the adoption in the SSI a lot. Yeah, I've tried to get the two communities together, not I haven't tried too hard. But yeah, there's so much specialization in each that you don't have a lot of crossover and so there hasn't been a lot of effort to bind the two. But it's really important because if you need to check the credential of someone who works at a different organization than yours, then all of a sudden you have to trust, you know, without having something like Verify the Credential, you have to trust. So you have to trust that someone or another company is an engineer or a lawyer or an accountant based on the role that they've been assigned. So having a non-creds, then also you can verify from a third party, that's fantastic. There, you can have multiple implementations and registers from for a non-creds. I mean, it doesn't need to, because if we see the code and if we checked the agent, well, this is the non-creds registry for the browser, which uses access. If we go to the ARIES provider, I don't want to go deep into this, into the code. We can go now into the non-creds REST implementation, which I think is more useful. So if we have here, we have here the non-creds, the non-creds module and we will have multiple registers that HyperLayer ARIES will try in order to get the schema. So you can have a registry that is from one company, which is in HyperLayer, which is in Ethereum with HyperLayer Vesu, you can have another in HyperLayer Fabric, you can have another that is an API, so it's, I think there is a lot of, there is room for interoperability and improvement here. Yes. Yeah, this is where a resolver could be used. Yeah, which is this one, no, the registers right now, because the resolver I think is for more for the IDs, so. So more or less, this is it, this is the demo, I don't know if you want to type in in a specific area of the TypeScript of the REST user interface. It's very similar to the agent, so I think it will, I will bore people if we go through its file. What I can show is the. Oh, I've got a question about the invitation you use, is that like a classic connection 1.0 or is that out of band invitation? Out of band. This is out of band with the, with the alias, multi-use invitation in order to be able to, to reduce the invitation and the auto set. Okay. The same, the same in the, I think the same in the browser, in the browser there is a connections, so invitation you are there again. Agent out of band create invitation. This is not, this cannot be used multiple. Again, this is the screen for the connection. So basically you will get the invitation you are there, you can select your code here and in other stuff you can accept it. I think we can do it now. And are you supporting attachments on the out of band invitation? What the AFJ supports right now. So the only change that we did, and this is what is great about this. So the key is here in the, in the agent areas provider. So the only thing that changes from the, from an agent running on the server to an agent running in the browser is this an on credits RS, which was, we saw before, there are two main implementations and this is the other implementation of the browser and on credits, which is a class that interacts with the web assembly. And the other part is the wallet. This is the wallet, the browser wallet model. So everything else is what the AFJ supports. We haven't, we haven't modified anything that we want. This will be another project. Okay. Yeah. I gave you a link to traction, but traction uses out of band 1.0 and AFJ uses 1.1. So they're, they're not compatible currently. Yeah. I see. I see this. So this, this traction. Yeah. Traction is a, it's an application that sits on top of that. And it handles multiple tenants and each tenant can have its own application with a web hooks in it. It's interesting. We had another project that we needed that also to have multiple tenants and we did it with AFJ this case. So, really interesting. Interesting. So you have these multiple tenants, the web hooks are part of the traction, no? Part of the plugins. You can create your own ACAPI plugin or basically it's ACAPI tenant and then you register it with the multi-tenancy thing. So there's, there's a core piece of ACAPI that's used for a tenant and then based on certain actions it'll then call out to your piece and then you respond back through the web hook. Interesting. And only ACAPI is used. So there is not the AFJ. Yeah. This is a successor to, there used to be a thing called the business partner agent, BPA. Yeah. But this is a multi-tenant version of the BPA and they've, they took the opportunity to refactor some of the code. So what you're saying is that the AFJ client is not compatible with the protocols that ACAPI supports? No. Yeah. They should be able to, I think they just need to update the version of ACAPI they're using. It's been known for a while that the out-of-band 1.0 and 1.1 problem has been a problem getting ACAPI and AFJ talking to each other. Yeah. Well, I hope they, it's, it gets solved, to be honest. But I mean, looking at ACAPI, I don't mean to to be negative, but it has a lot of issues created and I don't know about the, about that. Well, I think a lot of that is because a lot of people use it. Yeah, I can also, but I don't know. I don't know if AFJ is, because for mobile then you don't have any other option than to use AFJ. Yeah. AFJ is currently the most advanced in mobile. That's for sure. So, I mean, if you are developing an agent and you think you want to use the same language, maybe because if not, if you go with ACAPI then you will need to go to AFJ for the mobile. And then I think compatibility is starting to happen, as you stated. So, I don't know what is the best way to handle this, but this is something that they notice. Yeah, it's certainly the two teams work on interoperability. I'm in Canada and ACAPI is looked on very favorably by the governments. They like the tenant model that they have, where each tenant can have their own application that is called by the webhooks. The BPA didn't allow for multi-tenancy. So this interaction, they have something called an innkeeper and the innkeeper allows you to create the multiple tenants. And then there's a tenant interface where you go in and as an individual tenant you run it. And what they're trying to do, they have a model where they have the innkeeper is an endorser to the ledger. So the innkeeper is allowed to write to the ledger, but the individual tenants are not. And so the tenants have to use an endorser workflow where they submit a transaction to the innkeeper to get it approved. And there can be an automatic approval or there could be a set of rules in place with that. Well, so it's like a platform in order to manage different entities. So let's say you're a government and you have multiple ministries then you may want to control what schemas are written so that there's, to make sure that there's interoperability in Canada, the different provinces will all be doing things like driver's licenses and health cards. And they want to make sure that there's a compatibility between the schema, the credential definitions will be different. But if it's the same at the schema level, then that allows a higher level of verification. Yeah, something similar to what the EPC is doing, so a necessary ecosystem. No, a necessary ecosystem, more or less, that handles everything. That makes sense. I would try it out, but it looks very, very good. And this, well, I don't know how you will, well, the browser part doesn't really work for you, I think. Oh, for this, this is a whole different use case. The browser piece that you have works really well for what I'm trying to do. I'm not with a government. So for businesses like a small business, certainly for other types of devices, so not a mobile phone, but let's say a tablet that's not connected up or a computer. So if someone doesn't own a phone, we also have a problem with this. If the government tries to issue credentials, and people don't own a phone, then they can't use it. But if they could go to, let's say, a public library or somewhere where they can get access to a browser, all of a sudden they can send off the proof requests or do verifications or do connections, like all of those types of things that someone could do with a phone. But for someone who doesn't have that, you're now offering that type of capability. And so that's really good for accessibility. Yeah. Yeah, I think that eventually this will need to be integrated into the address from with JavaScript. Because the accessibility is a huge, huge problem right now. As you said, not having a mobile, having an application, and the developer team needs to the development team needs to publish this application, go through the app store, policies, publish it to the app store, this is hell. In order to have some connections and some credentials. Let's see, I don't know if to make this library open source. Right now, some of you are interested and I will for sure think about that and publish it and maybe we can get some traction for this. If you plan to use it in production or in a proof concept to start with. Okay. So, well, for the, this is the project for the non credits, it's pretty much, it's one file, basically, for this, there are some macros, but basically, and this was made also by, I think it was very many more, but basically an interface to the actual and on credits code. And you just declare this is an annotation wasn't been seen, and this is the fun, the function that will be published or yes, you just build it cargo build. And then what there are a bunch of warnings here. But this is if you want to change or add a feature to the non credits, which I don't think that you will need it because unless you want to implement functions that are not for the holder, that are for the issuer and the verifier, which is something that they haven't thought about because usually the one that is in the browser is a is the holder, but I don't know what happened that imagine that you go to the to a concert. You want to verify, verify your credential from order, but you don't have a mobile. So I think that holder and verifiers have a lot of a lot in common. So maybe there's something that will need to be added. But as I said before, then you can go to this case software and on credits errors once, and then you can fork it and implement your own functions. But it has the claims, the credence of request, it has also the credence of target attributes. It has a lot of functions that are here. I didn't know about REST until now, so probably some code can be optimized and better, but that is basically the approach into using an on credits from the browser. And once we build it, it's in the target here. I think the on credits dot wasp. This is the v file, it's to be binary, but you get the idea. And then this is imported. So if we, this is all copied to the research studio code to the folder. And this is the folder that needs to be updated. So if you do the cargo build, you need to find these files in the directory of the REST project, of the on credits project, and then paste it here. And then you just restart the browser. That's it. You can modify or add more functions. And if you go to the browser on credits class, which implemented the non credits interface for most functions, basically for the functions that are being used for the wallet. This, for example, is not being used for the wallet, so it throws an error, but create a schema, not implemented, process credence. So this is a basic example of how to use it. You just invoke the function. So if we get this function and search it into the project, then this is the JS name that we talked about, an on credits process credence has these properties and then that's it. So this is how I implemented it. Just go function by function, see how this is invoked, because there is another implementation. So this is the Wasp implementation, but there is another implementation for C++ or C. So this is the, for example, the wall to a credential. And this is another way of declaring that a function is public. But you get the, you copy the function that you want to implement and you just implement it in using these decorators and types that are valid for our assembly. For example, if we try to find process credential, well, this is not the one, but maybe presentation, well, an on credits, for example, an on credits, an on credits, create presentation, if these are the properties, if we go here to an on credits, create presentation in the Wasp, then you can see here that the press record is an object handle and in these cases are your size. The credentials is JS value in the Wasp. So you have a, and this is FFI list. So you have this difference that are the hardest to be done is in order to advance with this implementation. But at least it was successful and also these object handles are used in order to free the memory between the implementation and the Node.js, for example, and this is the same handle in the same way in Wasp. So there is no, there are no memory leaks in this case, which is very good for the browser. And for mobiles that run the browser and try to get into the website and don't have as much as much memory as others. So, well, you're going to have to comment about this, you have the repositories of if you took any issue or propose some more functions and I don't have much else to say. You can inspect the code. There are a lot of things in the code and a lot of details in the code that is hard to cover in a meetup, in a demo. So, well, unless you have any questions, I think we can close or discuss for the next 30 minutes things that you have problems or you have questions about. Okay, so I guess that this is it. So thank you everyone for coming and I will be watching the YouTube comments in case anyone has a question or you can contact me on Discord for any question. So thank you for coming until the end and see you in the next one. Have a good evening Matej. Thank you. Thanks, David.