 OK, I see. So let's jump right in. Hi, everyone. My name is Mitri from BigchainDB. There is a genie from JoLocom. Myself, I'm working on BigchainDB interplanetary database, also something called Ocean Protocol, and IntelliJR. And all of this combines into something we call a decentralized application stack. We are trying to create an interoperability space where data, smart contracts, and logic all unite. And this is one of the examples that we'll show today. It's called a decentralized data gateway for Ethereum. What it is? Should be clear. Cool. So we're in a space that becomes a bit scary. This is from 2005, when many companies started to realize data becomes a new oil. AI just doesn't need better models. It just needs more data. It's very data hungry. If you have a lot of data, you've got your mode. You can play around. You can create better models, more accuracy, more money. I think we all are aware of that. That takes a lot of scary future perspectives. So we're in a situation where our data is in somebody else's silos. We don't really own and control it. We don't really see what's happening. But it's actually stuff that's about us, about our personal, private life. And other people play around with it. And that makes me a bit sad. So this is how they typically do it. We are very happy. We get a little honeypot called applications. We run them. That data gets stored somewhere and gets upsell. Now, what you'll see is you have a lot of versions of yourself out there. You don't really know where they are, how they're rippled through. In Europe, there is something like the right to be forgotten. Very difficult to implement if you don't know where your data is. You cannot really turn off the switch. And of course, of all this revenue that's happening downstream, you don't really see much. You only see the ads coming up. So one of these ideas that's been very well explored in this space is data sovereignty. Own, control your own data. For that, you need an ownership layer. Blockchain is applicable to that. That's what we've been doing with BigChainDB for a while now. It's creating something like decentralized data where you own and control your data. You set the rights on your claims, access control, all of that. So this gives us a land of self sovereignty where everybody's happy, your unicorns can play around. But more importantly, you know where your data is. And you can revoke access or grant access. And you have problems. You can see what's happening with your data. So how we feel it should be is that you should bring your data to the service. And that service should ask you to consume your data. And you should be able to revoke access when needed. So let me go back a bit. We distinguish in this prototype we've built together with JoLocom, we distinguish two types of data. The private data, personal, off-chain, stored in local storage. But also as well, public claims on a decentralized public net like IPDB, the interplanetary database. And that's basically a database where it's a NoSQL store with decentralized control. There's no single admin. Currently it's in a federated setting where you have caretakers for future decentralization of the internet, like internet archive and monastery. I think there's like 17 of those. And they host a big data network. It looks and feels like a database which is actually decentralized. What you can put on there is any kind of public verifiable claims. Or maybe standards like the decentralized identity foundation is proposing. This is the public data. But JoLocom focuses mostly on is a private data. And then you can create an access control mechanism using a gateway and claims on top of a database. The benefits are quite clear. The fact is that you know where your data is. That you can revoke access. You can grant access. And if needed, you can share in revenue on upstream or downstream services. So what we've built for our DEFCOM meetup here is an interface that looks like this. We have JoLocom, a JoLocom gateway which manages the resource access. And Eugenia will talk much more about that further. About two parts. Not only the private data, think you port and such, but also about public claims that you can retrieve from either B-ChainDB, Swarm, et cetera. For this, we focus mostly on the apps. Imagine you see a smart contract. And it's kind of like hashy and not always UI friendly. But augmenting it with the data that you can fetch through this gateway gives you an enrichment of the data layer. What does it contain? Maybe some private personal data if you yourself that you inject into the smart contract. But also a description. And what you can grab from the public claims is maybe an audit. Is this scammy? Is it not? Has people been testing it? What's the current version? So applying this to smart contracts gives you a bit more contextual information. In a separate project, we're working on something called Ocean that allows data exchange between silos. But that's something that's a different project. I think, Jeannie, it's up to you now. Hello. So can you hear me? Nope. Wait. Yeah? OK, there we go. So to give a little bit of context and to paint a bigger picture, I'd briefly generally describe what we build at Yellowcom, the identity gateway. So generally speaking, it's a personal server. It's intended to be modular and lean. And it stores and curates access to your personal information, to user data. And more particularly, basically, we're talking about attributes. Attributes are effectively things about you, your name, second name, phone number, email address, mostly things you need to interact with online services, perhaps also things you need for some KYC scenarios. We also store verifications. So verifications, in the classical sense, signed messages by external parties that this is indeed his email address. So for example, if you sign in with Airbnb, they check your email address. They might give you a verification. You store it. Next time you sign up with another service, maybe you don't have to go through the whole process again. There's a lot of effort going on verifications now. So there's the W3C working group, five-day unfocused telepresented. A lot about it on Monday, I think. Oh, sorry, on the first day of DevCon. So this is definitely a very exciting field. The gateway also does access rights management. So it basically has an internal database of what entities are allowed to view what attributes. And those can be retrieved. Those can be revoked as well. So in case some service wants to get access to your email address, you'll have to go through your gateway. And if your gateway has the appropriate permissions, then it might grant the access. And it also has identity stores. So we envision a scenario where more people will share one gateway. So we allow multiple users to register on one gateway up to, for example, 10. You can register, perhaps, if you have an invitation code from the person who set up the gateway. So the use case for this would be mostly a bunch of friends just using one gateway together because they trust each other. And in order to be a little bit more resource-efficient, save some money. So this is kind of in broad strokes what we're building. At the moment, a lot of these things are stored inside the gateway. So locally, there's an abstraction layer on top of storage so that some of those things could be swapped from internal local databases to perhaps some of these solutions. Obviously, when it makes sense. So attributes which might need to be private, might need to be public, might need to be easily. So the access rights might need to be easily configurable. Maybe not all of these storage solutions make sense because it's quite difficult. But for example, application data, which can be large, and some of it perhaps even public, might be stored in one of these things. So I need to speed up a little bit. So the general idea behind the collaboration we have is we want to create a layer of metadata related to Ethereum smart contracts and store that metadata on the big chain DB. So the idea behind this is that when you interact with a smart contract, you might be able to retrieve some of that metadata from big chain DB in order to enhance the user experience or perhaps to provide for a safer interaction. We had a short brainstorming session about what kind of metadata we would like to store. So this is a very, so this is an initial design. Things will probably change and become more robust as time goes on. But the claims that we decided would make sense to store on big chain DB. The first one would be the ownership claim. So this is a claim posted by the person who deployed the contract. So this claim contains, for example, his Ethereum key, big chain DB key, yellowcomb identity, all of them assigned to the corresponding private keys. And it might also contain a field, for example, his email address in case you want to contact him or his home address in case he's very brave. And when you interact with this smart contract later point in time, you can retrieve this claim, see that, okay, this is the person that deployed the contract and these are his alternative identities and this is a way to reach him out. Besides that, we also have functionality claims. So this is fairly straightforward. A functionality claim, it's simply a claim that provides a user-friendly name for the contract, a user-friendly description. So for example, this contract does this and that. And the list of the methods that the contract has and also a nice description of those methods. So at later point in time, when you interact with the smart contract, this can be retrieved, parsed, and then displayed to the user in a nice way. We have reviews and endorsements. At the moment, these are fairly basic. So these are external parties, basically, saying I've interacted with this contract and it's okay. So it's kind of like an upvote or a thumb up. This could be a lot more complex and robust and I'll mention this if I have time at a later slide. And the last ones are security audits, which are fairly tricky to do, actually. These are either external entities, normal people, corporations, basically performing a security audit on a smart contract and signing a statement that this contract is secure. There's a lot of things to be taken into consideration, so you can't just say that the contract is secure. The state of the contract might matter. If it proxies calls to other contracts, that might be relevant. So overall, this is a little bit more of an involved case. So if the demo gods are with me, I might show a quick example of an interaction. Let me see. So I created this mock website. It's a little Ethereum. I hope the name isn't taken and I'm not gonna get sued or something, but the general idea is it's a website that allows you to place bets on outcomes of games. So we can log in first and when we log in, we get to log in with our YOLOCOM identity. So the things that the service requires from me at the moment is my email address and also my Ethereum address. So this very straightforward, I'm just gonna go over it. If I click accept, I hopefully get redirected back to the website, but now I'm logged in. Now. Okay, there we go. And this allows me to place a bet on a chess game that happened in September this year. So I'll place a bet on Levon because I Googled the results in Anohi 1. So if I place the bet, an Ethereum transaction is triggered. So this is an API called to the identity gateway, which then renders this consent screen to the user. And at this point in time, we fetch metadata from BigchainDB. So we fetch things like a human readable name and description of the smart contract. I don't know if you can read it, but it says a fair betting contract on top of the Ethereum blockchain. We pull a small description of the function that we're about to trigger, which is it allows users to bet on the outcomes of sports games. And then we also have a verified owner of the smart contract. So this is just the identity I used to deploy this local test contract. So normally it would look probably different. And we also have reviews, which I mentioned that basically the funds are basically people that use it and said, okay, this works as I want it to work. So if I confirm, no risk, no fun, I get redirected back to the service provider where, so this runs on TestRPC locally. This is why things are so snappy. Get redirected back to TestRPC where kind of the whole interaction is complete. So we've retrieved data from BigchainDB to provide a better user experience and also a more secure user experience in a way so that users can be a little bit more sure about what contract they're interacting with. So this was a fairly weak demo and there's a lot of things that still need to be done. Overall, next steps were represented now as an MVP proof of concept. The next steps, of course, we need further and better definition of the claims. So perhaps the reviewed claims, which I mentioned where it just kind of thumbs up, people signing a message that I've interacted with this contract and it's fine. Perhaps we could have a message there, a comment you could leave, perhaps say I've interacted with this particular function of the smart contract because maybe you don't interact with everything. So that could be improved. We could have historical or version records of claims. So BigchainDB allows you to step back through time and see how particular assets or metadata evolved through time. So perhaps we can see that the current security audit for the contract says that it's a secure contract. You maybe go back through the revision history at one point in time, it was not secure. You can maybe see how long did it take for it to be fixed. How often was it insecure? How often is it audited? So having this kind of ability to go back in time and check the reputation of the contract throughout history could be important for end users. Of course, we would like to have support for more complex smart contracts. So this also basically includes contracts that use libraries or rely on other smart contracts, proxy requests to other smart contracts. For example, if we audit one smart contract, the given point in time, we say this smart contract insecure, but then it proxies the request to another smart contract and has a function which allows to swap that one. It could be that at a later point in time that contract is no longer secure or it's malicious or has undefined behavior. So this is another thing we want to focus on. And the last thing we want to focus on is perhaps standards and community input. So it would be nice that we don't build our own silent solution and time. Thank you very much for your attention. Thank you. Thank you.