IPFS websites

Your page can host a website. Set its contenthash record to an IPFS CID and the gateway we run serves it at:

https://yourname.ipfs.cc

The gateway has its own domain on purpose, apart from etherpage.com, so a page’s website never runs on the site where you connect your wallet.

Step by step

  1. Build your site. Any static site works: plain HTML, Astro, Hugo, whatever produces files in a folder.
  2. Add it to IPFS. Use any pinning service (Pinata, Filebase, Lighthouse, 4everland) or your own IPFS node. You will get a CID like bafybei…. Prefer CIDv1 (starts with baf), since a DNS label is case-insensitive and CIDv1 is the form gateways can put in a hostname.
  3. Set the contenthash. Open your page’s manage page, then Records, then Website, paste the CID, an ipfs://… URI, or the gateway link your pinning service gave you, and confirm the transaction. The site encodes it into the standard binary contenthash format for you. A contenthash holds a root CID, so a link pointing inside a pinned folder keeps its root and drops the rest.
  4. Visit https://yourname.ipfs.cc.

How the gateway works

The gateway is a small resolver that reads your page’s contenthash from the contract on OP Mainnet and serves the content from IPFS. Your page is the single source of truth: update the contenthash and the site updates; nobody can serve different content under your name without your key.

The website is part of the page’s profile. It shows only while the page is active and its holder is the account that wrote the profile. After a transfer, the gateway serves nothing for the page until the new holder keeps the profile or sets a website of its own. The same happens while the page is expired or in its grace period.

Remember that the gateway is a convenience, not a dependency. The record onchain is what matters, and any IPFS-aware browser or gateway can resolve your content without it.

Subpages

A subpage can hold a contenthash like any other page, and every IPFS-aware client can resolve it. What it does not get is an ipfs.cc address, and the reason is TLS rather than policy.

A certificate can cover one level of subdomain. The wildcard behind alice.ipfs.cc cannot also cover blog.alice.ipfs.cc, because browsers accept exactly one wildcard label. Serving subpages would mean a certificate per parent page, issued on demand, which needs a server that terminates TLS itself rather than the edge worker the gateway runs on. It would also publish every participating name in Certificate Transparency logs.

We are not doing that for now. The alternative, serving a subpage at alice.ipfs.cc/blog, is worse than it looks: a subpage can belong to someone other than the parent’s holder, and a shared path means a shared origin, so both sites would share cookies, storage and scripts.

So a subpage’s site is real and reachable, just not at a name we host. Set the contenthash and open it through any public gateway, or through a browser that speaks IPFS.

Keeping content alive

IPFS content stays retrievable only while at least one node pins it. Your contenthash record lives onchain for as long as your page stays registered, but the content behind the CID is your responsibility: keep it pinned with your provider of choice, or on your own node.