Onboarding mainstream users into Web3 with Collab.land, Discord, and Lit with Chris Cassano

[Music] Yeah, let's do it. All right. Hello. Welcome to uh our talk on. Yeah.

Or we can we can pass it back and forth, too. But yeah, that's probably better. Uh we're we're going to talk to you guys about onboarding mainstream users into Web 3 with Discord and Lit. Um this talk is about how you can use Lit with Discord to super easily onboard your users with wallets. So hello, welcome.

Uh my name is Raymond and I work for Bridget. Uh so I'm so glad to be here on the on the stage with Chris. We have been working so hard together for months because we are doing very interesting joint research project um to figure out what's next for onboarding massive users into web street. Yeah. So Raymond, do you want to take us away and explain your dream wallet?

Uh, yeah. So I have been working on crypto for two years and I come to crypto from a traditional web 2 background, right? So even though I claim myself as a technical person, but I still struggle quite a bit to onboard myself into web 3. Uh, and the first thing we are thinking about is a wallet, right? So the wallet is your ticket to web 3.

But as at this moment the wallet has a lot of issues and the most critical one is I have to take the full responsibility to take care of the safe phrase of private key. Uh I don't know how you guys uh store your private key. Uh I wish I could just uh dig a hole dip it in the ground and bury that right. So I don't want to take that responsibility anymore. uh and secondly I want to have more flexibility so I can progressively you know take over the responsibility so I don't like have my wallet to be owned by Coinbase but on the other side I know a lot of user want to start from there right so we want to provide pass to the procept uh so of course like as a wallet I want to have multactor authentication and provide that you know uh guidance social recovery all this good stuff Um then incrementally as we getting deeper into the web three space then you use a wallet for different purposes right you could use your wallet as a decentralized ID and assign message to prove you you know did that thing or get a credential out of it or you can do like a meaningful transactions depending on the nature of the wallet I need to have a way to incrementally upgrade my security enforce the different authentications and provide a meaningful authoration right and and And people also really scared about signing anything today, right?

How do we make that signing process a joy instead of a scare, right? Have meaningful message, even have a preview of your transaction and even allow yourself to decide what's a criteria to sign that transaction. So all these uh steps will help us to have a much safer place to be. uh and uh of course like uh account abstraction is cool and it just arrived. I'm excited about it.

Uh but still there's some nuances for example I have to deploy the smart contract into the blockchain I'm integing with. I don't have a universal account abstraction for myself. I may mix mistakes say hey I have this account abstraction on mainet then when I work with polygon maybe that's not my wallet anymore right? So those are the things that of course like as a technical guy I really want to have that flexibility. I want to make a like offchain smart contract to manage my wallet.

Not everything in chain but it's a coll cooperation between onchain and offchain. So those are my like wish list uh I I bet each of you have probably more on about it. Thanks Raymond. So I want to talk about how like what is lit protocol and how it can enable the dream wallet. So, LIP protocol is a threshold cryptography protocol.

We're trying to decentralize public key cryptography itself. And the way that uh threshold cryptography works is you do a process called the distributed key generation. This generates a public and private key pair, but nobody knows the private key. Instead, each node only has a share of the private key and the nodes can both sign and decrypt with those shares. the user has to collect signature shares or decryption shares above the threshold in order to get back the uh get a signature or decrypt something.

Um and so we uh have a network that's live right now, but we're running all the nodes. We're working on decentralizing it. Uh it should be decentralized soon. And this is kind of like what it looks like uh to use lit to sign a transaction. So on the far left you have uh IPFS lit has a system called lit actions that I'll get into in a minute that basically lets you run JavaScript programs across the lit nodes in the middle and so you could have a program that like does authorization uh you know anything you need and um if the you know the program completes then the nodes will sign at the end and uh with their with their private key shares and then the user collects signature shares from threshold of nodes and can create a signature and you can also um and so this is like kind of the right use case for signing.

You can also do something similar uh for access control where you can encrypt content and you can say something like you can only decrypt this content if you meet a certain condition like the user holds an NFT or the user um is a member of a DAO. And so that that's like what this flow looks like where the nodes would actually check the blockchain and then if the user meets the conditions they'll create decryption shares the user can combine them to get back the decrypted data. So how does lip protocol enable the dream wallet? We have a thing called programmable key pairs that we call PKPS. Programmable key pair is basically a threshold key that anybody can own by simply minting an NFT.

You can also transfer the key by trading the NFT which allows you to actually trustlessly trade or sell uh private keys themselves that break soulbound tokens amongst other things. Um but that enables a cloud wallet where the nodes are the ones that actually custody the key for you. um that we have a system called lit actions which is a fully programmable JavaScript runtime that gives you access to the underlying cryptographic primitives that the nodes are able to use for threshold signing and decryption. And so that gives you the flexibility to kind of like do whatever you want with threshold cryptography. You don't have to like set up your own network of nodes, threshold nodes to do things.

Instead, you can use our network and just write some really easy JavaScript. And we worked really hard to make it so that you can do things like import regular node modules and uh you don't have to like use assembly script or anything. It's like actually pure JavaScript. And we also enabled you to talk to the rest of the internet via HTTP calls. You can use fetch and so you can pull outside data in.

You could use a lit action like an Oracle. Um the possibilities are really endless. I mean you could say like the user is only able to sign like on Tuesdays and you know pull down like what the date. Um and the other thing that we have is OH helpers. And OH helpers enable OOTH and web ain.

Um and what that means is that uh the user doesn't have to have a seed phrase. Instead, the user can log in with uh like Google or web aen um and send their access token up to the nodes and the nodes can actually check their identity and prove it and you know then can tell if they're actually allowed to sign or not. So this is an example lit action. Um, and you can see up at the top here, uh, we define a function that will be run and we define the the string hello world for testing as an array, but it can be any data that you could sign, right? You can sign an Ethereum transaction.

You could even sign a Bitcoin transaction if you wanted to, I guess. Um, and then we have a uh a function right here, lit actions.sign that sin CDSA that actually goes out of the JavaScript context into the Rust context because we're our nodes are running Rust and um tells the nodes to use their uh their key share to sign and there's an authorization that happens in the background here uh to make sure that the user is actually allowed to sign. This is like a kind of a little complicated diagram of what it how it works, but you start at the top right up here and the user has to off with lit somehow. Um in the case of uh the project that we're working on, the user auth cryptography scheme uh and the lit nodes like take that signature or that that authorization proof and uh pull down the lit action code which is like the JavaScript code that's stored on IPFS immutably and they execute that in the JavaScript runtime over here and uh they're able to use the cryptographic primitives like the threshold private key share um from the nodes and the JavaScript runtime is also able to access the whole rest of the internet by using an HTTP request.

You can pull data down from blockchains. You know, there's like a lot of things you could could build with this. Um and if everything checks out and the uh JavaScript creates the share, then the uh signature shares get returned to the user. They could be in a browser. They could be a Discord user.

Um, they combine those signature shares and then you can broadcast that signed transaction. So, what other use cases does LIT enable? Lit enables signing automation. So, you can uh because the nodes are custodying your private key. You can uh set up things like limit orders, dollar cost averaging.

You can have it sign in your sleep and you don't need to like like the way to do that right now, right? It's like a trading bot. You have to h have a hot wallet. It's pretty scary. Uh it's a big target to be hacked.

Um, you can do a PKP vault because you can trade one of these PKPs as an NFT. You could fill it up with all kinds of assets. You could put Bitcoin ordinals in it. You could, you know, put a thousand NFTs and sell the underlying private key and trade a thousand NFTs at once. You could do it uh cross-chain messaging uh because you're able to read and write from blockchains and you can sign everything.

Uh since the lit nodes are able to pull down data from the internet and sign things, you could uh use it as an oracle to you know create signatures of any like data that lives in the outside world. Um you can do things like locked NFTs where only the owner of an NFT is allowed to decrypt it. Um you can do certification and proofs which is kind of related to sign everything but it's like kind of conditional signing like uh I will only sign this you know if these conditions are met. Um, and because it happens across all the nodes and we have a two-thirds threshold, two-thirds of the nodes have to agree. Um, and so you know that like you had a sort of consensus on what that thing that you're trying to prove is.

And you really can build anything you want with uh decentralized signing or decryption. Uh, and and if there's something you can't build, come talk to me and we'll figure out how to change the system so you can build it. Um, we have the docs at getlit.dev, so definitely check those out. Raymond, do you want to talk about the some of the challenges of building the dream wallet with lit?

Yeah, sure. Like we have been really excited about this new paradigm because to me the only responsibility to have a wallet is to sign and to sign safely, right? Because otherwise nothing could happen and uh to me as long as we figure out a way for the wallet to sign meaningfully for you, that's the end of the you know on boarding journey. And uh when I uh work with uh Chris and his team uh we really try to drive the developer experience from the real world use cases. uh we designed some scenarios and try to enable these scenarios with the infrastructure from L protocol utilize the actions as a specialized offchain smart contract and we build a you know a middleware t on top of the blind signing because the demo the the code that Chris had early on it's either just uh sign a fixed message or just sign everything right but that's not good enough for a typical use case So that's why we kind of going deeper into that user uh expectation from the developers point of view and we ran into a a few nuances but we were able to work together and put on uh a good fix behind that.

So the first one is uh you know for the let action as a javascript function you need to have a source of truth and let use the IPFS as a immutable storage so that when you deploy that code uh just like a smart contract you cannot touch it anymore right that's a source of truth which is the IPFS hash ID that you as a user will authorize your PKP to run that code on behalf of you but more nuances we want to as uh you know IPFS infrastructure is not so reliable and sometimes it just like fail to load that in time. So one idea we come up is what if we also allow the source code to be passed to the network directly then we calculate the IPFS hash ID on the fly and if that IPFS ID match your authoration we can still accept it. So this is a a easy like you know uh in place uh source code but we still guarantee the integrity of your uh authorization. So that's number one. Number two is talking about our potential use case and the scale to support millions of users from disco from any app web 2 platform uh which you know the tokenized communities are collaborating together right so we need to have a higher we need to deal with the concurrency executions for example a lot of you know backand has limiting right so imagine you want to authenticate with uh uh discore Right.

So you uh need to get the access token and inside the let action which is a JavaScript function. We need to make HTTP calls to discoial really represents a user that has been authorized as part of the access control. Right? So that gave us uh you know some interesting challenge because this is a threshold based consensas decision making process. Multiple actions will be triggered uh by one single client to run the same in parallel and then make that you know two out of three decision.

So that creates some traffic to the back end we depends on. So we need to figure out how to deal with that. So that's the second one. And third one is uh as part of the you know smart contract you want to have some helper. You want to have some utility to do all this is common things right for example you want to verify the signature you want to you know have a way to talk to the smart contract that sits behind the blockchain that provides the access control.

you need to figure out the different authorations uh being given for that PKP. So those are the utilities we would expect uh do not repeat yourself and have the wrong time to inject these utilities to the JavaScript function based upon your requirement. So this give us a very meaningful dependency injection. So we can do these things in a uh reliable and you know do not repeat it yourself way. So that's number three.

Uh number four is uh now if you have a PKP right that's your public facing you know identity and uh to enforce the access control you need to attach some other identities with that PKP say if you want to authorize your disco ID to that PKP you want to authorize your email with that uh then there's a privacy concern right you don't want to disclose your disco ID Google uh ID your email in public blockchain right so that's another interesting concern like on one hand you want to make sure the ACL or onchain has all the knowledge but on the other hand you don't want to disclose all the details right so we did a little bit research into that so the first approach is we kind of hash this uh value onto the blockchain and only the action itself can understand that mapping uh another way is we kind of break the data into offchain state and onchain state. So for example, we can build all this knowledge into a mer tree. Then we store the root hash of the merker tree on chain. So anytime you present a proof to the action to check the integrity of the access control, then you just have to check if the proof is part of the root hash on chain. So this way we can have a good you know uh best braids approach to minimize the onchain data but we still keep that you know data integrity in place.

uh so I kind of hint that number five thing which uh you know sort of becomes a potential solution for the privacy concerns. Yeah. So I can continue a little bit. Uh so of course like we build something for a purpose right and we fully drive the design and the research from the real world use cases. So we do have a couple of things in our mind how we can unlock the value of the PKP.

So we can help our users. So first one is we want to emphasize this wallet as a onboarding insurance and don't emphasize too much on the financial side of the thing. So just imagine this is your first decentralized identity you come on board with web 3 and of course as a blockchain user uh which is kind of the first class synonym for web 3 you need to have the ability to receive some crypto assets as a starting point from some sponsorship right so it's very much uh you know you go to a party you get a a goodie bag and in that goodie bag you have a a bunch of things then with that goodie bag there's a ticket that you go to the next party. Right? So that's uh sort of our idea like how we can potentially use PKP as a meaningful way to onboard like crypto curious users into the uh full journey step by step.

Uh second one I want to really emphasize we are kind of blending the the barrier or the boundary between onchain ownership and offchain ownership because of course like funible tokens non-fundable tokens are well known to crypto savvy users as a source of digital ownership right but really it happening in the real world you are getting a lot of digital assets by yourself. Imagine uh we are talking here then you are you know have your attendance in this conference right uh or like you get a certificate from your college or even like between the different parties I can issue so-called verifiable credentials basically it's just a sign message which has the stand from the issuer and also have the recipient and another wallet or another decentralized ID then we have a claim So everything is digitally signed to protect the integrity of that claim and that could be independently verified. So these verifiable credentials are becoming even more important for us human beings in this society not just say you can use money to buy a lot of digital asset which are funible tokens and nonfungeible tokens. So those are the interesting use cases. We really try to connect the dots here and a lot of PKP the real key to unleash the value for web three and of course we hear a lot of announcement a lot of excitement like say hey a abstraction has arrived right and uh we kind of really like that uh movement and we see uh the MPC wallet and some other way to do the key management and onboard users uh together with account abstraction will really becomes a real marriage made in the heaven.

So we try to create this best of breeds best practice and uh enable user to have their own choices and provide this incremental upgrade. Yeah, that's absolutely right because with account abstraction you still need something to sign. you still need a designer. And so, uh, combining lit with a kind of abstraction, like just the possibilities explode in what you can build. All right.

Yeah. Yeah. So, yeah, that the future is bright. I mean, we're we're really excited to see um like what becomes of our little research experiment and uh really excited to see what you guys can build that is like similar or or interesting to really help uh bring more users into Web 3 and uh you know, not have to worry about seed phrases and things like that that are just like such a drag for the average user who's like it's like write down 24 words and you're like I'm on a bus like I there's people behind me like I can't you know no other uh product has that amount of friction. And so if we want web 3 to win, we have to really reduce the friction I think to the web 2 UX par.

And then I think we have uh a few minutes left. So if anybody has any questions, uh be happy to answer those. Thank you. Testing. Um, so in the event you know you have this nice frictionless kind of onboarding experience and somebody's using like a phone number or an email to access this wallet.

What are your thoughts right now on let's say that advanced user who says well actually I don't like that this is accessible through my email and I want to you you want to do that progressive decentralization and they want to revoke that access and maybe just go with the seed phrase right yeah that's very possible um I mean we've designed this so that you can uh do what what many people call eject from the ecosystem so yeah so if you if you want to uh to use a any any like o method that you want that um isn't supported by default, you can do that. Um the you know, we have like a series of smart contracts that you can use to uh create permissions. And so it's basically like as easy as you know, if you have a Discord wallet and you're like, "Oh, actually like I got a ledger and I I don't want Discord to be authorized anymore." You uh would use your Discord wallet to authorize the ledger and then you could use the ledger to revoke the ability for the Discord wallet to sign anymore. Yeah.

Yeah. Just to add a little bit color to that, really the key here is to decouple the key management from the interaction and controlling of the signing process. And when it comes to the controlling of the signing process, it's really this uh fine grain incremental oseration we can do and enable user to pick up the right path and even learn from the the community. we could have uh uh you know welldefined templates for them to define different kind of rules. Then from the credential perspective imagine you are part of a disco community and you get your first PKP wallet.

So of course at that point your disco ID probably it's the single controller of your wallet that's fine because at that point there's no you know meaningful assets in that wallet. you're just doing some you know uh experiment with the web street journey right then over time say hey I'm really like this wallet experience and I want to use that for small transactions like say I want to send a a tip uh inside discore say hey I want to give you know some tokens to Chris so that involves uh the next step of the journey which uh is onchain transaction so maybe this is a good trigger we tell the user hey now you try to do an onchain transaction, you the better upgrade your security, right? And that upgrade could be a traditional 2FA. Say you need to, you know, uh register secret and you kind of do that from Google authenticate to get this sixdigit uh code and use that in addition to the disco ID. Then from the disco ID perspective, because that's tied to a disco user, it's not tied to application ID, right?

So maybe you want to protect the user. You don't want to allow some third party app to you know trick the user to get access token for their disco ID then use that access token to unlock the PKP. So the user can decide I trust this bot application from XYZ but I don't trust this B application from ABC. So that means he can add one additional factor to the system that only the access token coming from you know XYZ can sign the transaction right then even more like say hey not not only I'm sending five tokens to Chris I'm sending like 1,000 tokens right so that move the next level so I would say oh maybe you need to enable the pass key right because to me pass key is the other side of the world like you have everything local on your device and provide this you know key management and have a meaningful signature exchange between your device and the sound service out there. So this PKP really it's kind of the the buddy the the um in the cloud then you kind of have a remote control to control what you do.

So for that to happen say you want to enable your pass key so that you have to sign with your pass key in addition to disco or you say I need to have a meta mask wallet and I use that manamas wallet to sign a message in addition to the disco credential in addition to the pass key right so this is really the the idea like we have this incremental path depends on the nature of the usage of the uh PKP you will be uh you know put into a guard rail uh getting there step by step as you are learning the responsibilities you are taking more responsibilities. Yeah, that's right. And if you guys aren't familiar with pass key, just to make sure that that's totally clear, that's the Apple implementation of web aen which is um it's like basically you scan your face and uh you know create an account and it's like a single button to do this within your phone and it takes a it generates a private key for you to use for authorization, signing into things and syncs it across all of your iCloud. Um, so if you lose your phone, you can still get back in. And, uh, I I think that's probably one of the easiest, like most secure onboarding flows for new users.

So, we're really excited to see um, what people build with this. And, um, yeah, check it out. Get.dev. Thank you.

[Music]