 Good day. And thank you for starting the morning with us. I'm here to introduce Andrew Mielek. He's the co-founder and CEO of SCIF, which is an end-to-end encrypted privacy-first wallet-native communication and collaboration platform. Andrew previously worked on spacecraft at SpaceX operating systems and spent time working all over Asia and Eastern Europe. Before that, Andrew graduated as the Henry IV, the second scholar from Sanford. Welcome, thank you so much. And hi everyone, nice to meet you. So yeah, we're going to start by talking about basically the stack of how you build consumer applications in Web 3. And so what does that mean not just for applications in DeFi and finance and trading and exchanges, but how can we actually build applications that we use every single day and ideally every single hour? So you wake up, you check your email, you check your messages. How can we rebuild the stack of the way consumers live and work on the internet to be more private and user-owned? So we'll start with just some of the attributes of what we look for in our application and also in all applications in this sector. We'll start with privacy first. And this actually for us at SCIF is probably the most important fundamental layer of how we build things. So what that means is all of your data is owned by you and it's private to you. So no one else, not some technology provider or platform will have access to it. And so it's really only something that you should have access to, which is just also a lot more intuitive for the way we use these really sensitive applications, whether it's file storage or messaging or communication, all the things that we store on those products should really only be known to us. And that's not an expectation that people certainly have today. Beyond that, and we'll talk more about this later, we think it should be decentralized. And what that means isn't always that, you know, compute is taking place all across the world on chain or always on a decentralized network, but it should be architected in a way where your data and your compute isn't always entrusted to a platform. And that translates into the data structures that you might use into the way authentication and identity might work and also into so much more from an ideological side of how might your data be de-platformed if you're removed from it? How would you think about censorship resistance? How would you think about access to it that's always permanent and always accessible? And then also how would you think about just incorporating privacy into every single piece of your data storage and identity? Finally, this one's a little interesting. We think that applications should be interoperable. So when you're no longer asking an OAuth application like Google for your identity, we want you to be able to use that information in other parts of the web. So whether it's logging into another product, storing your data elsewhere, or building really cool API and programmatic integrations to all the files and things that you create. And lastly, we'll just say this very briefly. We think it should be open source, which is something we've committed to at Schiff. But also, I think something that in the entire community of just Ethereum and the crypto ecosystem is really important to make sure people trust what you can do and also can replicate it. So we'll start with privacy first with a pretty intuitive saying, which is if you own the keys, you also own the data. And so basically, everything on the product should be intent encrypted from the ground up. So you're sending a message, keep that message private only to you and the recipient. If you're uploading a file or piece of information, make sure that's also private only to you. We've basically just seen countless examples in the last two years with people storing things on the cloud and being de-platformed, targeted for the things that they store on a cloud provider, or just not really able to understand and trust where their data is being used. Is it being dropped into some massive machine learning model? Is it being used in some massive search indexing algorithm that's also just used across 500 million other users? Your data should be private to you and intent encrypted. I skipped over this, but we also want to make sure there's no personally identifying information inside these products. This is slightly controversial depending on the application, but in the encrypted messaging space and intent encrypted communications, it's really kind of this ground zero expectation that people have, where you want to be able to use a messaging product, you want to be able to use a communication product without giving out a phone number or a real name, et cetera. And so many places in the world now make it harder and harder to do that, whether you need to submit an ID to buy a SIM card or you need to go through an internet provider or an email provider and provide another address or some sort of accountability chain. So that first one's also really important to us. And finally, a lot of these bullet points actually rest on the idea of non-custodial wallets or non-custodial public keys, where if you're doing intent encryption, you kind of have to own your own key pair. And so that poses a bunch of interesting consumer product challenges that we'll get to shortly. So on that next point of decentralized, we talked a bit about how decentralized can lead to censorship resistance, where there isn't a single kind of point of deep platforming where you can get kicked out of your identity or kicked out of your product. And also with intent encryption, it's really unclear even who is using that data or how it's going to be processed beyond just the things that you do with it. This also translates into client-side data storage, data structures, sharing, search, collaboration, and more. So once you've gone down the path of intent encryption, any product that you build will not have access to user data. And what that means is you've kind of set up an entire sequence of challenges and hoops that you have to jump through, whether it's rebuilding how search works, you know, searching on someone's device, or rebuilding how you share that data with other people. So if I want to share a file or a document with another collaborator, how can I as a user do that? But the platform never be able to do something like that. Finally, one super important point is also how you trust the platform and the product as well. And so that comes from how you might actually look up other users' public keys. And we'll get to this later, but this is one of the biggest age-old questions in communication. How do I send a secure email to someone? How do I look up someone's public key if I'm using, you know, Signal or a Telegram Secret Chat or PGP email back in the 90s? And then on that interoperable point, a lot of similar things about basically giving people ownership of their identity through self-custody of their keys or wallets. And then also just using a much more local first on device model, where data can still be synced or synchronized across the devices and things that you use. But because it's NTEND encrypted, a lot of that actual computing power and computing authority is no longer with a technology provider. And then we'll cover some of that last point about command line access or programmatic access for your content. So I guess let's get into some of the actual technical parts of this stack. How has actually NTEND encryption communication been done in the past? We'll start with PGP. I don't know, has anyone used PGP or uses it regularly? Okay, so a little bit. So PGP is, I think, a little over 30 years old now. It was invented or published in the 1990s, I think, 91. And unfortunately, it's become pretty clunky, pretty clunky, very complex and pretty inefficient, where there were proprietary formats owned by corporations, open source formats owned by open source standards, and now just other basically open source publications, compliance standards, et cetera, that try and take this age-old 30-year-old standard and update it for modern cryptography. And secretly, it seems like we have a few PGP users here, but I'm just going to say that almost no one actually uses it. It's estimated that literally 50,000 people worldwide still maintain PGP key pairs. And if we look at the other option for NTEND encrypted private communication, we're literally looking at many three, four orders of magnitude of different scale. And so you can understand why maintaining your own PGP care or key pair is probably a thing of the past. So if we look at signal and telegram as examples, where signal is default NTEND encrypted using the signal protocol, and telegram is NTEND encrypted using secret chats, we get so much more privacy built in right out of the box. So the protocols handle all the stuff around key exchange, key downloading, and actual encryption of messages. And then that leads to, you know, 700 million monthly active users on telegram, and over 100 million on signal. Finally, one piece of this that, you know, is somewhat of an advantage, but also can bite you in the back in the end, is a complex story around key ownership, signup, and metadata. Where if you look at a product like telegram, they're often criticized for not being fully open source, even if some of the protocol is. And signal often is criticized for requiring a phone number on signup, which for some of us may not matter, because we'll, you know, happily share a phone number with friends. But for others, it can really defeat the purpose of a privacy-first messaging product. Now we'll look at one last piece of the current authentication framework. So the last is OAuth, which I think is one of the most painful forms of doing authentication today, because it's basically putting your identity in the hands of one single server and provider. And so whether it's, you know, your Gmail account or another product, you've basically made that, you know, become your identity around the web without really knowing that you really own it. And so the way OAuth works is just for a quick overview. You know, you'll plug OAuth into your app in five minutes. You know, developers have made that so easy. You can query for a scoped token, so ask for my birthday or my favorite color or my email address, and get back credentials that can be refreshed, possibly indefinitely, for access to an application. So a lot of these standards have developed as, you know, the identity story gets more and more complicated around the web, as centralized providers store more information about us, and also just keep enlarging these scopes of data that you could access. Now we'll just flip the paradigm completely on its head. We at Skiff think wallets are just a natural successor to this problem across encryption, across identity, and across data ownership. So we've actually seen wallets start to be used as the basis for generating and 10 encrypted key pairs. And so if you're familiar with the method eth get encryption public key, this is actually an innovative thing published by the MetaMask community and then later adopted into Brave wallet, where you'll turn an Ethereum public key or Ethereum key pair into a curved 2559 encryption key pair, which can be used to just encrypt and decrypt data with your MetaMask or Brave wallet. There's a bit of complication around that as some of the cryptography is ironed out, but it's this much more simple and intuitive way of going from a key that you own to an entire framework for N10 encryption. Instead of access grants, where we'll ask Google or a provider for more data, all of this will be super transparent to users, where you sign a token, giving access or authenticating exactly what you want or exactly who you are. And then finally, on the distributed public key directory, I think no one here wants to put up one of those, you know, HTML only personal pages with your PGP key and then just expect people to go to that if they want to communicate securely with you. With wallets and things like naming services, we get a much simpler way of going from a human readable name like skiff.eth to a public key, and we have some people from the DM3 team here who are working on that exact problem. We'll talk about this more later, but it does introduce some problems on the consumer side with recovery and basically account reset, as we all know, and using a wallet. So just to recap, what's this new model for authentication? We'll start with a human readable name, like, you know, an email address or even simpler. We'll take that and transform it to a wallet address, which is done using a transparent on-chain lookup. And then finally, we'll recover a public key from that. And so in certain cases, we'll get back an Ethereum key pair, or in others like that kind of experimental method I talked about, we could actually figure out a way to get a really well-suited encryption key pair to send data to people and then encrypt it. So now we'll go, we'll kind of completely erase the PGP stack, we'll erase OAuth, and we'll go from this, you know, human readable name all the way to N10 encryption. Much easier than Signal, much easier than Telegram, and so much easier than PGP, which is why people don't use it. So then we'll just cover some about storage and interoperability, a little more on the technical side. So this is a point that I've made a lot, but I think is pretty intuitive as well. If we're moving to a world where decentralized storage actually works for products, we also need N10 encryption. If you're storing data on a decentralized network, you wouldn't want to store it all in plain text. You know, I write a note, I write my PhD thesis, I don't always want every single draft of that to just be stored, you know, sharded around the internet in plain text. So instead I want that to be encrypted, and I don't want that to be encrypted with some random person's key, I want it to be encrypted with my key, and that's exactly what N10 encryption means. So to get basically this value alignment across N10 encryption and decentralized storage, wallets are an excellent solution for that. And then once you've actually published things to a decentralized network, you can use that network to query for it, maintain a list of identifiers, and have permanent access to that outside of any sort of platform, which gets back to that importance of censorship resistance. Then we'll also just talk about the data structures. Let's say you're now using an N10 encrypted product that has no access to the things that you're writing, you're typing, you're notes, your documents. All of a sudden you can't use a single server like the Google model or, you know, the centralized model of collaborating. You have to use a new set of data structures. And so we'll cover this briefly because it's probably a little bit of a tangent, but there are actually really good data structures that are now coming into modern production use, like CRDTs, which are conflict-free replicated data types that actually allow for composable operations to be done on these data structures from around the world. So I increment some number and someone else across the world decrements it. You can see how that operation is composable. And so even if there's some latency or someone gets disconnected, we can arrive at a really consensus-based version of a final product without having a server. The last point about interoperability is that it makes account transfer, sales, and auctions so much simpler. So when an account or identity is transferred on chain, we'll just do that same lookup and the new owner gets access to that username, or we'll just automatically have access to that skip.eth. It'll also mean that users can choose their own history and path around things like 2FA, you know, account signatures and login and all that sort of stuff. So if you want to use a multi-sig wallet for skip.eth, or you want to set some sort of 2FA mechanism or use a hardware wallet, you'll get to choose your own security posture. And so that has a lot of pros for more advanced users. It means that people can choose their own way of securing their private keys, but it also means that platforms no longer have to deal with some of that risk of accidentally de-platforming people, having 2FA and complicated reset mechanisms, and you can make sure that the right identity is going to the right person. It does, however, introduce complications around account reset. So we'll just be transparent about that. You know how difficult it is to remember a seed phrase. Maybe you wrote it down or put it in a safety deposit box, or you split up pieces and gave them to your friend. But that makes building consumer apps a little more challenging too. Like if I want to reset my email address or my messaging app, it's a little weird to ask my friend to click a button or three of them to click a button and give me their, you know, secret out of a few different secret shares, or to use a multi-sig wallet to log into a single collaborative product. So it gives users a lot more freedom and empowerment over how they can use these products and lets you choose your own security journey. But it also means that there's more complexity around account reset, identity, and all those areas that frankly a lot of the regular consumers will get to. And so that's something we spend a lot of time on at Skiff. How can you make products really simple, really easy to use, and really easy to sign up. And so once you get to users who, you know, don't want to remember a seed phrase or write it down on their desk, you actually get people who, you know, have access to all these amazing benefits of end-to-end encryption and, you know, easy-to-use collaboration. But then if they lose their seed phrase, it's harder to reset your account. So to recap on the stack, we talked first about the auth layer, where wallets basically enable this entirely new user-owned flow for authenticating and logging into products. They also give us a much simpler mechanism for distributing public keys. So don't run your own personal site with a PGP key pair, run your wallet, and just basically add that data on chain. So we can go from your human readable name to your wallet address to a public key to end-to-end encryption. From there, the storage layer of using decentralization and end-to-end encryption give us so much more flexibility. You can basically store data in more places or in a decentralized network if that data is encrypted with your key pair. It also means that data is portable. So you want to access it via program or via some sort of command-line tool and change it or edit it or download it. You can do that all from the decentralized network. And then finally on the app layer, there's still a lot of progress that has to be made. So this is basically a whole new paradigm for building a product like Gmail or Dropbox or Drive or OneDrive. I've tested, you know, or our team has tested every single email product out there, every single storage product out there, and it's radically different to build one that's end-to-end encrypted from the ground up and works with people's wallets. So it gives us a lot of benefits of basically this, you know, natural path from identity to key pair. But it also means that we have to rebuild a new stack of consumer apps that do this all behind the scenes, you know, simply, naturally and also really performantly. So that lookup process gets complicated. So I think from there, yeah, I just wanted to add a couple notes about basically how we think this benefits the entire community and ecosystem and then we'll do questions. So my background is I've been a software engineer my whole life since I was probably five or six years old, although I was not a professional engineer at that point. And now actually doing this for real, you can see that this model of building products is just so much more intuitive and better for people and their identity. So if you have a, you know, a wallet or a key pair that you really trust and you want to keep track of, you could choose your own security mechanisms and safety mechanisms for owning that private key. If you want to communicate with people around the world with N10 encryption, you can now get that an entirely new kind of more user-owned stack of products. I've been a big fan and so has our team of decentralized storage and N10 encryption is one of the biggest enablers for actually building consumer apps on top of it. So there's still so much work to be done on the product side, but we think that basically going from, you know, this distributed consensus around public keys to N10 encryption to a lot more flexibility on storage and interoperability. It's just a much more intuitive, better and simpler future that the end of the day is giving people access to what we see as a fundamental right, which is private communication, private writing, private collaboration, and owning your own key pairs. So I think we've got five, six minutes for questions. Thank you all for coming. I know it's early. Go ahead. Ah, so this is a great question. The question was what are the nuances of going from, I think it's just basically a wallet address to a actual public key that you might use to encrypt data? So the nuances are like a wallet address is derived from a public key. So it might be a hash of a public key or, you know, a hash and a truncation of a public key. And that's how you get the, you know, the hex, 0x, whatever. You can't use that hex to encrypt data. It's just basically the hash of a public key and not a public key. So that gives us, I'll just go back to the diagram. So because we can't actually do that, there's now two options to go to a public key we can use for encryption. One is we generate a new key pair that's derived from your wallet address. So derived from your wallet private key for encryption. So you can use whatever elliptic curve you want. So one that's really well suited for that and generate a new key pair. Or in the Ethereum context, you could use an Ethereum public key. So a curve SEP256K public key, which is not really quite as well suited for encryption. It's a little slower and generally not preferred over, you know, like a curve 25519 public key. But yeah, I think there's still a lot of lack of consensus on how to go from a wallet address to a public key or how to use, you know, do encryption and decryption via wallets. Is that the data can be stored in a decentralized way? You showed IPFS. How is this realized in practice on CRDTs when a user presses a key? Is that a new IPFS hash every time or how does it work? Yeah, this is a good question. So right now, basically the way our products work is when a user presses a key, it's applied locally to your editor state. Your editor state is some data structure that's like editors are actually super complicated. You know, we should all go to a conference on text editing, but basically editors store some array of values like headers, body, text, etc. So that gets mapped to a CRDT state, which is just a data structure, which basically like a set of operations on an empty state. And so that operation, you know, I typed a key at position 500, is then sent or it's N10 encrypted, sent across the network to other people who are collaborating, and they also apply that operation. And so you do both do that composably and end up at a final state. From there every so often, and there's another, I guess, like a few little kinks to iron out here, from there your document is N10 encrypted, so encrypted with a key that you have access to and your collaborators do, but no one else does. And then from there it can be uploaded to IPFS. And so there's a few nuances of not everything in real time on our products is uploaded to IPFS, but things that are immutable or static or published can be. So that's how that's done today. But yeah, the whole decentralized storage kind of network choosing is another whole area. Go ahead. So can I just ask then, are your servers, they're providing the IPFS services, that's not decentralized as of yet? Do you have any plans around that or? Yeah. So I don't think we, I've been a big fan of IPFS for like five years and you know, tried running my own nodes, all that. I don't think it's totally feasible for everyone to be running their own kind of nodes in a decentralized network. So there are really great IPFS gateways, you know, for upload and even Cloudflare runs a really fast kind of caching layer on top of the download part of IPFS. So I think basically, yes, there's some, you know, N10 encryption, which is done client side, then it gets passed through some sort of gateway, which is generally centralized. And then it gets put on a network and like the user at the end of the day can get access to those identifiers. So at the end of the day, you still get the benefit of, you know, your data is N10 encrypted, it's put on a network, you can get access to the identifier and the key, but it's not, you know, every single part of that process isn't totally distributed. Well, if any last quick things either come grab me. Thank you all for coming. And yeah, I guess we had that whole power scare. So someone, you know, did some sort of search.