 All right, so let's get started. So the name of the presentation is a blockchain-enabled decentralized social network, which might be ambitious, but to start with, I think the best start is probably to highlight the problem that we're facing. Let's see, perfect. So the problem is probably familiar to a lot of people here, which is the problem of centralized identities and what it basically means. So we have a couple of bullet points, kind of. It's more than this, and the topic is kind of subjective, but in a nutshell, it's basically an identity that you don't own. It's an identity that's provided to you by someone else, be that Facebook, be that Google. So it's the identity that you don't create yourself. It's the identity that you can't revoke yourself. It's the identity that can be taken away from you or censored, or among other things. So this type of identity, as mentioned, is rather vulnerable to censorship, which basically means if Facebook doesn't like you, if any identity provider doesn't like you, they can just block you or delete you, and there's pretty much nothing, most of the time, you can do about it. Another problem is that there's no real data ownership, as in all of your data is stored on the identity provider's servers. So if you say I want to delete a Facebook photo, you have to basically put your trust into Facebook, that they will indeed delete that photo and that they are not storing it somewhere. So I think this is straightforward. Trust is required, so mostly trust towards your identity provider. So you really have to trust your identity provider. You have to make sure that they don't do anything with your data, that they don't claim, or that they claim they're not doing something. You cannot be sure about these things. And another problem is limited portability. So in a nutshell, a lot of times, some identity providers will not allow you to export your data. A simple example would be, again, Facebook. Well, Facebook has a certain export profile picture, but if you'd like to fully migrate from one service to another, a lot of times you're not able to get all of your data from them. It's a bit difficult to migrate fully. So, and this is how most identity providers work in a nutshell. This being the users and that being the identity provider which provides them with the identities and amongst other things hosts their files. And at least this is kind of like a very conventional, hyper centralized system. And the solution to that is a word that's probably mentioned a lot all over the place. It's self sovereign identity, which in a nutshell basically means that you have control over your identity. So you don't rely on any external service to create, delete or manage your identity. You can do it yourself when authenticated against some websites on the internet. You can authenticate with your identity. It's quite a vague generic formulation, but and you don't really have to rely on some third party to handle this for you. And again, no external service can revoke or censor your identity. And the user should be able to always access their data, which is I think a very important point. So the data should ideally be always on the user side rather than on some identity providers website. And it should be portable and not locked down to one domain or on one location. So this is, this transposes directly to what we mentioned before. And this, there's a couple of ways to do self sovereign identity. There's probably been concepts for a while. One of the ways is heavily promoted by a development team at MIT led by Kim Bernsley, which is the solid spec or the social linked data specification. It relies on a couple of factors, which we'll get into in a second. So this is ideally how a decentralized identity system would look like where every owner, every user stores their files locally, and also their identity locally. This symbol here is actually a server, a personal server that they're running. This particular program stands for the solid servers. It's a server, it's a server again, developed by the solid team. So to fully understand the stack, we need to kind of get the grasp of the basic building blocks. The very basic building block is a web ID, which is quite straightforward. It's an HTTP URI which describes an agent or an entity. So this is basically your login. This is your identity in a nutshell. So a couple of valid web IDs, for example, would be eugenia.webID.telecom.de profile card. Me, that's a bit irrelevant, but another one would be, for example, Kim Bernsley's web ID, which would be, I'm not gonna read it, but this is what it is. So there's a different, there's a bit of distinction here. The first one is actually provided by identity provider, but that's something we can talk about in a bit. So this HTTP URI needs to resolve to a profile document. It needs to resolve to a document that basically describes who you are and perhaps some primitive amounts of that and also link to some other documents that further describe you. And those other documents can then have some specific access control rules associated with them. So this part has to be public, so it can be accessed by anyone to get some primitive information about you and then the further exploration can be restricted by access control rules. And then it's a unique identifier due to the nature of how domain names work. So, no other entity would have the same web ID as you. You can have different web IDs in the same domain names or subdomains that could be perfectly valid, but it is in a naturally unique identifier. So the web ID really defines where your identity is stored. It basically says that there's this URI which describes you and that's where the entry points to your identity should be stored. Now, it doesn't really define how your data should be formatted, it doesn't really define anything, it only says it is there. In a system like this where every agent hosts their own identity, it is imperative to have interoperability. So if an agent wants to retrieve some data from you, he should know how you store your data, he should be able to parse it, read it and make sense of it. And if a service provider wants to do the same, he should be able to do the same thing. So basically they have to speak the same language in a nutshell, they all have to understand each other. And the solution to this comes pretty natural which is actually linked data or linked data, which you can actually see one example of linked data here. Linked data is a way of formulating statements or pieces of information using triples. So a triple has a subject that predicated an object and it defines something. So in this particular case it basically says that I know Joachim who's somewhere there. There's a lot of people here. So this is the general idea, you know linked data needs to be used to, should be used to describe you. So your profile ideally should be stored in RDF or yeah, in a different serialization for a messages turtle or RDF XML, but it should be very linked data. It's the first point. And then there's a second point that ACL files, so access control lists. So files that define who is allowed to do what with some files that you store in your system are also very linked data. And linked data in tandem with web ID simply makes sense because linked data, the next link that is addressing entities by a certain URI. So every agent, every entity is defined by a URI. Predicates are also defined by URI, they're clearly defined in a number of ontologies or predicates. So if you take linked data and plug in the web ID which usually URI for identify users, that works. It's an easy way to show social relationships like this because now a parser could see this statement and then could jump through Joachim's card which is also valid linked data, parse that and jump on and on and on and make meaningful, perhaps extract some meaningful information out of that. So exactly that's basically the stack that is defined by social linked data or solid. So they use RDF to store your file, to store your, to serialize the information. They use web IDs to point and use those identity files for entities in the system. They use access control lists to manage authorization which basically is just another RDF file that says that this and this and these agents are allowed to do this and this and these things on these files. Everything being evaluated URI. A good thing that comes out of solid is the elimination of a network effect. So in the conventional systems we have the so-called network effect where everyone is using a social network. That's the reason why other people are using it as well. You know, why do you use WhatsApp and not Signal because everyone uses WhatsApp and so on and so forth or Facebook or the examples are endless. Solid envisions of world where every user has their data on their side in a predefined format and applications can simply hook into that data. So applications can simply request access to your server, to your user space, get the data and do some computations on that or perhaps display it in a graph or perhaps it depends on the application really it's really application specific. And as a result of that you have an ecosystem where everyone has their identities which they build over time. They want identity and then a bunch of applications that they can use to manage different areas and aspects of their identity. And different functionality comes from different apps so you don't have to use this big monoliths anymore. And then we talk about YoloCon now, so that's us. How do we fit in into this picture and we also do a very short demonstration if the internet allows us to do so. So first of all we are a tool that allows you to modify, edit your WebID profile. So we're a tool to visualize your WebID profile to modify this user space, a data space to manage it in a meaningful and easy way. And we also allow for certain interactions. So I think it'll be a bit clearer if we just do a very quick demo of that. So here we have the very primitive demo where we have this one node. So this is, Eugene, this basically is my node. This renders the files on the server that I own. So the application basically gets access to my data and renders it. So at the moment I'm a simple node which doesn't really do anything, doesn't really have any connection. So we can do things like, obviously we can look at my profile where there's some primitive information. So this would be my WebID, my email and that's about it, it's a very sort of blank profile. We can do things like link to other valid WebID profiles. So I think we'll link to probably two or three to really explain the interoperability aspect. So first of one will be probably Joachim. So this is Joachim's WebID, if I can just spell it, Joachim will go to Joachim.com.com. You can put that on me. So we can click the link to Joachim. So this basically gets information from Joachim's personal server. And in this case, this is hosted on a server owned by Joachim for development purposes. It's just easier this way. But I'll show two examples with people who self-host their identities. So this just gets access to Joachim's data. To whatever data Joachim made public to me. And if I go to Joachim's profile, we can see that we can explore his data where he has a number of connections to a lot of other entities. So all of this being other people, some of them self-hosting, some of them posting their data as an identity provider. And then some general knows that he created some pieces of information he's uploaded to his servers. If I navigate back to me, so this is the example of linking to someone who's on a server that we host. Because it's easier for us to do it so for development reasons. But we can, for example, a good example would be Kim Berners-Lee. So this is his card that he made public online. And you can also see the third location of this card. So all of his information, information about him is basically encoded here. So it's his location, phone number and so on and so forth. So if we take this URI and link to it. It's important. We send a request to his personal server to get some data and whatever data he made public comes back to us. And we obviously can render some of that data in. So this is what we've kind of extracted from his profile file. So this is quite a simple computation, really. It's nothing crazy. And the last example we have another identity that's hosted on a freedom box right there. So here's the thing that kind of has a circle around it. It's a personal server. It's supposed to act as a little personal server, rather solid server on it. So if I connect to it, I don't have this nice little feature. It's really not that impressive. But if you send a GET request, an HTTP request, if you get data from the freedom box, it spins, the little light spins. So you might see the moment when I request it, there's the data that's stored on the freedom box from whoever owns it. So I think the name for this one would be holocom.freedombox.me. Oh, I mistaked it. It'll allow me again, unless I do something. Last second. 2222. The server is down. Thank you, demo gods. But... Maybe with the cables there, perhaps that is the reason? Yeah. I'm not sure if it's worth recovering it now, but there's an identity on there. Trust me, when you access it, the light blinks. It's the coolest thing ever. It's really annoying, though. Yeah, but... The camera's not supposed to work, and yours always did, so... Ideal demo. But yeah, sorry, maybe we can get it working a bit later. We can show it to you. People want to see things, please. But this is what it basically does in a nutshell. So you can connect to other people who have their identities in different locations. So a very extreme example would be the freedom box, which is a server that is self-hosted. It has a number of privacy-related functionality features on it. It's developed by the Freedom Box Foundation. You could host your identity really anywhere, ideally, obviously, self-hosting it. And talking about access control, so access control writes, I'll create something very primitive. I'll create a node, which is this node. It's just a file we basically upload to our solid server, to our catastorage. And to that node, I might even... I'll be very ambitious and upload a picture, and hopefully, they'll make it there. Yeah, there we go. So this is a file we've uploaded to our files. It's going to be to our solid server. It's not that crazy, but what we can do, so if we go to this test node, we can copy the URL that it is at. And wait. I want to show that this is... So this URL is basically where our node is, which is publicly available, so people can get it. Anyone can connect to this node. Anyone can visualize this node. Anyone can see this node, which is what you would expect. So what you can do then, you can edit the privacy settings on this node. And at the moment, it's public. I can make it private, where only I can access this node, or I can actually add particular electronic authorization. The people I know are the general, just WebIDs out there in the world. So if I allow Tim Bernsley to read the access. Can somebody, anyone has contact with him? Can you ping him? Tell him that he has read the access to this... Oh, right. Am I the only one who's left that? But so basically now, only he has access to this file. And if I try to curl it from the outside, I get denied, I don't have the authorization, unless I prove that I am indeed Tim Bernsley through the predefined authorization purpose. And this is enforced on a, this is not enforced on an application level. Obviously, this is enforced by the solid server that the user is running. So this is in a nutshell kind of the things that goes a bit deeper than that. You can really spend some time tailoring your identity, making, you know, you spend some time adding valuable information about you. And then you can use this identity to interact with a lot of applications that are out there in the wild. You don't have to create a new identity with every application you're using. You don't have to register again. The dream would be you basically go and say, you connect with my web ID. And it would be kind of like the Facebook connect, but not evil. So Stok basically presented what we do, what we are all about, but we've encountered a number of problems I think about doing that. And also a couple of questions. So the big question kind of is, is the identity model defined by solid truly self sovereign? And some people it is to a certain extent because you don't rely on a centralized identity provider. Some people it isn't because you still rely on DNS. And some people would say that you rely on an electricity provider and so on and so forth, but the big sort of weak point here to a certain extent is that it does depend on DNS. This is one problem of the current system. And another problem of the current system is that your identifier is tightly coupled with the transfer protocol, with the protocol. So your identity is HTTPS forward slash forward slash, whatever. This is the problem. There's no layer of abstraction between your identifier and the protocol. So there's no layer of abstraction between who you are and where you are. And this is probably my case, your server goes down. You won't change to a different web ID. What happens if you want to change to a different domain name? What happens all of the connections you've built until now are broken? Because I'm not going to say, I'm not going to say broken again, because the connections you've built so far are broken because now they point to an imbalance. Okay, so this is kind of a problem that they're so tightly coupled. Migration is indeed a bit problematic. Another problem is the authentication protocols that I employed at the moment. Into these, we're not going to dive too deeply, but to make it very, very briefly explain this. The authentication protocol currently employed is web ID TLS, which basically uses client certificates to authenticate. And I don't know if anyone is familiar with client certificates, they suck. So this is a problem. There's no easy way to terminate a session. There's no easy way to log out. There's no easy way to do a lot of things. So to abstract this problem, we built a proxy, which they use our self-posts and which we use as well for development purposes. But the proxy is quite straightforward, really. The proxy stores your client certificate, the keys, and then you proxy the request through the proxy. The proxy signing stuff. So you don't have to see this. This is all with the pop-up all the time. There's easy way to terminate your session. Should you trust a centralized proxy? Obviously not. Self-posted would be the correct solution, yeah. So this has aspects of the web of trust. There's a lot of agents interacting between each other. You can link to other people. You can give permissions to one another person. The idea of reputation and claims comes kind of natural to this. So it would be really cool if agents could state something about another agent. And this is possible to a certain extent with the current implementation. The truth is that it's still on file systems. It's on servers, so there's no, in case of hijacks, in case of servers being compromised, in case of malicious agents being present, it's a bit difficult. So there's no one way to fully verify that the data hasn't been tampered with at this. Another, so this basically results on it. So making claims, there's a way to do claims now. With the current solid infrastructure, the question is, could it be improved? And making payments is something that kind of comes to your mind as well because this is all about sharing information. This is all about sharing data. So it's easy to envision scenarios where you would want to share something and return for some price. Perhaps even having a service provider, like I don't know, Facebook, actually not too much bad things about Facebook, Google+, asking you, do you want to provide me your address? I'm gonna pay you this and that much. Or do you want to give me access to your list of friends? I'm gonna do this and that. So there's a potential sort of LA for payments. But the biggest issue is DNS dependency and this is strong coupling between who you are and the way you are. So what we do here now, together with Fabian who's gonna come in a minute, is we kind of started looking at that. It's only sort of in the starting phase. There's no revolution coming, so waiting for that. My God, I'm gonna smoke a bit. But we were kind of looking at ways to improve what we currently have. Perhaps to remove some of the dependency on some centralized services, things like that. And I guess Fabian probably come out and, I'm gonna go try to figure out where that doesn't work. I do it with the keyboard. You might wondering, where's the fucking blockchain here? That's a very strong introduction. Yeah, you'll come figure there may be a solution for those problems and even more problems with Ethereum. So they got a little bit of funding to work with me from Farnov and my colleague Manuel here together. So we can investigate a little bit how maybe Ethereum can solve some problems. And yeah, this is a big picture. So it's an extract of what Virginia presented. But there's somehow the digital identity in the blockchain. And there are maybe third parties involved for payment and such things. And very important again, is this VET ID proxy. And because again, the VET ID is very complicated to use. Nobody actually does it. You have to install something in the browser, certificate and so on. So, and this is also an issue you may want to solve for the blockchain. And we wrote down some general considerations about it in the first place. The biggest problem is how can Ethereum be integrated with the given technology stack. So it's a linked data stack. It's DNS based. It's basically a completely different thing. And the second question is, how can it get it to identity when we present it in Ethereum? Then how does this affect the sign up and log in process? And will it be secure? Because it's public, it's a public blockchain. How can we map claims and perspective verifications because this is a potential use case for the Yellowcombe software. And especially very important is how can we search for other identities? Because now you need this VET ID. If you would put it in a sample instance, you have a sample instance again. So, but you just need it. Like a junior type in Joachim Web ID Yellowcombe. And yeah, what we first did is some kind of state of the art analysis. You probably know some of the projects, I bet, especially U-Port. And, but the landscape of people working with future identities and digital identities that you pick, but we focused on the most prominent ones. And Blockstake, it's a decentralized app platform based on blockchains. Consensus is a company behind U-Port and other Ethereum products. And important also very interesting is Jason Web tokens. Because U-Port, if you don't know it, U-Port is a similar approach. They want to do digital identities in the blockchain, in the premium blockchain. And the main vision there is, especially it's similar to our vision, that you want to replace command user name password locking system. You just want to block in a different way. So you don't have to remember the password all the time. And the concept is to have a smartphone. You have to privately on the smartphone. And you have like with the WhatsApp app, if you know it, you scan your QR code and then you authenticate it with the blockchain identity. But for now it's like this. If your smartphone gets lost, your identity gets lost. They are working on a recovery process, which is not in place. We actually talked to the U-Port guys. And I'm not going into detail about this. And they have a proxy contract and you can recover your identity because you're actually identity is somewhere here. And you have this little social network which has parts of your private key you can recover it. So they are heavily working on key recovery. Which is also an issue for us. That's basically the biggest issue of all of this because if you have somehow a digital identity in the blockchain and you're facing the issue, how to lock in, how to authenticate against it. And we talked to Ethereum guys here. We talked to U-Port. And basically it comes down to this, you still have to save your private key somewhere. There's no, actually there's no way around it. You can do it in a browser at all. You can do it in the Ethereum mist browser. You can have it on your smartphone, you can write it down. But this is like some of the conclusion for our little project that you still have to do it. This is related to super-strikes, you might know it. It's in a decentralized system. If you have an identifier, it's either decentralized or insecure or it's secure or inhuman meaningful. You cannot have three or three of them. We have a decentralized system which is secure but our identifier is still not that human meaningful. So what we did, we decide where we are because our project is just five months and that we cannot change the solid and that identity infrastructure. We have to keep it as it is. It's based on DNS, it's based on link data. So we designed an intermediate solution. So the step towards a completely self-sorbent identity. So we introduced the digital identity in Ethereum. We took concepts from U-Port, Blocks, DID, and we didn't use U-Port because we didn't use it directly because it's a closed system somehow. That this app, you need to use this app and they advise us that we are not got a good idea to use the contracts directly because they cannot ensure the security if you don't use that. So we did our own complex based on their concept and what we're doing, we are storing the Vepad Evoi as Eugenio mentioned just as an attribute in the blockchain identity. And we are also putting the encrypted private key there. So you're getting your identity, it's somehow self-sorbent. You have it in your blockchain encrypted. And we can put in additional attributes like claims of applications and this comes down that little sister acts as a live wallet. So the app you have just seen is then a live wallet. And this is an intermediate step towards a complete self-sorbent identity. Again, the overall architecture, we have the Eurocard app, we have the live wallet, we have a death note, which is at the moment, sinful, but you can have it on your own system as well. We have personal identity contracts. We will also offer a seed storage. The seed is there to get your private key. It's just a service, so you don't have to write it down. And we have this WebID proxy, which will not store any longer the keys of the WebID, but the keys are in the contracts. And just taking into detail, we're using the consensus Ethereum live wallet, which works with this death note and the private keys are only stored on the browser and it's communicating the note. And the smart contract design is not finished yet, we're still working on this. We will have a lookup contract where you find the users and you will have your personal identity contract for all your attributes and your WebIDs in there. And we have a global identity contract where you can find users and also the claims would be probably there. Yeah, and the future overview, we have the digital identity with the WebID and we have the additional attributes, which can be stored there and other users and companies could verify additional attributes. We are also still working on this, this will be JSON web token base that will be hashed and somehow we will have to get it out in the next months. And just the use case, and because actually my department in front of it we are dealing with public services, so this is really related to our work and it's usually if you want to need to share a driver license and for example, to make a car, you have the option to show the driver license physically, you can show it digitally with the service and option three, we are aiming to do is, you verify the claim that you have it, have the license, like with this option and you do it once and you put it in the blockchain and then you can use it all over again. Another use case in the future, hopefully, people will go to the blog and they tell that you have a driver license, Erica has it, they sign it with their key and it's in the blockchain so everybody can see that Erica is allowed to drive a car. It's just, that's the vision, what we want to do with such an entity and we put it there in the blockchain. I didn't do that. I didn't do that. So what's actually going to be stored in that contract and have you already looked at how? Yeah, yeah, we did, we did in the lookup contract, well, Manu, you can answer it, he's doing the contract. Manu, look up, we want to read a personal account, a personal smart contract for every person and it's a way how you can find your personal smart contract based on your choice. So you just look at the contract. Have you some kind of notion about gas consumption of the two years? Yeah. I noticed with the start-ups now coming up, I tried a couple and I was stunned by what I had to pay for saving my data. So it's early stage, so I think it was good. But there's a lot of it to actually going on on your JOLICOM, so we have some calculations. Yeah, we calculated, at least for the creation of the contract with the WebID, we calculated it's 11 cents, euros cents at the moment. At the moment. At the moment, yeah. Yeah, that's the thing, all this, your privacy, you have to pay for it. Questions? Any questions for you, Jean? Who will buy or the person who will buy this? Who will buy what? This software, this service. Who will buy? It's actually like, if you look at the payment option on general, who will use it? If it's 11 cents, you mean? I didn't get the... How do you make money? Maybe you have to answer that. That's a good question. This project is, at least for us, it's not about making money, but it's research, we try to evolve this idea, and yeah, there is no real business concept right now. Well, I mean, at least not with the developers. Thank you, I think it's there. All of the questions regarding that became... But actually, it's always with data. If you want to buy data, somebody's getting a fee, probably. So, it's difficult. So... On one side, you include your private key. We use our private key. We use other keys to encrypt those keys. We are deriving from the Ethereum private key, another key, and with this one, we will encrypt the private key. And what about that key? Which key? That's the encryption key. What way do you think... It's deterministic. We can create it every time again from the... I see, you have a problem, I should have seen. If I lost the original key, my original private key from Ethereum... You encrypt your private key. The WebID private key. It's not the Ethereum private key. It's like this YoloCom ecosystem has a WebID, and this WebID has also a private key. It's signed with a key. And we're encrypting this key. Sorry, I didn't get it. You can derive from C, YoloC, like 12 words, you have to remember, then you can derive a couple of public private keys. And we're just using a cycle code for encrypting it. But... What is the bit behind C in this private key? Why are you encrypting this private key? Because it's on the blockchain, so it's public. Your identity in the blockchain is... Everybody can see it. And it's your private... Why do you lost this encryption key? Yeah, but that's the thing we were talking about, that there is no solution right now. You have to store your private key somewhere. That's... That's a thing. I don't know. You're probably a couple of years using Ethereum, so you have your private key. So if you lose it, yeah. We have this mechanism, this Ethereum light wallet is offering this method to generate a 12-word human readable seed. It's 12 English words. And we're actually offering to store this seed, and not the very cryptic private key, but you have to remember or write down the seed. It's still... That's still state-of-the-art. Actually, we really talked to a lot of Ethereum guys here, and it's like this. And U-Port is working on it, but they told us that it will take at least a couple of months until they have the recovery, the social recovery process in place. But then still it's not really self-sorning because you rely on your friends to help you out. You do a lot of math, so I have a nasty question. Why are you looking at Ethereum? Because they're here. Yeah, I mean, a part of being in the office and allowing the project. Yeah, actually, this was like, it's a very, like in the sense that this is a small project, and we had to set some requirements. Yeah, the scope, and we said, okay, Ethereum, it's complicated enough for the time we have. And it's like, you have this chewing complete programming language and it offers you, for now, everything you need. But yeah, it's a good point. Maybe better blockchains or other blockchains for the specific use case, maybe. But also the fundamental idea is to eventually, perhaps, move away from HTTP URIs as identifiers and rather introduce an extra layer of abstraction. This is effort done by, for example, BID. So yeah, that's basically a non-human readable identifier that resolves different data structure and different blockchain depending on. So there's effort on that. There's also XDI, which is an alternative to RDF, which also deals with similar things. But in the long picture, the ideal would be to kind of decouple them, or at least introduce a certain amount of portability where you can change your domain name, you can kind of move your data, it can still maintain your identity, and this is kind of the golden, the holy grail, so to say, at least for us at this point in time. So we're doing a little exploration step by step. This was a very simple straightforward example of integration, I want to see how this works, how well this use our needs. So this is by no means a state of the art. This is by no means a finished project. It's rather just kind of a bunch of people figuring things out, so. Yeah, big issues also always performance scalability where if this lookup contract or this, the map with all identities, we don't know how it behaves if there are millions of identities in that, we don't know. Say a question for the WebID part, like what it means to incorporate that in your model. The stack, so the WebID, the solid, sound is really attractive, and I think it is still very, I think it is still very attractive to this day because, sorry, it is very attractive to this day because it promises this wonderful type of system where you have a bunch of identities, all of them use apps, your data is on your part. It is very, and it's still very much a development. You see very smart people behind it, very smart people working on it. And it shows promise for certain extent, and this is really the, at least to us, this is subjectively the weak point because some people would argue that DNS is not a problem. And some people would argue that it is, and therefore you have incentives. I don't think the, I actually think as far as problems with relying on kind of web infrastructure go over reliance on DNS is a smaller one. The other one is I feel like while you have reliance on any kind of server, it's not fully self-sovereign just because like regular people cannot operate their own servers. Like even I try to operate my own server and I have to do a bunch of maintenance on it every month, right? So, like it's, if you go towards that model where like it's the best thing you can possibly do is realistically federated, right? I think that's a very important point. There's some incentives that I get on plug-in freedom box, which is, you know, this kind of like out of the box thing you plug it into the internet and you have your solid server identity there. So it really tries to abstract a lot of the technical concepts from normal people but they're still troubleshooting, they're still maintained. So it has issues. I mean, it has challenges. And I think you make a very good point here actually that as long as users can operate their own servers they'll probably be vulnerable to this. And someone will argue that centralized identity providers like Facebook would probably be more secure than there'll be more withstanding to denial of service attacks to just malicious intent in general than your personal solid server. So, it's, oh, I love it. Sorry, I'm taking more of the conversation. I would just as part of the previous question, one of the attack vectors like you identified with this server thing. Do you have something in mind which is basically a base for the servers? If everyone wants to run a server, then you have to push up things and like maybe you found some other like ways of like, what would you basically call it? Yeah, I mean, if someone doesn't like when you host your own solid server on a freedom box for example, the freedom box has limitations in terms of computations, they can easily take it down really. So that's another problem, but you know, you basically want every user to close their own server and that server to be able to withstand the potential attack from a million malicious agents. So it's kind of, it's a tough sort of agreement that needs to be found. But there is a reason, there is a reason. The normal everyday user running their own server self posting probably doesn't have the infrastructure to survive a malicious intent. But the question is how malicious, like who would be this bad guy attacking users? There's always the chance of backing out that and looking for a different server. So this, I think it's already out of the scope of this presentation. We are really exploring these things as well to find them as we go and as we kind of step around the ecosystem. So we might not have the perfect answer for everything here, but we're willing to get here and discuss definitely. I'll hold up on this question. Yeah, I'll only ask you nasty questions because I was fired by the presentation. So we keep my brain going. Because now we're all worried about this and that. Yeah, I'm not very good at giving nasty answers to that. We'll just have one here, I'll see. I think too.