ENS Identity in Your Apps I Greg Skril

Hey everyone, I'm Greg. Excited to be here with you today. Um, I'm going to try I'm just on a monitor, but I'm going to try and keep the chat open side. So, if you have questions throughout, feel free to ask. Um, and if you have questions after, also, you can ask then, and I'll get to them then.

Going to try and keep an eye on everything. So let's get started. Um first of all again I am Greg Deal engineer at ENS labs and today we're going to be talking about ENS as a source of identity in your apps. So I'm going to start with the basics and then get into some more specific examples of how you can excuse me how you can use in us. Okay take it slow.

So I have to move the chat so I don't cover my own slides. Okay, should be fine. So ENS or the Ethereum name service is a decentralized permissionless naming protocol that lives on Ethereum and scales the entire internet. At a high level, we turn complex hex addresses into human readable names. So obviously in crypto there's um addresses everywhere like this one ox179A so on and that is very confusing and bad for user experience and new users just don't understand what that is and so ENS prescribes names like Gregirl to the addresses and the goal is that anywhere you see an address or anywhere you would have seen an address you can instead see a name and we like to think about ENS as a user experience protocol we exist to make your application and Ethereum and really all of crypto easier to use.

You can imagine the before and after. It's like you get coffee with somebody at a cafe and the before is having them pay you back in USDC to you know some some long address. And this obviously you can't say you can't remember um if you do say it somebody's going to type it incorrectly and so on. And so you'd have to copy and paste it into a chat app and then they'd have to copy and paste it into their wallet app and then you'd have to double check it and this whole thing that's annoying. And the alternative is just saying send me $5 to direct scroll.

And that's easy to spell, easy to say, easy to type, much better user experience. And this is kind of just talking about ENS as a username. But really over time it's gone from just a username to more of a well-rounded profile. And so this is a view of my ENS profile. You see the name up here.

I'm not sure if you can see my cursor, but you see the name Greg and my address. Um, but you also see a bunch of other things. So, I have this banner image and I have this description saying that I like baking and building apps on web3 protocols and um addresses on different blockchains including non EVM chains like Bitcoin and Solano. Um and you see links to social records and kind of all this different stuff. And so again, this is just to say that ENS is not just a address to a name mapping.

It is more than a username. It is really this decentralized profile. this portable web3 profile that goes with you across web 3. And if you have an ENS name um or I guess in this slide, even if not, you will probably recognize this flow. You [clears throat] know, when you connect to an application, you will press a connect wallet button and then see maybe like a gray box or a random generated image and your address.

And this, you know, is your address, but it doesn't feel very personable. It feels very random almost like when you get an email um like a marketing email and it literally has curly brackets around like insert name here or something. Um and this is just the experience that um is very common around crypto around web 3, but we don't think is really good enough that feels bad. Nobody likes that experience. And so if your application integrates ENS and a user comes to your app that already has an ENS name, their experience is much better.

They press connect wallet and they are greeted with this um their name, their avatar, any other relevant information that you might want to surface in your app. And it's really just like showing up with your account. They know who they are, you know who they are, and it's a better end to end experience. And these are just a few examples of kind of how it shows up in the wild on snapshot.org, which is a popular governance app.

um I will go there and it recognizes me as Greg Shad. It shows my preferences and all this stuff even if I haven't signed in before. Um and so it's better for the app developer because it also brings context to the app. Um and another example down below basically same thing. You sign in and you see your profile and it feels great.

Um another comparison before and after and I see some questions coming in that I will get to in a second. Um, this is on Etherscan. I send a transaction to a smart contract and that smart contract has a name. I can very easily see what's going on here. Maybe especially if I saw the like function name or me receiving something in from real Cameron.

This is very easy to see just Cameron to Greg. Um whereas the two kind of counter examples below a random set of characters and numbers sending something out to another set of random numbers and characters. And this is uh you know kind of meaningless. I don't know what's happening here. I'd have to click in and look at a bunch of information to figure out what that is.

So the point here is that ENS brings context to your apps. This is kind of from a reading past actions perspective. And then on the right is sending assets to an ENS name very easily. So this is um the most immediate like use of ENS which is again the the username part. So it's like profile type thing on the left, usernames on the right, just to reiterate.

Um and yeah, like I said earlier, the idea here is that users of cryptoowered experiences should never have to interact with a hex address. ENS is here to solve that. And really, anywhere you read or write a hex address, you should be able to use an ENS name. So, those are kind of um the basic intros, what your experience might look like before and after um why you might want to integrate ENS and stuff like that. I'm going to take a second to catch up on the questions and then we will move forward.

Okay. Are the nonthereum addresses verified or could you add any address? um it is not verified. You could add any address to a name like this. And then in an upcoming slide, I'm going to talk about a um kind of a reverse process that verifies an address for a given name.

Um yeah, and so this data is just write only. I could write anything here. It doesn't have to be an address that I can control. And then next, how can we claim a free ENS name for the hackathon? that is part of the ETH global hacker packs and um should be accessible to everybody, but we can probably help you with that afterwards.

Yeah, it's more of a a tech thing, but we'll get you sorted. Maybe send a message in the Discord channel um so we can help you with that later, Jack. I think that was And then there's another question. What about multi-chain? Um yeah, many of the addresses here are in multiple chains.

So the name by default a name lives on mainet Ethereum and you set your address for different chains but still on L1. So L1 is like where your data lives and it can point to data on other chains. Um it is possible to set up ENS names in a way where the data itself like these text records or these address records are stored on other chains. Um and I believe I will get into more detail on that later. Um, and if not, you can ask again later and I'll make sure to go into more detail, but just want to make sure we get through the core parts.

But thank you guys for asking questions. I think it's it's nice to stop halfway and ask questions instead of going all the way through. But hopefully that kind of helps for Okay. Um, cool. So yeah, basic intro to ENS and why it's important.

Now, how does it work? So there are two main processes in ENS that are important to know from the get- go. There is forward resolution which is the ability for a name to point to an address on any number of chains. So for example, Nick is an ENS name and it resolves to this address ox8 C2 so on on these different chains and so if I am in MetaMask or Rainbow and so on and if I go to send Nick.eth ETH assets on these chains.

I can just type in the name instead of copying and pasting the address and it is an easier way to send assets to Nick. The opposite is reverse resolution. So it's a mapping of an address to a name. And this also exists on multiple chains. So I can have my reverse record on Ethereum mainet be different than my reverse record on base or optimism or something like that.

And the way you can tell for sure that a person controls a given name or rather that an address and a name are um verifiably linked is if both of these um kind of equal the same value. So if the name points to the address and then you look at what name what address the name points to and these two things are the same then you have what we call a primary name and a primary name is really your source of identity on Ethereum. That is what allows apps to safely show instead of 0x179A that I am Greg ETH and this is my avatar and stuff like that. So the primary name is kind of the culmination of those two features. Okay, I see a question that yes, we will get on to a bit later.

Um, and so yes, these reverse records again this part, the bottom part are available to set on um, Ethereum mainet and then five different L2s that is not currently available on non EVM chains, which I think was one of the questions earlier. So yes, this the verifiable addresses are only on these chains um and their respective test nets for the sake of hackathon or or development. Um and the contracts that enable you to set that reverse mapping are very simple. you know there is a set name function that any um address can call on its own whether it's a smart contract or a EOA and then there's also a set name for address which allows you as a developer to sponsor the setting of a reverse record basically and so you can have a seamless experience for your users and there are example repos that you know make this super easy to do if that's something you're interested in and that really makes for the optimal user exper experience. They can sign into your app.

Maybe you can Oops. Maybe you can give them a name for free, which we will touch on in a bit. And then you could sponsor setting their reverse name. So whenever they go to other apps and your app, um you can kind of recognize their profile as again this portable web 3 profile. Um and yes, this names this works for both EOAs and smart contracts.

So smart contracts can have ENS names and they can have primary names as well. Okay, so that is um the more like obvious features of ENS I would say or the ones that have um yeah gotten the most attention. Then a few other things that I want to touch on. First is decentralized websites. And this has been possible with ENS for a while, but we're talking more about it as Cloudflare is starting to have um more outages even like during Dev Connect.

Um Cloudflare went down, but decentralized websites on ENS could still be used. And this was a really cool way to demonstrate why it's important for crypto websites and especially at this hackathon being for DeFi. Um, for DeFi websites, it's important that we're not dependent on a single company like Cloudflare to keep all of the websites accessible. And here's a kind of um, maybe overwhelming diagram that shows the process of deploying a decentralized website on ENS, but I'm just going to break it down real quick. Um, basically a decentralized website on ENS is the combination of a few pieces of technology.

I can upload my website content to some sort of persistent storage like IPFS or Swarm or Arweave or kind of any decentralized storage network and then store that hash of that content um basically in my ENS name and then there are a number of gateways that will easily allow you to access that content um in a much easier way. And so on the upload side, there's a tool called Omni Pin, which I believe I will link to later. Um, that allows you to kind of coordinate all this stuff. And then on the gateway side, there are a number of options. Um, and I spelled Vitalic wrong, but anyways, if you've followed Vitalik's blog, um, you might notice that he shares it as Vitalic.

Or ETH.Link. And these are gateways that in the background fetch the content hash record which is the hash of the the centralized storage upload from your ENS name. They serve that content to you under a domain. And so it's very easy for you to access this content under vitalic.

link. Um and this is meaningfully decentralized because there are a number of these gateways like limo sucks and so on. So e.link e.limmo limo.

Um, but the coolest part is actually that you can run your own gateway. And this is the most decentralized way to access this content. And so for example I run I run one under my you know local network where I can access Vitalik's blog or I can access um our ENS application or our ENS documentation fully decentralized through my own Ethereum RPC through my own IPFS gateway and through the content that Vitalic or ENS has kind of declared official under its ENS name. And so this like decentralized website stack is something that we want to push a little bit harder and I think is important to highlight in a DeFi hackathon where um your smart contracts may be decentralized but there has to be an easy way for people to use that as well. So that's an area we want people to explore with.

Um another cool area to explore is custom text records. So ENS as I showed in the profile earlier has a number of text records which means arbitrary which are arbitrary key value pairs that are just string to string attached to any NS name. And so for example a common one is the key avatar and the value is a URL that points to a profile picture. But there can be really cool ones that store things like payment preferences or DeFi um patterns. And what this might look like as a hackathon project is you set a text record key that is like preferences or something.

And the value is like a stringified JSON object that has the chain and the asset that you want to be paid out in. And if you're building a wallet or an app that transfers assets, instead of um letting the user decide, the one who's sending the assets where the assets will end up or just assuming that the receiver wants to get the same asset that the sender is sending, if that makes sense. You can intelligently use this to basically route assets to the place where the receiver wants them. And so say you have ETH on arbitum and I say back to the example, send me $5 for coffee. Um, you shouldn't have to ask me what chain and what asset I want the $5 on.

I should be able to just say send me the $5. And so a hackathon project that could be really cool is coming up with a standard that allows me to set a text record that says my preference for payouts is always USDC on base. If I say pay me $5, I don't care how you pay. I want it to settle in my wallet in USC. And then the hack project is kind of the standard for what defines that text record.

Maybe it looks like this. Maybe it's something else. And the router logic that um you know swaps the input token for the output token effectively. Um and so that's you know one idea for you guys hacking this weekend. Um, yeah, maybe let's see if there are good questions here or at this point, let me just get through it.

Yeah, and then I'll do the questions. We don't have that much time left, so I'm going to try and speed up. Okay, things you can build. ENS is the type of thing that fits really nicely into existing projects, more so than a specific project on ENS. Um, the text record thing that I just described is an example of something that could be a inclusive ENS hackathon project.

It's just like the brainchild of this payment preferences thing. Um, but in most cases, it's like you're building an agent or you're building a wallet or a social um app or anything like that. And ENS can be used to improve the user experience of that app. As I said before, ENS is a user experience protocol. So it is more used to improve existing apps than um to build specific apps for yourself.

It's like part of the journey, not necessarily just a destination. And yeah, so if you're building an AI, think about how you could give your agents usernames with ENS. Or if you're building a wallet, then make sure that every transaction history shows the ENS name that you're sending assets to. Um, and in a social context, maybe it's more obvious, like all the profiles are ENS names. And any sort of website can be deployed to ENS using the content hash record.

So, any app that you're building probably has a good way to be improved by ENS. Um, and that's kind of what I want to get you guys thinking about over here. And yeah, I'm covering my slides again. At a high level, it's like anywhere your app shows a hex address, it should instead show ENS names. And I know this might sound obvious, but I've talked to so many hackers who will be building for a whole weekend and then they come over on the last day and ask how ENS can be used and they'll just like show me the app and like, oh, hex address.

We don't like those. You know, uh that could that could and should be a name and it will probably improve the user experience of your app. So literally just look at a demo of your own app and see where their hex address is and figure out if and how ENS can be used to improve that. When I say has ENS names, um that could mean either they have their own name like Greg.eth or if they don't already have one, they being your user, you could um issue one for them.

And the easiest way to do that usually is a subdomain. So for example, I have projectname and I wanted to give a username to all of my users that don't already have an ENS name. And so then I would have Greg.name.eth.

And there are many different ways to do this. I'm not going to explain all of the different options here, but a very popular one and um people's hackers favorites because it's, you know, fun to play around with is this project called Duran. And Duran is basically an opinionated way to give subdomains on a layer 2 of your choice. Um, and it's kind of a step-by-step process that has detailed information and is really a fun um path to go down. So hopefully you got the chance to scan this QR code.

Otherwise, it will be available later as well for issuing subdomains to your users. Primary names, I talked about it before um but I'm just going to give you a few seconds to scan a QR code if you want to read some more docs about it. Again, the ability to go from address to a name and what makes ENS this sortable this sort of portable web3 identity. And with all that, um, maybe the information was a little scattered, but hopefully I got enough of it out. Um, our prizes.

So, there are two prizes for ENS at this hackathon. The first is just a full prize. Anybody that integrates ENS will be eligible to win part of a $3,500 pool prize. This could be as simple as implementing ENS resolution, which is, you know, sending assets to a name instead of an address. Any input field you have should support ENS.

Um, or if you have a list of transactions, you're showing some data, it should try and resolve those addresses into ENS names. It can be setting a decentralized website using omni pin or any of the tools I described earlier. You could be issuing subdomains to your users. really anything as long as you write some code specifically for ENS. If you just use Rainbow Kit and the connect button um you know that the default thing shows your name, it's not quite enough for this, but you have to write some some custom code just for ENS.

It could be using a few React hooks, but it has to be some effort um to integrate ENS. And then um the bigger prize just for one team will be $1,500 for the most creative use of ENS in a DeFi application. I have a feeling this might be around those text records that I described earlier. I think payment preferences are really interesting and underexplored. Um and so it could be that it could be a similar version that DeFi protocols could use as like a way to specify where you want your earned yield to go.

Um, so it could be DeFi, it could be payments. Let's say most creative use of of ENS. Um, more broadly, DeFi is just like specific for this hackathon. But any super creative ideas that are loosely related to payments or DeFi or something like that are eligible. And if you have any questions, obviously you could ask.

Um, cool. While I read through some questions, we have five minutes and I will leave this QR code up here to join our developer group. Um, if you have any questions over the next few days, feel free to ask in there or in the Discord. We will be monitoring both. Um, and so yeah.

Okay, let's go through some questions here on Zoom. Okay, I've scrolled back up. So, yes, the hacker pack is only available after project submission. This is to Jack's question, but um we can help you get one for the sake of the hackathon for free. No problem.

Just send a message in Discord. And also, I should mention that um app.n.domains is where you may have already been to register a name. If you prepended Sapoleia to that, so seolia.

app.ns.domains, domains that brings you to the test net version of the application which allows you to register names with Sepula ETH. So no real money needed and that is totally fine for the sake of the hackathon. Okay.

Um what if I want to provide subnames for my users and my users will be multi-chain wondering how to set up the resolver in that case. Okay. So the probably shortest and easiest and maybe most helpful answer I could give is Duran is a great place to issue subdomains from L2s. Um by default the implementation is that you do have to choose one. So all of your names for example will live on base or arbitum or something like that.

Um although there's nothing stopping you from using this in combination with NFT bridges like I believe layer zero or um others that will um potentially allow you to have the same functionality crosschain. there's probably some confusing bits there that are like underexplored. Um, and so I'm happy to, you know, talk with you through it, but just to be clear that is having a name, having a collection of names that is available on multiple chains at the same time is not a native ENS feature. And so, um, that would be kind of a part of the hackathon project in itself. Awesome.

Can it happen that someone registers the same ENS I did on mainet on an EVML2? I register matte e on mainet and someone register the same on base. No. Um and this is actually related to the previous question in a way. The reason it's really hard to do crosschain naming is because you do need a single source of truth.

uh a name collision where I have named eth on mainet and somebody else has named ethan base at the same time is kind of the worst case scenario for a global namespace and so our our architecture is that athereum L1 is the source of truth and then you can kind of delegate certain parts of your name or subdomains to other chains but generally at least by default an entire collection of names and a collection I'm saying is kind of like a level of subdomains um are all on the same chain for the sake of having a source of truth. So hopefully that answers your question, Matt. Um another question from Jack. If I lose my primary ETH wallet, is there a way to enforce a transfer of the name? I think is what I'm understanding from the question.

Um so kind of there is a concept in ENS where you can have an owner of a name and a manager of a name and in this case the owner of a name should be a secure hardware wallet that you know doesn't get accessed often and is only for secure assets and then the manager of a name is who can change the ETH address and the description and things like that more dayto-day. Um, and that can be a how wallet where if it gets hacked, it's not a big deal because the owner can always like fall back the asset. Uh, or the owner can always change the manager to be more precise. And so that is is my recommended setup for a name. Ultimately, if the owner of a name is a wallet that gets compromised, then the hacker could potentially steal that name from you.

And once they do, there's there's no way to get it back. No. Um, yeah, it's an NFT and, you know, has no sort of admin keys, so it is not possible for us to recover a name for you. A decentralized protocol on Ethereum. Um, okay.

Can smart wallets have in names? Yes. And looks like a few people were getting involved in answering this for me. So, thank you guys. This is great.

Um any address can have an ENS name. This includes EOAS, smart contracts, smart contract wallets, um you know, which are smart contracts and and so on. So there's no restriction there. Yes. And as somebody pointed out, in order for a contract to receive a ETH name, it does have to be able to accept ERC 721 NFTs because ENS names are represented as NFTs.

So um that's a fairly common error that comes up. Developers will write a contract and try and transfer a name to it and there will be an error that is um an NFT error, not necessarily an inspecific name error. Um, and yeah, there are certain types of ENS names that are ERC 721 or 1155. And so I don't think I have the time to explain that right now, but ask in Discord and happy to help or in DMs. Um, oh, I think we made it through.

It only went a minute over, so hopefully that's that's all right. Pascal.

Yeah, don't worry about it. Craig, thank you. That was a fantastic, really, really informative workshop. Um, as Greg pointed out, um, the team is available on obviously their developer Telegram channel, but also on our Discord channel or Discord server. Just, uh, send the message into the partner, uh, ENS channel, and the team is more than happy to help jump in.

Um, yeah, Greg, again, thanks for joining us. This was really, really cool. This entire thing is recorded and uploaded on YouTube. So if you missed any parts throughout the workshop, missed any of the QR codes, you can always watch it there again and just scan the codes.