 Good evening everybody and welcome to a little show and tell of our product called Skizzle. So I'd like to break this talk down into four parts. Basically, let's start, you know, first part will be some context setting, some introductions and a little bit about our product or motivations, etc. Then we'll jump into some of the more interesting stuff, which is, of course, we'll do a live demo of Skizzle. And then let's actually jump into, you know, the tech bits behind Skizzle and more specifically how we actually achieve end-to-end encryption. So, I'm Mayur Relaker. I'm the founder of a company called Newfang, where we are building a product called Skizzle. And I've been an entrepreneur in the past and two other startups that I founded, both were failures. So I'm here hoping to contain the charm for us. And I work with a great team of guys. Arvind, who heads our growth and Abhishek, who is our tech lead, were both my colleagues for the past six years now. And we are working at a technology services company here in Bangalore. And Saurav has joined us also and Saurav happens to be like a blockchain dev, but really he's our man Friday. He can do just about anything that is required of him. And Saurav is in fact still in college. She's in his final year. And once he graduates, you know, he'll be on board with the team completely. So let me tell you a bit about Newfang before we actually get into Skizzle. So Newfang is a company founded in 2019. And the idea was to build a decentralized cloud storage platform for developers. And when I say decentralized cloud storage platform, you could imagine something like an AWS S3 or Google cloud storage. But in our case, we wouldn't own and operate any data centers. The resources that is storage and bandwidth would actually come from independent third parties who would do so for an incentive. And in our case, that would be cryptocurrency. And our motivation behind building this was to be able to be a platform that is faster with greater emphasis on security and privacy. And of course cheaper by trying to leverage devices at the edge of the network, like your smart phones, laptop, smart fridge, etc. So at one point, after we launched Newfang and we took it to market, we realized that the market that we are catering to, which happens to be the Web 3.0 set of developers, basically people building decentralized apps. They were themselves in a very early stage, very, very novel stuff was happening. And primarily they couldn't really afford to even pay us. And that market was completely cornered by free credits from Amazon and Google and what have you. And that's when we kind of decided that in order to really survive, we needed to have more stamina, more runway. And we wanted to figure out a way to get to get to revenues faster. So we did. But obviously we built all of this tech and intellectual property, which we really wanted to leverage. So what we decided was to build a product that basically we hoped other people would build on top of our platform. And which is how Skizzle was born. We've been working on it since the beginning of this year. And we are now at the absolute cusp of, you know, putting out a public beta very, very shortly in the coming weeks. And hopefully things will go well. So let me start talking to you about Skizzle, right? So let's set the context for what Skizzle is first. So we all share files every day, whether it's for personal reasons or for work. And some of these files just happen to be more important than others. And when I say important, they could be inherently valuable or contain sensitive information. You know, things like trade secrets, intellectual property, financial documents, or even this personal information. And we usually share these files over email, especially if it's trying to collaborate with people on the outside. For internal sharing of files, of course, people use messengers and chat apps and things like that. But more often than not, we end up sharing these files over email, either as attachments or as links to file that actually sit on another service, like say box, Dropbox or Google Drive. The problem essentially is that attachments are unencrypted. And even if there is encryption, the encryption keys that are used to actually encrypt your file are owned and controlled by the service provider. And I mean, you know, this basically means that they always have access to your files. And in some cases, with a few service providers, that is by design, because that is exactly the business model. And if you were to try and go about encrypting and sharing an encrypted file with someone else, you'd have to jump some real user experience hoops, you know, where you'd have to have, you would have to generate your own keys. You'd have to then, you know, encrypt your files using Software A, upload it to Software B, and then finally go to your email and share a link and things like that. So it's really not trivial for the average person. So Skizzle solves this and Skizzle in its current form is a browser extension that allows you to send and receive end-to-end encrypted files right in your email. You never have to leave your inbox, never have to use an additional tool to accomplish this. And what is, at least what we think is really great about us is the fact that a lot of our backend is on a blockchain. And so basically what we do is every user action is written to the blockchain. So this brings about unprecedented amounts of trust and transparency into how things work. You'll see it in action very shortly once we do the demo and go through the talk. So let's jump right into it. So hopefully everything will go well. So I'm in my inbox here. And as you guys could perhaps see on the top right of my browser, I already have the Skizzle extension installed. To send an encrypted file over to someone else, I just have to do exactly the things that I'm used to doing. I hit compose. You'll see that Skizzle introduces a little security bar here. I turn Skizzle security on, which basically means that every attachment that I add to this email is now going to be a Skizzle encrypted attachment. I do what I normally would or intuitively do, which is hit attach files. Then I go ahead and pick a file. And now this file gets encrypted locally and gets uploaded to our servers. And I simply have to say who I want to send it to. And I just hit send. And that's it. I don't have to do anything else. So on the receiver side, presuming that I have the extension already installed, just wait for a couple of seconds for the email to show up. There you go. I just need to click the email. Skizzle recognizes that there is an encrypted attachment. And it goes ahead and fetches it. And I just click it to start downloading. That's literally it. From the sender sending the file to the receiver receiving it, no one in between, not even Gmail, not even the servers where we store the file, the encrypted files. And not even us, none of us, none of these people, no intermediaries ever have access to your file. So, apart from this, of course, the Skizzle UI shows you, you know, files that you've sent and received. You can, in fact, even just go ahead and, you know, see, get a few details of the file, but more importantly, see who all have access to this file. And like you see here, I can go ahead and actually revoke access to anyone that I've shared with. I've just shared this email with, I mean, this file with this particular address. I go ahead and hit revoke. And as soon as that is done. So you have complete control over who has access to your files. And then, obviously, once the file has been downloaded, you this is literally nothing you can do, but this starts to become very powerful when you share a file with view only access. And this is something that we are working on and will have released in our beta. So yeah, I mean, where where this starts to get really interesting is, you know, we are saying all of these things about, you know, these are the people who have access. You know, everything's written in the blockchain, but how do you kind of publicly verify all of this. So we've got that covered too. You simply have to say verify. And this is an explorer that we've built, which basically queries a public blockchain. And kind of gets information of about, you know, all the files that have been uploaded. If you if you jump in here, or on the second while this loads up, it kind of shows you all the activity on the network. And, you know, I can actually take a look at, you know, what all is happening. I can even further go and verify this on the public blockchain that they're using, you know, just click on the the transaction that occurred and I can go and, you know, look at all of the logs and kind of verify that, you know, whatever is being said is really what is happening. You can always take a look at, you know, what is the status with a particular file. In this case, this is a file that has just been uploaded. It's not been shared with anyone, not downloaded, not to work, but all of this data is just pulled from the blockchain. And so you can always verify. But the key thing here is if this is a public explorer, it means that everyone, anyone can basically access this. So what we've done is we use only pseudonymous identifiers as you can see here, it says so and so user uploaded so and so file. And so this way, what we kind of ensure is that until and unless you know what you're looking for you really can't find it. And if you are just kind of perusing through the explorer, you are none the wiser about who the identity of people or what they're doing and what kind of files. So, yeah, so this is, this is what Skizzle does. And this is in its current form, like I said, it's just a Chrome extension will obviously expanded to other browsers. We'd also love for it to play well with, you know, some of the other, you know, email clients out there will obviously look at outlook. And of course, you know, all of your mobile apps for Gmail or outlook or what have you. All right. So what is our motivation behind building Skizzle and in fact even with new Fang, and we always kind of seem to go back to the seven principles of privacy by design. And these are the seven principles listed here the pretty self explanatory but I'd like to quickly gloss over them principle one says proactive not reactive preventative not remedial. This basically means that, you know, if you are in the business of, you know, saying, we look at privacy later. And then you're, then you end up having a breach and then you're firefighting breaches and kind of trying to address things later. Then you're, you know, it's only going to get worse for you. So you can need to be proactive when it comes to things like privacy of data and especially users privacy principle tools is privacy at the default. So privacy is not a feature. It's something that has to be part of everything that you start doing, which kind of takes us into principle three which is saying privacy embedded into design. So your entire system your architecture everything I should be taking into account privacy from the get go. And it should also be positive some not zero some which basically means that if your attempts to do good privacy and to do, you know, basically do do proper security for your system and for your users in the process if you're compromising on say user experience. Then, then you're doing something wrong. Either you're not being creative enough or not explored all of the options. So at the end, it really should not be this dichotomy of user experience versus says system security or being wholly private. It has to be something that works together and positive some end to end security which basically talks about ensuring that you know the lifecycle of the data right from the user uploading it or adding it right up to the point where it can be fully deleted and removed from the system is completely taken care of you're not just sitting on idle data that is really has no business being there. And then visibility and transparency talks about basically how your entire system needs to be very accessible. It should really play well with other open systems that are out there. We should. I mean, we can even talk about things like, you know, all the critical pieces of your code being open source and also ways for your users and the public in general to be able to interact and also give feedback to whatever it is that you're doing. And finally just respectful user privacy. It's, it has to be with everything that you do every little tool that you use to improve your product or do anything else you have to take into account and ask the questions is this going to is this respectful of our users privacy. And if the answer is no then it's something that you should perhaps definitely look at avoiding. So let's look at the broad architecture of schizel. There are five important parts to this one is obviously the extension. And then you have we have our odd libraries we use Google because right now we work with Gmail so we use Google odds to kind of verify users and we also use the decentralized key key management system from the guys at Taurus, you go into some detail about that a little later so this is the authentication libraries we use. We have a we have an application server that kind of helps us with the overall UX, obviously things like you know loading files fetching data needs to be really fast and you know, responsive and something that users are kind of used to. And we then have our schizel storage network which is basically a set of storage nodes, which kind of act like a distributed file system. And they basically handle storing of all the encrypted files and also handling any requests that are coming the way. And finally we have of course our smart contracts on a public blockchain. And this is what kind of enables the access management that we built into schizel. It's a decentralized access management system so it's not something that we run off a central server somewhere. Everything that you want to be able to do with respect to providing access to your system is actually written in smart contracts, which can be publicly audited and the code for this is also open source. So let's kind of look at each of these five pieces right and I'd like to look at them from the lens of you know what are we doing about the security and privacy aspects that we that we are so keen on ensuring within our system. So the first piece is obviously the extension as the extension is a view JS app. And we for those of you familiar with Chrome extensions, we use content scripts to actually talk to the email client. So if you remember from the demo of the piece about how the security bar is put into the compose window that happens through content scripts. And we obviously leverage the browser's local storage to store almost all of the data that is kind of critical. And we store it in encrypted form in local storage and we ensure that you know only stuff that really needs to be on a server is on a server but otherwise everything else is encrypted and stored in local storage. So what are the security and privacy implications. What are we doing to kind of ensure this. So a user is assigned crypto keys and we'll see that in a minute and how that happens. And we make sure that these keys are stored securely that is they're always encrypted whenever not required. All the files are is encrypted before they are uploaded. And only publicly known information is stored unencrypted in your local storage. Sorry about that. And what we also do is we make sure that the extension only works on the Gmail tab. This is with the express intent of making sure that you know a lot of extension that you might have seen or used will say they require access to every site that you visit. For us that is obviously not logically required and also from a security perspective we want to ensure that we're doing everything possible. Which is why we make sure that extension only works on Gmail. And the extension does not read emails. The code for this will also be open source so this can also be verified. The only thing that the extension does it is it looks for a specific HTML element in the email body just to be able to recognize if there is a schedule encrypted attachment. But otherwise it totally ignores the rest of your content. In the authentication libraries that I spoke of we use Google Auths for sign up and we use the Torus Direct Auths. This is the Torus website. Yeah, so this is what Torus does and Torus is essentially a non custodial key management system. So basically means that you although kind of keys are generated by Torus and they're a decentralized set of nodes. The actual custodians are the users themselves. They can own and control their keys. So yeah, so in terms of security and privacy we use Torus and like I said it's completely decentralized and non custodial which really works for us. Then of course we have the application server which is kind of used to do a lot of, you know, quick work, improve the UX. It stores some file info of the users. And it's also what enables PGP. We kind of dive into this later on in the talk. And it also kind of tracks user and billing handles, all payments and user billing and things like that. What we do is we basically don't store any data that is non essential on the servers. Like I said, everything is stored on the extension itself in your browser. And we definitely don't store any sort of data that will help us, you know, derive usage graphs. So even if our servers are compromised there is really nothing that stands to be gained by the any attack. We use standard JWT based authentication for any API calls. And we always encrypt locally before storing any data that needs to be, you know, basically shared or retrieved at a later date and also to allow for backups and for users to like move systems and things like that. Then we have our storage network, which like I said before is a set of nodes that basically runs a custom Tahoe LFS app. So for those of you who don't know what Tahoe LFS is. So Tahoe is a distributed file system. It was built by these two guys called Zuko Wilcox and Bram Cohen. Zuko is a very well known photographer and Bram Cohen is the guy who created the bitter and protocol. And like I said, it's a, you know, completely distributed file system. And it does a lot of cool things, but you know, it was not enough. So we basically gone ahead and, you know, made it our own. We forked their code and brought it up to speed. It's quite old built in the mid 2000s. And what the network kind of also does is it performs something called erasure coding. Erasure coding is basically basically a form of file encoding, which basically means that any encrypted file that is uploaded is broken up into a bunch of pieces. And each piece sits on a unique storage node. And the breaking up of this file happens in such a way that you need only a subset of them to actually retrieve the entire file back. So it's more, you know, elegant redundancy management when you compare it to a system like RAID. Just to give an example, an encrypted file could be uploaded to our servers. It gets broken up into six pieces. And you need only any four of those pieces to actually retrieve the file back. This means that if two nodes are down for any reason, your entire file can still be retrieved. No problem. And it obviously stores the encrypted files and affords for their downloads and deletions of these files. And it also does one important task of forwarding user user sign transactions. And when I say this, it's basically every, like I mentioned before, every user action is written to the blockchain. And what we do is we get the user to sign a transaction on the client with their cryptographic keys. And this sign transaction is then submitted by us to the public blockchain. And this is in a way to ensure that the users don't have to interact with the cryptocurrency or, you know, deal with anything that the blockchain has to, the actions that the blockchain has to perform. And we're doing this in the interest of user experience and trying to ensure that, you know, people don't have to, you know, get themselves mangled with, you know, handling keys and doing a lot of other things. And so a couple of the things that we kind of take care of from a security standpoint is of course erasure coding is to make it more fault tolerant like I explained. It's a complete zero knowledge store. So none of the nodes know what they're storing. There is absolutely no way that, you know, any, any sort of data mining can be performed. And they can't manipulate transactions. And even if they, even if one of the nodes is compromised and any kind of manipulated transaction were to be submitted to the blockchain, this would, this transaction itself would fail and completely roll back. If they're trying to spoof a user or to kind of change some of the data that is being passed. And finally, we have the blockchain itself, which is a set of smart contracts on, on basically what is known on a public blockchain called Matic. Matic is a company based out of Bangalore here in India. It's one of the biggest and most used blockchains in the world. In fact, it is, it's a layer to scaling solution on top of Ethereum. For those of you familiar with the blockchain space will know that Ethereum can probably do about 14 transactions per second and Matic kind of enables, you know, doing thousands of transactions if not more per second. And this is the blockchain of our choice. It's completely public and decentralized. And the blockchain, we also use it to store usage logs. And we do this so that, you know, there's complete transparency unit comes to your usage and consequently your billing and as charging you. So, like I said, we use only public Ethereum identifiers. If you will remember from the explorer that I showed earlier, all of the identifiers are pseudonymous. And even though public, you don't know who is the actual owner of these particular files, etc. And the blockchain completely the blockchain bits kind of take care of the access control and we follow something basically what is known as the decentralized ID spec. Did is something that are coming into play. There is a whole working group by the W3C over here. So there's a lot of great work happening here and the idea behind decentralized identifiers and I won't go into too much detail because this is a huge topic on its own is to basically give self sovereign identity to people and even things. And so what we've done is we've taken the concepts and in fact the entire specification behind the IDs and applied them to files in our case. I'll go into more details on how we how this actually implemented and how we actually perform access control based on the IDs. And finally, we store only hashes of any personal data that are required, like I mentioned earlier. So, yeah, now let's get to the important bits right so how do we actually perform this end to end encryption. We basically do a combination of symmetric and a symmetric encryption. So the symmetric part is of course we use as 128 to encrypt the files using an encryption key that we generate on the fly on the client. And we use standard PGP to kind of be able to encrypt the encryption key and share it with share it with someone else. So we'll go into more details about this shortly. So to be able to kind of understand how we fully do it we there are there are a couple of questions that we need to answer and and we had to get right in order to make this happen seamlessly. The first one is how do we end up assigning keys right so I told you earlier that this process is not exactly straightforward. How we assign keys is basically we have the extension here and the extension when the user performs a sign up operation. We get them verified by Google Auth and the Auth token is then forwarded to the Torus network, which is basically a set of nodes that are doing what they're doing is they're constantly generating public private key pairs. Public private key pairs that are constantly generated and when this user is authenticated and let's say this is the first time user basically the Torus network spits out you know some cryptographic material. Each of the nodes kind of generates a piece of what will be the key pair and these pieces are then sent over to the client. And then it is all pieced together and then decrypted to actually give us the actual public private key pair, which we store locally within the extension itself. So in one seamless Google sign up operation, a user is actually assigned public public private key pair that they actually own and control. So then now that we've done that once we've assigned keys to people, the next process is obviously how do we handle uploads, right? So we have the client here, which is basically a combination of the browser and the schizel extension. And from my Gmail UI, I obviously pick a file from my hard disk. This file gets encrypted on the client itself, like I mentioned, and the encryption key that is generated is then pushed to the local storage over here. And then the encrypted file itself is then uploaded to the storage node network. And the encrypted file is then like I mentioned earlier is erasure coded broken up into multiple pieces with each piece sitting on a separate node. And once this operation is performed, we submit a signed transaction basically logging that user operation, which is the upload operation on to the blockchain. And once the upload succeeds, the client is then informed. And we managed to kind of fully upload completely encrypted file. So this we've done one part of the e2e process. Then how do we handle file sharing? So this is the critical element of the whole process. Now, this is akin to me hitting the send button on Gmail. And when you actually hit the send button in your Gmail client when you're using schizel, this kind of basically invokes our schizel server to talk to the smart contract and create what is basically a decentralized ID, a DID for the file that was uploaded and then shared. This document that is generated, let us take a quick look at it and how that looks. And this follows the W3C DID spec. And if you were to kind of piece together all of the piece individual elements of all that we do on the on the blockchain and smart contracts is you'd arrive with, you know, like a JSON that looks like this. There's a bunch of material here. There, like I mentioned, there will, every file is assigned a DID. Apart from the DID, of course, you know, there's some information about when it was created, and when it was updated. And then there is some information about the public key, which basically talks about who is the owner. So there's some information about that, who is the owner of the file. And then there's mechanisms for how you can authenticate the ownership of this particular file. The key pieces, key piece here is about the services that are exposed. And these are completely open. We're talking about services like, for example, checking if a particular user has access. And there'll be a particular service endpoint for it. And similarly, there are other services like get all users, which is to basically say who are the different users who have access to this particular file. And there's so many other such, you know, services that we've incorporated, and this can be obviously extended hugely. And then we go into a few more details about, you know, what is the file size, something called the UEP hash, which is basically the multiple tree of the file that was encrypted. What the UEP hash serves as is the way to check the file integrity when it is downloaded. So if you're able to kind of build the entire multiple tree back and arrive at this UEP hash, that means you've gotten the file that you actually uploaded and it is correct. And this is what the DID document for a particular file that was uploaded actually looks like. And this is what we kind of use within our smart contracts to figure out if some user has access to a particular file or not. And then the last bit is, of course, how do we manage downloads. So the recipient uses the extension again. And what they do is they basically make a request to the storage network, the storage node network to fix the file. And based on the DID of the file, the storage node network checks if the smart contract, on the smart contract, if this particular recipient has access. And if this user indeed has access, then the file is decoded back and the encrypted file is then transferred over to the client. So asynchronously, there is also a call that goes out to our application server, which fetches the encrypted encryption key. So when a file is uploaded and shared with someone, the encryption key that was used is then further encrypted with the recipient's public key. And that means that only this particular recipient can basically decrypt this encrypted encryption key with their own private key. So if anyone else kind of managed to get hold of the encrypted file, they would still not have access to the encryption key in order to decrypt the file. So it's almost like double layer protection. So this is essentially how we've kind of enabled end to end encryption on our system. What's next for us is a bunch of things. Like for example, we need to be able to handle forward and backward secrecy. Just to quickly kind of let you guys in on what that means. So backward secrecy is basically saying that if basically a set of keys or a secret is exposed at any given point in time, that means that the system or the files that are actually uploaded should not be then still available to this attacker who managed to get hold of these keys at a later date. Forward secrecy is, you know, if there is basically like a passive attacker who's kind of putting together all the encrypted files, somehow he gets hold of them. And then later on in the future gets hold of a set of keys or some secrets that will decrypt these files. He should not be able to do so. So this is something that we want to be able to implement. There are great resources on how some people do it. I would definitely urge you guys to look at signal or the messaging app and they have done some fantastic work in the space. Next is to obviously be able to deal with malicious users and malware. So one of this in fact came up very recently and the question was how do you deal with malware being sent using Skizzle. And this is an issue for any system that is end to end encrypted because you cannot basically process files that are already encrypted and there is no real great way to actually do this. There are workarounds that we are at the moment considering and I'd love to go into details of that perhaps if anyone has any questions. And it kind of brings us to one of the ways we can actually deal with malware is and but more importantly do a whole bunch of other things is being able to process process over encrypted data. So this is possible with homomorphic encryption, which basically means that you can let data remain fully encrypted and without decrypting actually process that particular data. One of the things that you could do in your processing is actually detect from malware and without ever needing access to keys or the actual data itself. There's some great work going on in this space and there are a lot of POCs that are getting built. This is a very old concept from the 1980s if I'm not wrong, but you know hardware or needed to catch up and then software needed to catch up and now we're getting really close. There's some good POCs. The only problem is it's really slow to do homomorphic encryption and process data over it at the moment, but I think it's just a matter of time where this will be possible. And lastly from a text standpoint, what we definitely looking at doing next is extending schedule beyond being like an extension or or an add on for different services. And start giving developers access to APIs in SDKs so they can actually use whatever we built in in their in their apps and in their products, especially if their apps and products are privacy and security centric. So this is something that we want to be able to do next. So yeah, I mean, thank you. We'd love for you guys to kind of follow us on Twitter, we are at skizzle.email. You can basically check out our website at skizzle.email or write into us at hello at skizzle.email. We're definitely looking for people to share some some feedback. And let us know more. Yeah, I mean, you know, if you guys have any questions are more than happy to take them at this point. Some interesting questions kind of emerged. Before I go into the technical question, some of the people want to know more about your product itself. Are you open? Can people sign up with skizzle? Is it free? Are you charging? And when you say the code will be open source, people are asking where it is. Yeah, yeah. So yeah, I mean, you know, we're just getting to the point where we're going to release the product. We're going to be releasing our free plan of our free forever plan in a couple of weeks. And following that we'll have a bunch of paid plans as well, which will basically give you guys more storage. And the ability to perform more actions on the files. And so yeah, the free plan will be out in a few weeks from now. You can sign up on our website to kind of get notified as soon as we launch. Apart from that, yeah, our code will all be like all the important bits at least will be open source very shortly. You can keep checking our website. We'll open source it all. We'll have links to our GitHub over there very, very soon. And, you know, everyone can participate. Go ahead and for bits that make sense, raise issues, etc. Okay, so you explained the issue with malware in an end-to-end encrypted system. But there are issues that blockchain also brings in, right? You are essentially putting, I mean, you are anonymizing stuff. You're anonymizing the content, but you're essentially putting for a fact that you and I have potentially communicated. Yeah, it's probably not known through a public blockchain that it is you and me. But the fact remains that I and you are signed up on Skizzle's network. The email ID are part of your network. Now, when you're talking about malware actors, the kind of actors which are involved in those hacker groups, but also at the same time you have nation-state actors, right? Like when you're looking at nation-state, especially the kind of people who don't want government to know what they're sending or whom they're even talking to, blockchain kind of removes that whole deniability factor. Yeah. So where do you see the issue lies with that? I mean, I know you're trying to anonymize and sort of anonymize things, but say tomorrow you do get a request asking you to give the list of all of the users on your platform, nothing more. Yeah. What sort of threat vector and how can one evade that? Are you saying that you have systems in place that this stops it or are you saying this is the trade-off that we can't take it away? To be honest, it'll be a bit of both, but let me tell you what is currently not possible. If we need to kind of, if our hand is forced and we kind of need to give up user details, that is something that, I mean, if you have to give up a list of user emails, then that's absolutely possible that we'd be forced into doing that. But we don't maintain a mapping of user emails to public addresses. So that is, in fact, is something where Taurus comes in and because it is zero knowledge itself, in a sense, like they maintain that mapping. We don't actually have that mapping of users to email. So this is something that, at least, you know, it skirts the issue. I completely get that. It's something that we have to kind of deeply look at and kind of figure out, you know, going forward, how do we deal with this? Although, so we are dealing with like really potentially very sensitive information that, and we might attract all the bad actors that you can imagine, including state actors. So it's honestly something that we'll have to figure out a way to deal with. We'll have to, you know, probably we'll have to take a call at some later date to kind of deal with only, you know, certain sort of organizations or enterprises and not make it available to the general public at all. Yeah, so the trade-offs do exist. Like no system can be that perfect. No, absolutely. You're controlling it on your own. So the kind of trade-offs that, say, signal is providing. One can't really get them without owning infrastructure or mitigating it. No, absolutely. Absolutely. So yeah, like you rightly said, if you don't own the infrastructure and things like that, then you kind of, you know, you're not in full control. This is something we do want to mitigate. We have some plans, including probably, you know, doing things where we completely own almost all of the infrastructure, but then we'd have to kind of worry about business trade-offs. So yeah, I mean, you know, honestly, this is something that we'd have to deal with. Okay, so the other question I have was on homomorphic encryption. That's a really interesting thing that's like upcoming, yet upcoming. I mean, I think there have been various good developments, but still not there for people to use it at a commercial scale. I mean, I know there is, Microsoft has a product on it. I forgot what it's called. Yeah, Microsoft IBM also has. No, Microsoft SEAL. They have an open source system where people can use it for homomorphic encryption. But I guess it would require some maybe another five years is what I think. What do you think, what would be the time for this to emerge? I mean, it depends on who you talk to, honestly. There are people in this space who are extremely optimistic and are saying things as early as next year. I forget the website, which actually kind of is like a, like trying to be like a central body for stuff that's going on here. It's like an index for all the cool stuff in the HME space. But yeah, I mean, you know, it's been a while coming. We obviously need systems and software to kind of rise up to that level. But I don't, I think the timeline is, is that I think it's one to five years. It's probably when we'll really see very, very cool stuff in this space. And it's honestly hotting up. I mean, I've seen a few startups that are aiming to do exactly this. You know, they're now coming out of like stealth mode, still no details on how they're exactly going about doing this. But I guess that they just looking at the activity, I think we should be fairly close. Okay, I don't think we have more questions on that. But if there is anything that you want to show, I think we have some time. Yeah, I'm trying to remember. What was the site if I can just kind of doing that. I'll probably put it into my slides in my index later on. That's okay. Yes, sure. I think this has been really helpful. More people want to ask my question, my kind of hanks out of this telegram group where all of us are talking about cryptography. If you're here listening to the conversation, you can just join us there. It's t.me slash crypto chat. And you can just search for it at crypto chat. If you're working on some of these issues, and if you have the problems you probably already saw, like some of the problems that my own mentioned, right? Like, how would you start recognizing malbed with the need to use systems? Or if you have questions, you could just reach out to my own. And we're trying to see, I mean, even in homomorphic encryption, right? Like, we're trying to understand what's happening in the space. And if people have new techniques that they are trying to adopt or evolve, I would be happy to listen. Anything else that you want to say, Myra? Then we can end the conversation. I mean, that's about it. Really glad to have this opportunity. And, you know, like I said, if there are any questions, feel free to reach out to us on any of these channels that I mentioned. And, you know, we'll be more than happy to engage with anybody with any interesting questions or feedback for us. Or, you know, if you simply want to be able to try out Skizzle very soon. Thanks.