Your .eth Name Is a Website Now

I built a small app for a very specific idea:

Write HTML/CSS/JS in the browser → preview it live → publish it to IPFS → write the IPFS link to your ENS contenthash → open it at yourname.eth.limo.

That’s it.

No React setup. No npm install. No build step. No server to deploy. Just a static folder, an ENS name, IPFS, and a wallet signature.

The app is live at ens-sites.vercel.app.

Why I built it

ENS names already feel like internet-native identity. You can point yourname.eth at an address, avatar, text records, and other metadata. But the part I wanted to make feel dead simple was this:

Your ENS name can also point to a website.

ENS has a contenthash record. That record can point to decentralized content, like an IPFS directory. Gateways like eth.limo can resolve that ENS name, read the contenthash, fetch the site from the decentralized storage layer, and serve it in a normal browser.

So if chrismg.eth has a contenthash pointing to an IPFS site, the site can be opened at:

chrismg.eth.limo

And I have my own website on IPFS accessible at https://chrismg.eth.limo

If you don't know about IPFS here's a short explainer

That is extremely cool, but the workflow still feels too technical for most people.

Usually you have to:

1. Build a static site locally.
2. Make sure the output folder is correct.
3. Upload that folder to IPFS.
4. Copy the CID.
5. Encode it as an ENS contenthash.
6. Go to your resolver or ENS manager.
7. Write the record.
8. Wait for the transaction.
9. Test it through a gateway.

That is fine if you already understand ENS, IPFS, CIDs, resolvers, and static hosting.

But I wanted the flow to feel like:

connect → pick name → write → publish

What the app does

The app publishes static websites to IPFS and points an ENS name at them.

That matters because IPFS stores and serves content-addressed files. It can host things like:

• HTML
• CSS
• JavaScript
• Images
• Fonts
• Plain static folders

But IPFS does not run your server.

So the app does not support source projects that need a build step or a backend runtime:

• React source projects
• Next.js source projects
• Vite apps before build
• Server code

That limitation comes from the publishing target. IPFS is great for static output, not server-side execution.

A static site can still be interactive. Your JavaScript can run in the user’s browser, call APIs, connect wallets, query RPC endpoints, or read from decentralized networks. The key rule is that the folder you publish must already be browser-ready.

You can create files like:

index.html
styles.css
script.js
favicon.png

Or upload a folder that already contains your static site. The app previews the folder in-browser, then publishes that folder to IPFS. Once IPFS returns the directory CID, the app asks your wallet to write that CID to the selected ENS name’s contenthash record. After the transaction confirms, the ENS name points at the new site.

How it works under the hood

The flow has four steps.

1. Connect your wallet

You connect a wallet on Ethereum mainnet. The app uses your wallet to identify the ENS names you can publish to.

The important part is ownership: the app should not let you casually publish to names you do not control. When publishing, it checks the ENS resolver and prepares the contenthash write for the selected name.

2. Pick an ENS name

You choose one of your ENS names from a dropdown.

That name is the domain.

If you pick:

myname.eth

Then the final site should become accessible through:

myname.eth.limo

3. Write files or upload a static folder

You can write files directly in the browser or upload a folder.

The app expects static web output. That means an index.html file plus any relative assets it references.

A simple folder might look like:

index.html
styles.css
main.js
avatar.png

If index.html links to styles.css, that file needs to exist in the folder. If it references images/logo.png, that file needs to exist too.

There is no build step after upload. What you see is what gets published.

4. Publish to IPFS and write contenthash

When you hit publish, the app uploads the folder to IPFS through Pinata.

IPFS returns a CID. A CID is a content identifier: it points to content by what it is, not where it lives. If the content changes, the CID changes.

Then the app encodes that IPFS CID as an ENS contenthash and sends a wallet transaction to your ENS resolver.

Once the transaction lands, the ENS name points to the IPFS directory.

Then eth.limo can resolve the name and serve the site in a normal browser.

Why contenthash matters

A normal domain points to infrastructure.

An ENS contenthash points to content.

That distinction is the whole trick.

Instead of saying:

this domain points to this server

you can say:

this ENS name points to this content

The content can live on IPFS. The ENS record says what content should be loaded. Gateways like eth.limo make that usable for people who are still using Chrome, Safari, Firefox, or mobile browsers without native .eth support.

So the browser path becomes:

yourname.eth.limo

And behind the scenes:

ENS name → resolver → contenthash → IPFS CID → static site

What this is good for

This is perfect for small static sites:

• personal pages
• hackathon demos
• link pages
• project docs
• manifestos
• experiments
• “I just need this online” pages

It is especially good for the kind of thing you do not want to over-engineer.

You should not need a full framework to ship a two-page site. You should not need to remember how to configure a build command just to publish HTML. You should not need a server for something that is already static.

The web used to be simple files in a folder.

ENS + IPFS makes that idea feel new again.

What it is not

This is not magic hosting.

There are still tradeoffs.

IPFS content needs to be available somewhere. Pinning helps keep it available. Gateways are still gateways. Browsers still do not all resolve decentralized web content natively. And writing the ENS contenthash is an onchain transaction, so it costs gas.

Also, because this app publishes plain static folders, it does not run builds.

If you want to publish a React app, build it somewhere else first and upload the static output. The app is not going to run npm run build for you.

That constraint keeps the product simple and predictable.

Why I like this model

I like software that removes steps.

The underlying pieces already existed:

• ENS names
• contenthash records
• IPFS CIDs
• pinning services
• eth.limo gateways
• wallet transactions

The missing part was a tiny, direct interface that joins them together.

Connect wallet. Pick ENS name. Build static folder. Publish.

That’s the whole product.

And the result feels good:

your .eth name is a website now

References

• ENS Docs: Hosting a Decentralized Website
• ENSIP-7: Contenthash field
• IPFS Docs: Content Identifiers CIDs
• eth.limo
• Pinata Docs: Pin File to IPFS
• sites.xyz app