# Building Resilient Websites With ENS | Greg Skirloff - ENS - Channel: [Ethereum Denver](https://streameth.org/ethereum-denver) - Date: 2026-03-09 - Duration: 12:55 - Topics: ETHDenver, Crypto, Web3, Blockchain, Event, Conference, ETHDenver 2025, ETHDenver 2024, Bitcoin, Ethereum - Watch: https://streameth.org/watch/yt-soXkDEYt_hg - YouTube: https://www.youtube.com/watch?v=soXkDEYt_hg ## Description πŸš€ Get Ready for ETHDenver 2026! πŸš€ We're already hard at work preparing for next year's biggest Web3 event! Keep your eyes peeled for more info on ETHDenver 2026β€”it’s going to be epic! 🌟 ## Transcript All right, guys. Welcome back. Uh, this is our last presentation for today. Uh, we will see you back here tomorrow at 10:00 a.m. Uh, but coming right up, we saved the best for last. It's Greg from ENS, Building Resilient Websites. >> Awesome. Thank you for the intro. Hey everyone, thanks for sticking around for the last talk of the day. Hopefully, it's a good one. I can keep your attention. Um, just 13 minutes. So, we should be done pretty soon. But cool. Hey everyone, I am Greg with ENS Labs and today I'm going to be talking about decentralized websites, why your crypto protocol might need one, and how to deploy one. But before we get too into the weeds, I want to take a step back and think about why we are here. And I would say many of us are here to build protocols that live forever. But really the layer on top which is the app layer is often more brittle than we think. Every website that you visited today could really disappear tomorrow between DNS registars and CDN providers and cloud hosting and RPC hosting in the case of crypto apps. Any of these providers could go down or could decide to shut you off at any time for any reason. And we don't necessarily love that and we should have backups in a space that is meant to build apps that last forever of this kind of web uh circle. The infrastructure is really the weakest link. And I know this sounds kind of uh like it doesn't happen, but it actually does. And there are a number of examples that I'll point you to. So the most popular maybe is a few years ago, Tornado Cache, of course, was sanctioned by the US government. And that means the domain was seized and inaccessible to all the users even though the protocol stayed live on Ethereum. Usage went down because users couldn't access the website. And that's not the ideal state of a decentralized protocol. Balancer, Curve, and Aerad Drrome are all popular D5 protocols that have had their DNS domain hijacked at different times, which means that their web 2 domain served unofficial content that stole users money and resulted in millions of dollars of loss, which is obviously another bad outcome. Safe, our favorite multisig wallet, had their deployment process compromised last year, which led to a huge loss of funds again. And basically all the crypto apps during Dev Connect last year or just a few months ago really went down during the Dev Connect um week due to the Cloudflare outage and that was completely unavoidable. But actually decentralized websites did solve all of these problems or do solve all of the problems. Tornado does have an ENS name tornado which they have a decentralized website attached to that was still accessible even after the web 2 domain was seized. Aerad Drrome started pointing their users to a decentralized website after their DNS name was hijacked just a few months ago. Safe. In the safe ecosystem, there are multiple open source apps that are deployed to ENS names that allow you to cue and execute and do all of the things that you need to do um for safe transactions without any external dependencies at all. And in the last case, just to use ENS as an example, we started pointing users to our ENS.eth ETH decentralized website and actually showing people how to use ENS through that decentralized website during DevConnect. So all of these are real problems that have existed, but they all could have actually been solved or were solved with decentralized websites. And I would go as far as to say that protocols can't claim to be meaningfully decentralized unless they have some sort of decentralized front end. Some way that users without any other dependencies could install a front end and use the application. And the way you accomplish that is what I would call the decentralized website stack. So this kind of has to replace each layer of the issues that we pointed out before. On the domain side, of course, we have ENS, the Ethereum name service that is most known for pointing names to wallet addresses, but as you'll see in a minute, also points to any sort of arbitrary data, including decentralized storage data. And that brings us to storage. There are a number of decentralized storage networks like IPFS, Arweave, and Swarm that allow you to host decentralized websites in different ways. For deployments, the most secure way you can deploy a website is using a multisig because that means multiple people on your team have to explicitly approve a version of a website before it goes out to your users. And the tooling that kind of combines all of these pieces is called omnipin, which I'll show you in a minute. And then lastly, the way you access decentralized website are through a gateway. And eth.m limo is the most popular gateway that we have. And so that's kind of piece by piece of like what covers this. And now let's go into how it works a little bit more technical side. And before I start talking about it, obviously there are two sides to this. There's a developer creating a decentralized website and then there is a user accessing that website. So first the deploying side for developers. There are really three simple steps. First you build a website. Obviously you need something to deploy. Then you upload and pin those files to IPFS or you upload them to Swarm or Arweave. And this is what makes it accessible for a long period of time. And it results in some sort of hash, a CID it's often called or a content identifier. And that content identifier in step three is attached to your ENS name in a record that we call the content hash. And these are believe the three steps that are orchestrated by the tool called Omnipin, which again I am going to show you in a minute. And now let's look at the flip side of consuming a decentralized website which is really just the process in reverse. So if I'm uh trying to get the data that's attached to an ENS name, I first resolve the ENS content hash which gives me the content identifier. Then using that I fetch the files attached to it from IPFS or again the other storage providers. And then lastly I serve the content or I consume the content in this case. And these three steps are orchestrated by gateways which again eth.m limo is the largest um public operating one. And so now let's take a look end to end at doing both deploying and consuming. And because the internet was a little dodgy I recorded this and so I'm just going to voice it over as we go. So to start you can see that I'm trying to access dweb.gest.e.limo which means the ens.gest. gest and the gateway is eth.l and there's no content there. So obviously step one we have to build the website and at this point you would normally have a website already that you are deploying to a name but just for the sake of being of showing the full endto-end experience we're going to create a brand new website here with Astro which is a great static site generator and an important note is that you have to use static site generators because IPFS only supports static files. Now that we have the website, we are going to build it and see what it looks like locally. And you will see that it is a functioning blog. It's very simple, but it works. And this is just running locally. It has multiple pages and all this stuff. So now that we have built the website, second, we want to upload it to IPFS. And we're going to do that using Omni Pin. In just a few seconds, that will finish. And we have a CID which is that long hasht IPFS.deweb.link which in this case is an IPFS gateway slightly different to the ENS gateways which we'll talk about in a second. But that long hash is not a friendly way to access a website. And so now we connect it to the domain which of course is ENS. So this is the ENS manager app. I have my name dweb.gest.eth teeth and I go ahead and attach an IPFS hash which is just IPFS slash that hash that we got in the previous step. And now it'll take a few seconds to save that onchain. And this can be offchain or on layer 2 or all of those things the way ENS normally works, but I don't have time to go too into that rabbit hole. Okay, now we have a content hash which is that CD attached to my ENS name. And we're going to go back now to the gateway in the first place. Again, dweb.gest.eth is the name. And then e.limmo is the gateway. And we refresh it a few times so they clear their cache and can serve the content. And then here's my blog. It's the website that I just built 30 seconds prior. And we just uploaded using Omnipin. And then we manually attached it to the name in the ENS manager app. And now my functioning decentralized website. Oops. is dweb.gest.eth and again that gateway is eth.ml limo but in an ideal world you would have your own gateway as well which we'll talk about in a second. Cool. So that's kind of end to end of deploying and reading. And a few examples of projects that use this. Obviously there are hundreds or maybe even thousands but just a few that came to mind when I was working on this are of course ENS. Like I said, we used it to onboard users at Devconnect that we otherwise couldn't have done because of the Cloudflare outage, which is completely outside of our control. Next, arrow.drome.eth is obviously aerodrome, the D5 protocol that started using this more after their DNS hijacking incident a few months ago. Locals safe is my favorite of the open-source safe interfaces that allow you to cue and execute transactions without any other API dependencies. that's built by the Ciffron team. So, shout out to them. And then lastly, Vitalic.eth. Of course, Vitalik has a blog that is very known for being a thought leader in the space. And a few months ago or maybe a year ago, he transitioned from Vitalic.ca, which was his web 2 domain, to vital or vital. Including the gateway. And this is basically a signal that it's not just for protocols that need decentralized access to their apps, but also decentralized information in the case of Vitalic. And I think there's no sight of no sort of website that does not really deserve decentralized access. And I think Vitalik is a good example of that. Okay, this I don't know how well you can see, but what I showed before is a very manual process, right? We built the website using the bun run build command. Then we used the omnipin deploy command to deploy it. And then we manually copied and pasted that hash to the ENS app. But with omnipin, you can automate actually all of those things. And this is the real script that we use to deploy the ENS docs to IPFS and to our ENS name automatically every month as a sort of decentralized backup. And I'll walk you through it very quickly. So on the first of every month at midnight, we build the website and then we deploy the website to IPFS using OmniPin. And what these few arguments do are actually propose a transaction to a safe that the ENS labs team manages saying to update the content hash of the name uh the name being docs.ns.eth in this case. And the outcome of this is that we don't have to manually do anything other than approve a transaction to update the content hash. And that's really safe again because multiple people on the team have to explicitly approve that. And so the outcome of this is I wake up on the first of each month to a link that I click and I sign a transaction and I send it to somebody else to sign and then our new doc site is live on docs.ns. And so depending on the type of app you're building, you might want to do this for every deployment. You might want to do this once a month as a sort of decentralized backup. It's very customizable. But the point is omni pin makes all of this easy and even automates the executing part. I want to leave with this. Every protocol deserves an uncensorable interface and I think ENS is the best place to build that. This is a QR code to a blog post where I walk through all of these steps in more detail and have a full video going through even the safe part of the Omnipin deploy process which we skipped over today just for brevity. So feel free to take a look if you're interested. Otherwise, thank you very much for listening and I'll be over here if you have questions after.