Native Mobile Ethereum dApps: Why, How & What to Do About Censorship – Paul Cowgill

hey everybody my name is Paul Cowgill and I'm with a project called tacit and to talk today will be about native mobile aetherium Deb's thank you so for an outline basically I'll answer why why someone would want to build a native mobile aetherium gap talk about a common concern which is censorship and then show how you might do that the the building of the native mode of bull tap as I mentioned I'm Paul Cowgill that's my Twitter handle sort of an aetherium generalist for the last two and a half years so why build a native mobile aetherium Deb well basically right now we're building everything for laptops but if you talk to anyone who's relatively young or anyone globally they use their phones a lot more than their laptops I know we use our laptops a lot the people that are here but it's sort of self-evident that phones are kind of where it's at in terms of mainstream users there's a lot of talk about progressive web apps as well and those are great right now it seems like the average mainstream user is much more comfortable downloading a native mobile app and people might use a web-based app to start but then if they become a power user they tend to want to download the app so if we have an aetherium dab we ought to be providing experiences like that for those power users so they can do it however they would like to what are some good situations where native mobile makes sense if your target user base is those young or global people if if there's a high-frequency element to what you're doing so like if you're often interacting with the app and or if there's something that it's you have to act in real time you have your phone with you at all times you don't with your laptop right now it tends to be things that are lower stakes that you might want to do on your phone so maybe not buying a $20,000 parcel of decentraland land but again I lots of people like only use their phones and not laptops so people are getting more and more comfortable with doing even pretty weighty things on their phone and then of course if there are any of the features that are core to native mobile that you can't even really do on the web like camera or GPS or biometric off or that at least that it's much more awkward to do on the web those make an app a great fit for native mobile as well and then finally there's a much better data persistence story on native mobile you can definitely put stuff in local storage or use some of the new browser API is on web but you don't have quite the same guarantees for when that data is purged and the the SDKs for interacting with that data just aren't quite at the same level as with mobile we're offline first data is a very common pattern so what about censorship in short as long as you don't have a private key on the device where that phone is the only way that they can control the funds that that private key controls you're pretty much good so two ways to do that or with contract based accounts where the key that's on the device in that app is one of many signers or you can use Wallet connect as well where there's a different wallet and and you're just having the experience in the app but using actually different wallet to authorize that and then so let's you know consider some of these scenarios Apple might remove the app if you have built it and react native which is kind of what I'm pushing for here at least it'll work on Android yeah if Google takes it down at least it'll work on iOS and even if you like have them in both app stores for a while but then it's taken down the beauty of react native is that it's quite similar to react which is what most of your web-based steps are built in already so there's there's tooling like react native web so that you could build it mobile first but have it work as a web experience as well and you can also get clever about sharing parts of the components but maybe not the styling between native mobile and web so contract-based accounts and react native get around a lot of those censorship concerns and finally big coat big tech co companies do change based on the feedback they're getting on a long enough time scale so I think if we enable a lot of DAP developers to make more and more native mobile dabs they'll kind of see that they have no choice but if they want to remain a viable option for how people can download apps they need to accept more and more dabs so I think over time censorship will be less and less of a problem through this channel anyway well so with that address let's talk about how to make it happen the goal here is a simple UX but without sacrificing any of the things that are important to us as part of this movement a couple criteria by which you might evaluate that are one if you or if you have a native mobile app and it goes away one day so your project runs out of money and it becomes stale and you're not able to keep upgrading it so that stays in the App Store the user should be quite sad but they shouldn't be totally screwed so as long as the contracts are still the same permissionless contracts that your native mobile app is hitting but you have a contract based account so there's seamlessly web-based experience through which they can do that as well then that kind of fits with the ethos were aiming for here and also you ought to assume that the user probably isn't crypto native but still offer options for the purists among us so if you want to add more and more signing keys to the contract based account with hardware hardware wallets or whatever more advanced configure you want that should be an option but perhaps buried somewhere a little bit deeper in the settings okay so with those goals in mind what's needed to do this well I've divided up into the onboarding part kind of the ongoing UX and mobile specific stuff I'll go into these in more details so I won't read them off here but the three major categories here and at my project tacit we are aiming to make it as simple as possible to do all those things while building on lots of great existing work in the ecosystem as well onboarding to start I think in order to attract the next wave of users we can't have a two-step process where you first have to set up a wallet and then get to use adapt the setup process for a new wallet needs to be embedded into the app so the SDK powering this is built with that use case in mind and what does that look like so from the test that SDK you can import the the account package or module or whatever you want to call it and just create a new burner wallet that's in DAP and use it from there so not too dissimilar from the way we're buying food with burner wallets at this event here's the point where someone might feel sad that there will end up being lots of different accounts I think in a kind of counterintuitive way that's not actually a bad thing so again if you consider mainstream users they probably don't have another account yet anyway so this is the first account and depending on how heavily they're using the step you can add more and more features so it comes to resemble a proper wallet more and more closely and this can evolve into their main account but also as a crypto native power user it's nice from an object perspective and an accounting perspective to not mash everything I do on web 3 all into one spot I do some games related things and I wouldn't want that intermingled with my dphi activity you can always stitch that together between multiple accounts after the fact but it's much harder to disentangle it if it's all happening from one account in the first place so now what if you want to upgrade the security we'll say of that ephemeral account there ought to be support for contract based accounts as well so you can basically call a count out upgrade with the address of that burner ephemeral account the ENS user name you'd like to use and the type of contract based account that you'd like to upgrade to so it could be a safe could be argent could be a bridge could be aetherium it could be a whole lot of things and I think it makes sense to provide a sensible defaults certainly open to feedback on what that default ought to be but make it configurable between those different contract based account types as well and you can see here from the variable naming that it's creating a create two style contract based account so it's not actually deployed yet but you do get to know the address ahead of time so perhaps in the app only once the user has accrued enough value that it warrants deploying it you might consider deploying it then or if there's another transaction they need to initiate or something like that and then at some point you do want to deploy that contract based account so there's another function you call called deploy and at that point you have a contract on maenette where the username has become the sub domain on that daps ENS name sort of more musing on how this 100 accounts per user thing isn't actually a bad thing depending on how heavily their users using them some of those might be upgraded in a contract based account some might not and they can be split into different buckets of life that users use different type of apps for and I think comparing it with how we use web 2 is pretty instructive here you have different accounts for basically every app you use and I don't see why it ought to be different in web 3 doing things like investing and doing things like having social apps are quite different experiences and again you can always stitch them together after the fact but having them separate by default is quite nice if you do want some of those stitching together features there's always the option of inheriting account recovery settings from your Argent wallet for instance or adding your primary wallet be it a contract based wallet or a regular wallet as an additional signer for that gap wallet or providing a seamless experience for transferring funds between the users main wallet and that in dab wallet the other key piece of this onboarding part is letting the user get money as easily as possible I saw a great talk from Althea yesterday about how sixty-year-old users in Oregon used to have to on board through coinbase but they switched over to wire and it's like dramatically improved the experience for all their users wire doesn't work in every country this is not my tweet but I think we definitely need a thing like this where there's just a single SDK for all of the Fiat on-ramp solutions happy to work on this with people happy to have someone else build this but definitely it exposed something like this in this sdk and the nice thing about that is this is one other thing that makes it less awkward to have a new additional account because you don't have that moving funds from your main wallet problem anymore the second of three buckets for having a great native mobile experience is the ongoing UX piece one keep one key part of that is having an optimistic style UI so basically what that means is yes as an implementation detail you're using aetherium behind the scenes and yes transactions take a while to be confirmed once or seven times but you can be very clever about how you present that to the user so if you take for an example sending an NFT here you can import contract from the test that sdk get the NFT subtype of that instantiate basically associate the ABI that's already part of the SDK with this address and then in a non async fashion do a contract safe transfer from to build this thing you want to do but notice that here we're not awaiting it which is sort of the standard way people tend to do with your iam transactions right now with like ethers or web three and that's because you might want to do something in the UI exactly at this moment and not after having a waited it so after having built the action you can subscribe to airs or one conformation or whatever constitutes enough confirmations from your perspective and then send the transaction and I also like a weight so it might be fair to say hey this seems like a little more awkward way of writing it but I think the benefits outweigh the costs here I know that even though with a weight style you could build it an optimistic style you I I just find that people don't tend to do that it becomes so tempting to await the first confirmation that that basically ends up being what people do another key piece is not having any in order to satisfy that criterion of letting users be sad but not devastated if your app disappears that's nice if you're using a service like the graph rather than having your own proprietary back-end with like a postgrads DB so beyond just awaiting confirmations directly through a library like ethers abstracted through the tacit sdk if you'd like you can also await its presence having been indexed on the graph and the API here looks essentially the same so that's just a nice little convenience feature here and then of course you can do things like querying for like the last a hundred events of things that went for sale on a marketplace to I know that the graph is starting to work on rights in addition to reads too and will likely support that as well so if you wanted as a developer consuming this SDK you could do all your reads and writes through the graph so that you would lose a bit of that awkwardness of the mismatch and API style between like graph QL I mean Thurs ENS is a really important piece you don't want to be throwing addresses in users faces too much so out of the box using since we use ethers Jess under the hood you can send it to anyone with an ENS address and then on the receiving side basically any DAP using this SDK can have whatever ENS top-level domain at once and the user can have a new subdomain on top of that and of course meta transactions are very important in some cases especially when the user is new and hasn't yet been sufficiently motivated to connect debit-card through google pay through wire or whatever so the thing that's different here is this action dots in for free function so there's out-of-the-box support for meta transactions rather than standard transactions again depending on your use case that may or may not make sense for different transactions and then there are the mobile specific features many again for the the user that has never used any aetherium dat before this piece is less important but in order to make it palatable to those who already have a wallet that they really like using making it pretty seamless to move funds back and forth with that wallet is something that ought to be supported out of the box so you can basically pre populate a transaction that you would like to be built in a different app and send that through a deep link so also very interested in what people's thoughts are on what the standard looked like for this and this is a major focus of what we're working on I don't have much to say during this presentation about biometric off and push notifications but just to remind you those are things that are quite cool that are very specific to native mobile and that you want to support out of the box but there's nothing too surprising to say about how these work basically you have the private key and a secure Enclave and you'll be able to perform transactions using that private key after having biometric costs for some period of time yada yada yada at this point I've talked about a lot of features and it might be starting to feel like we're boiling the ocean here I definitely would argue that we're not the team as myself so very much trying to avoid extra work wherever possible so we do use great SDKs under the hood as much as possible and that's one subclass of conversation I'd like to have lots of Eddie's Denver great SDKs that are good fits for being in some cases exposed directly through this SDK or perhaps abstracted a bit to offer some of these features in order to make that work I have felt this pain point with some other JavaScript SDKs it can be tempting if you're mainly considering a browser environment to use a lot of the new browser api's but the more you do that the less isomorphic that javascript is so if you're gonna do that at least maybe make an abstraction layer around that and then hit the browser api's so that becomes simpler to swap out those pieces for the native mobile equivalents [Music] scaling and privacy are two extremely important topics and I think for this project we're still at the stage where we're keeping an eye on what the community gravitates towards they're obviously layer 2 is very important east to is coming quite soon and there are lots of great privacy preserving technologies like nightfall for instance coming out very open to folks input on what makes sense in a mobile environment here but kind of too early to say right now look for look for over the next six months and now it's myths about well mate we might be doing with on this side of things so to wrap up this is a super controversial point I argue about this on Twitter a lot depths depths do already offer value to me in very tangible ways that I can't do with lots of web 2 apps just like a super trivial example spinning up a multi-sig is so cheap and so fast and offers something that there's no way I could have done otherwise so if that's the case that lots of lots of us at this conference are getting tangible value from taps then the only problem is the way they're packaged regular people have some of these same needs like managing funds as a group that's a pretty common social human issue to come across so if we if we deliver apps where the users are in a way that can understand we can see like 100 X thousand X growth setting aside the scaling of discussion for a moment right now and so I think by building layers of abstraction like this SDK we're working on it enables a team that has made a mobile app before but hasn't gotten too deep into the etherium ecosystem but a very talented web to product team to start delivering value to users using aetherium during the course of the rest of today and tomorrow and also just an ongoing fashion actively looking to talk to users who would be interested in using native mobile apps and even more importantly timing-wise talking to developers about what it would take for this to be the right fit for you to build native mobile apps with so again here's my twitter handle feel free to reach out to me or just find me at the conference one cool announcement we got some funding to build this from the etherium foundations the first told anybody that for the most part so pretty excited about that yeah thanks and also have lots of generous support through the Nokia nose this ecosystem fund and get coin grants so thanks to all those initiatives and then here are a bunch of URLs feel free to go to any of these I know it's kind of overwhelming or take a picture have a good idea [Music] you