Web3

My Web3 site survived four years of neglect

Mon, 23 Feb 2026 03:56:44 -0500

Four years ago, I published my first Web3 webpage using IPFS and ENS. I uploaded a simple "Hello World" HTML file, pointed dries.eth at it, and left it there. Two years later, I found it still running.

I haven't touched it since. Today, on the experiment's four-year anniversary, I checked again. It's still up at dries.eth.limo. Four years of total neglect, and the page loads just fine.

When I checked two years ago, every service I used was still operational. I called that "really encouraging". That optimism aged poorly.

Today, half the services have shut down, restricted access, or pivoted entirely:

Fleek, a platform I used to pin my content, shut down its hosting service on January 31, 2026. They pivoted to AI.
Infura was acquired by MetaMask and closed its IPFS service to new users.
Web3.storage rebranded to Storacha, and dropped IPFS pinning altogether.
Cloudflare sunset its public IPFS gateways.
Scaleway shut down its IPFS pinning service.

Of the original services, Pinata is still focused on IPFS. I logged in and my "Hello World" HTML file is still there. And eth.limo, the ENS gateway that lets anyone access .eth sites in a normal browser, still works.

Technically robust, commercially fragile

IPFS content exists only as long as someone chooses to host it. In 2022, my HTML file was pinned on Fleek, Pinata, Infura, and a friend's node. Today, it comes down to Pinata's free tier. My web3 page is hanging by a thread.

That sounds fragile, and in one sense it is. But the protocol is working as designed. IPFS doesn't promise permanence. It promises that content is addressable, verifiable, and can be kept alive by anyone who cares enough to pin it.

The durability of content on IPFS scales with how much people care about it. No one really cares about my "Hello World" page, so it's not being pinned. If this were dissident journalism or censored speech, people would likely pin it.

If you run an IPFS node and want to help keep my page alive, feel free to pin it: ipfs pin add bafybeibbkhmln7o4ud6an4qk6bukcpri7nhiwv6pz6ygslgtsrey2c3o3q.

Of course, I could make it more robust myself by pinning it on additional services or running my own node. Instead, I relied on third parties. With no node of my own, I'm entirely dependent on pinning services and other users to keep it alive.

The real story isn't fragility. It's economics. There may simply not be enough demand for decentralized storage to support a healthy market of providers. Companies keep entering, failing to find a business model, and pivoting away.

Traditional hosting is cheap, reliable, and familiar. The people who need censorship resistance are a narrow group, and everyone else has little reason to switch, myself included. And to be fair, replacing everyday web hosting was probably never IPFS's goal.

I still love IPFS as a protocol and the ideas behind it. But it feels like the ecosystem around it is commercially thin, and getting thinner.

I've written before about the idea of a RAID for web content. Rather than relying on a single system, the goal is redundancy across multiple layers. I'd like to experiment more with IPFS and make it one of those layers.

Browser support got worse, not better

In 2022, mainstream browsers didn't support ENS or IPFS natively, except for Brave. Brave included a built-in IPFS node that could resolve ipfs:// and ipns:// addresses directly.

In August 2024, Brave removed that integration. Fewer than 0.1% of users had ever used it, and the support costs were too high.

Chrome, Firefox, and Safari still don't support ENS or IPFS natively. A Firefox issue for adding IPFS support has been open since 2017, with no plans to implement it. The IPFS community continues pushing for browser standards work, but native protocol support seems like a long way off.

Today, the easiest way to visit a .eth site is still through a gateway like eth.limo. You append .limo to the ENS name and visit it in any browser. It works, but it's a centralized bridge to a decentralized system, which is a little ironic.

Gas fees dropped 99%

Not everything got worse. In my original post, I called out the cost of updating an ENS record as a major barrier. When content changes on IPFS, its hash changes too. To keep dries.eth pointing to the latest version, that new address has to be written to Ethereum, which costs gas.

Updating my content on Ethereum cost me $11.69 in 2022 and $4.08 in 2024. If I wanted to update it today, it would cost roughly one cent.

Average Ethereum gas prices now sit around 0.03 to 0.05 Gwei, compared to 30 to 50 Gwei when I first set this up. That is roughly a thousand times cheaper.

Two things drove this.

First, Ethereum roughly doubled the computation it can process per block over 2025. Validators gradually raised the gas limit, and the Fusaka upgrade in December formally pushed it from 30 million to 60 million.

Second, many applications migrated to Layer 2 networks. These are separate blockchains that batch up transactions and settle them back to Ethereum in bulk. As traffic moved off the main chain, congestion and fees dropped further.

The impact on ENS is dramatic. Just this month, ENS Labs cancelled its planned Layer 2 blockchain called "Namechain" because Ethereum's main network got so inexpensive that the Layer 2 became unnecessary. Nick Johnson, ENS co-founder and lead developer, noted that subsidizing 100% of all ENS transactions at current gas prices would cost about $10,000 per year.

A mixed scorecard

Four years in, the technology is better than ever but the market around it is worse. The IPFS protocol seems sound. ENS records are permanent. Gas fees have nearly vanished. But the commercial ecosystem for decentralized hosting has steadily thinned.

I wrote in 2022 that "IPFS and ENS offer limited value to most website owners, but tremendous value to a very narrow subset". Four years later, that assessment holds true.

AI also absorbed most of the tech industry's attention and capital. Web3 funding dropped sharply. Fleek's pivot from IPFS hosting to AI inference feels symbolic.

Will I keep the experiment going? Of course. But it's probably time to add a few more pins and stop relying on free tiers. The protocols don't need my help. The ecosystem apparently does.

Two years later: is my Web3 website still standing?

Thu, 29 Feb 2024 10:06:36 -0500

Two years ago, I launched a simple Web3 website using IPFS (InterPlanetary File System) and ENS (Ethereum Name Service). Back then, Web3 tools were getting a lot of media attention and I wanted to try it out.

Since I set up my Web3 website two years ago, I basically forgot about it. I didn't update it or pay attention to it for two years. But now that we hit the two-year mark, I'm curious: is my Web3 website still online?

At that time, I also stated that Web3 was not fit for hosting modern web applications, except for a small niche: static sites requiring high resilience and infrequent content updates.

I was also curious to explore the evolution of Web3 technologies to see if they became more applicable for website hosting.

My original Web3 experiment

In my original blog post, I documented the process of setting up what could be called the "Hello World" of Web3 hosting. I stored an HTML file on IPFS, ensured its availability using "pinning services", and made it accessible using an ENS domain.

For those with a basic understanding of Web3, here is a summary of the steps I took to launch my first Web3 website two years ago:

Purchased an ENS domain name: I used a crypto wallet with Ethereum to acquire dries.eth through the Ethereum Name Service, a decentralized alternative to the traditional DNS (Domain Name System).
Uploaded an HTML File to IPFS: I uploaded a static HTML page to the InterPlanetary File System (IPFS), which involved running my own IPFS node and utilizing various pinning services like Infura, Fleek, and Pinata. These pinning services ensure that the content remains available online even when my own IPFS node is offline.
Accessed the website: I confirmed that my website was accessible through IPFS-compatible browsers.
Mapped my webpage to my domain name: As the last step, I linked my IPFS-hosted site to my ENS domain dries.eth, making the web page accessible under an easy domain name.

If the four steps above are confusing to you, I recommend reading my original post. It is over 2,000 words, complete with screenshots and detailed explanations of the steps above.

Checking the pulse of various Web3 services

As the first step in my check-up, I wanted to verify if the various services I referenced in my original blog post are still operational.

The results, displayed in the table below, are really encouraging: Ethereum, ENS, IPFS, Filecoin, Infura, Fleek, Pinata, and web3.storage are all operational.

The two main technologies – ENS and IPFS – are both actively maintained and developed. This indicates that Web3 technology has built a robust foundation.

Service	Description	Still around in February 2024)
ENS	A blockchain-based naming protocol offering DNS for Web3, mapping domain names to Ethereum addresses.	Yes
IPFS	A peer-to-peer protocol for storing and sharing data in a distributed file system.	Yes
Filecoin	A blockchain-based storage network and cryptocurrency that incentivizes data storage and replication.	Yes
Infura	Provides tools and infrastructure to manage content on IPFS and other tools for developers to connect their applications to blockchain networks and deploy smart contracts.	Yes
Fleek	A platform for building websites using IPFS and ENS.	Yes
Pinata	Provides tools and infrastructure to manage content on IPFS, and more recently Farcaster applications.	Yes
web3.storage	Provides tools and infrastructure to manage content on IPFS with support for Filecoin.	Yes

Is my Web3 website still up?

Seeing all these Web3 services operational is encouraging, but the ultimate test is to check if my Web3 webpage, dries.eth, remained live. It's one thing for these services to work, but another for my site to function properly. Here is what I found in a detailed examination:

Domain ownership verification: A quick check on etherscan.io confirmed that dries.eth is still registered to me. Relief!
ENS registrar access: Using my crypto wallet, I could easily log into the ENS registrar and manage my domains. I even successfully renewed dries.eth as a test.
IPFS content availability: My webpage is still available on IPFS, thanks to having pinned it two years ago. Logging into Fleek and Pinata, I found my content on their admin dashboards.
Web3 and ENS gateway access: I can visit dries.eth using a Web3 browser, and also via an IPFS-compatible ENS gateway like https://dries.eth.limo/ – a privacy-centric service, new since my initial blog post.

The verdict? Not only are these Web3 services still operational, but my webpage also continues to work!

This is particularly noteworthy given that I haven't logged in to these services, didn't perform any maintenance, or didn't pay any hosting fees for two years (the pinning services I'm using have a free tier).

Visit my Web3 page yourself

For anyone interested in visiting my Web3 page (perhaps your first Web3 visit?), there are several methods to choose from, each with a different level of Web3-ness.

Use a Web3-enabled browser: Browsers such as Brave and Opera, offer built-in ENS and IPFS support. They can resolve ENS addresses and interpret IPFS addresses, making it as easy to navigate IPFS content as if it is traditional web content via HTTP or HTTPS.
Install a Web3 browser extension: If your favorite browser does not support Web3 out of the box, adding a browser extension like MetaMask can help you access Web3 applications. MetaMask works with Chrome, Firefox, and Edge. It enables you to use .eth domains for doing Ethereum transactions or for accessing content on IPFS.
Access through an ENS gateway: For those looking for the simplest way to access Web3 content without installing anything new, using an ENS gateway, such as eth.limo, is the easiest method. This gateway maps ENS domains to DNS, offering direct navigation to Web3 sites like mine at https://dries.eth.limo/. It serves as a simple bridge between Web2 (the conventional web) and Web3.

Streamlining content updates with IPNS

In my original post, I highlighted various challenges, such as the limitations for hosting dynamic applications, the cost of updates, and the slow speed of these updates. Although these issues still exist, my initial analysis was conducted with an incomplete understanding of the available technology. I want to delve deeper into these limitations, and refine my previous statements.

Some of these challenges stem from the fact that IPFS operates as a "content-addressed network". Unlike traditional systems that use URLs or file paths to locate content, IPFS uses a unique hash of the content itself. This hash is used to locate and verify the content, but also to facilitate decentralized storage.

While the principle of addressing content by a hash is super interesting, it also introduces some complications: whenever content is updated, its hash changes, making it tricky to link to the updated content. Specifically, every time I updated my Web3 site's content, I had to update my ENS record, and pay a translation fee on the Ethereum network.

At the time, I wasn't familiar with the InterPlanetary Name System (IPNS). IPNS, not to be confused with IPFS, addresses this challenge by assigning a mutable name to content on IPFS. You can think of IPNS as providing an "alias" or "redirect" for IPFS addresses: the IPNS address always stays the same and points to the latest IPFS address. It effectively eliminates the necessity of updating ENS records with each content change, cutting down on expenses and making the update process more automated and efficient.

To leverage IPNS, you have to take the following steps:

Upload your HTML file to IPFS and receive an IPFS hash.
Publish this hash to IPNS, creating an IPNS hash that directs to the latest IPFS hash.
Link your ENS domain to this IPNS hash. Since the IPNS hash remains constant, you only need to update your ENS record once.

Without IPNS, updating content involved:

Update the HTML file.
Upload the revised file to IPFS, generating a new IPFS hash.
Update the ENS record with the new IPFS hash, which costs some Ether and can take a few minutes.

With IPNS, updating content involves:

Update the HTML file.
Upload the revised file to IPFS, generating a new IPFS hash.
Update the IPNS record to reference this new hash, which is free and almost instant.

Although IPNS is a faster and more cost-effective approach compared to the original method, it still carries a level of complexity. There is also a minor runtime delay due to the extra redirection step. However, I believe this tradeoff is worth it.

Updating my Web3 site to use IPNS

With this newfound knowledge, I decided to use IPNS for my own site. I generated an IPNS hash using both the IPFS desktop application (see screenshot) and IPFS' command line tools:

$ ipfs name publish /ipfs/bafybeibbkhmln7o4ud6an4qk6bukcpri7nhiwv6pz6ygslgtsrey2c3o3q
> Published to k51qzi5uqu5dgy8mzjtcqvgr388xjc58fwprededbb1fisq1kvl34sy4h2qu1a: /ipfs/bafybeibbkhmln7o4ud6an4qk6bukcpri7nhiwv6pz6ygslgtsrey2c3o3q

The IPFS Desktop application showing my index.html file with an option to 'Publish to IPNS'.

After generating the IPNS hash, I was able to visit my site in Brave using the IPFS protocol at ipfs://bafybeibbkhmln7o4ud6an4qk6bukcpri7nhiwv6pz6ygslgtsrey2c3o3q, or via the IPNS protocol at ipns://k51qzi5uqu5dgy8mzjtcqvgr388xjc58fwprededbb1fisq1kvl34sy4h2qu1a.

My Web3 site in Brave using IPNS.

Next, I updated the ENS record for dries.eth to link to my IPNS hash. This change cost me 0.0011 ETH (currently $4.08 USD), as shown in the Etherscan transaction. Once the transaction was processed, dries.eth began directing to the new IPNS address.

A transaction confirmation on the ENS website, showing a successful update for dries.eth.

Rolling back my IPNS record in ENS

Unfortunately, my excitement was short-lived. A day later, dries.eth stopped working. IPNS records, it turns out, need to be kept alive – a lesson learned the hard way.

While IPFS content can be persisted through "pinning", IPNS records require periodic "republishing" to remain active. Essentially, the network's Distributed Hash Table (DHT) may drop IPNS records after a certain amount of time, typically 24 hours. To prevent an IPNS record from being dropped, the owner must "republish" it before the DHT forgets it.

I found out that the pinning services I use – Dolphin, Fleek and Pinata – don't support IPNS republishing. Looking into it further, it turns out few IPFS providers do.

During my research, I discovered Filebase, a small Boston-based company with fewer than five employees that I hadn't come across before. Interestingly, they provide both IPFS pinning and IPNS republishing. However, to pin my existing HTML file and republish its IPNS hash, I had to subscribe to their service at a cost of $20 per month.

Faced with the challenge of keeping my IPNS hash active, I found myself at a crossroads: either fork out $20 a month for a service like Filebase that handles IPNS republishing for me, or take on the responsibility of running my own IPFS node.

Of course, the whole point of decentralized storage is that people run their own nodes. However, considering the scope of my project – a single HTML file – the effort of running a dedicated node seemed disproportionate. I'm also running my IPFS node on my personal laptop, which is not always online. Maybe one day I'll try setting up a dedicated IPFS node on a Raspberry Pi or similar setup.

Ultimately, I decided to switch my ENS record back to the original IPFS link. This change, documented in the Etherscan transaction, cost me 0.002 ETH (currently $6.88 USD).

Although IPNS works, or can work, it just didn't work for me. Despite the setback, the whole experience was a great learning journey.

Web3 remains too complex for most people

Over the past two years, Web3 hosting hasn't disrupted the mainstream website hosting market. Despite the allure of Web3, mainstream website hosting is simple, reliable, and meets the needs of nearly all users.

Despite a significant upgrade of the Ethereum network that reduced energy consumption by over 99% through its transition to a Proof of Stake (PoS) consensus mechanism, environmental considerations, especially the carbon footprint associated with blockchain technologies, continue to create further challenges for the widespread adoption of Web3 technologies. (Note: ENS operates on the blockchain but IPFS does not.)

As I went through the check-up, I discovered islands of innovation and progress. Wallets and ENS domains got easier to use. However, the overall process of creating a basic website with IPFS and ENS remains relatively complex compared to the simplicity of Web2 hosting.

The need for a SQL-compatible Web3 database

Modern web applications like those built with Drupal and WordPress rely on a technology stack that includes a file system, a domain name system (e.g. DNS), a database (e.g. MariaDB or MySQL), and a server-side runtime environment (e.g. PHP).

While IPFS and ENS offer decentralized alternatives for the first two, the equivalents for databases and runtime environments are less mature. This limits the types of applications that can easily move from Web2 to Web3.

A major breakthrough would be the development of a decentralized database that is compatible with SQL, but currently, this does not seem to exist. The complexity of ensuring data integrity and confidentiality across multiple nodes without a central authority, along with meeting the throughput demands of modern web applications, may be too complex to solve.

After all, blockchains, as decentralized databases, have been in development for over a decade, yet lack support for the SQL language and fall short in speed and efficiency required for dynamic websites.

The need for a distributed runtime

Another critical component for modern websites is the runtime environment, which executes the server-side logic of web applications. Traditionally, this has been the domain of PHP, Python, Node.js, Java, etc.

WebAssembly (WASM) could emerge as a potential solution. It could make for an interesting decentralized solution as WASM binaries can be hosted on IPFS.

However, when WASM runs on the client-side – i.e. in the browser – it can't deliver the full capabilities of a server-side environment. This limitation makes it challenging to fully replicate traditional web applications.

So for now, Web3's applications are quite limited. While it's possible to host static websites on IPFS, dynamic applications requiring database interactions and server-side processing are difficult to transition to Web3.

Bridging the gap between Web2 and Web3

In the short term, the most likely path forward is blending decentralized and traditional technologies. For example, a website could store its static files on IPFS while relying on traditional Web2 solutions for its dynamic features.

Looking to the future, initiatives like OrbitDB's peer-to-peer database, which integrates with IPFS, show promise. However, OrbitDB lacks compatibility with SQL, meaning applications would need to be redesigned rather than simply transferred.

Web3 site hosting remains niche

Even the task of hosting static websites, which don't need a database or server-side processing, is relatively niche within the Web3 ecosystem.

As I wrote in my original post: In its current state, IPFS and ENS offer limited value to most website owners, but tremendous value to a very narrow subset of all website owners.. This observation remains accurate today.

IPFS and ENS stand out for their strengths in censorship resistance and reliability. However, for the majority of users, the convenience and adequacy of Web2 for hosting static sites often outweigh these benefits.

The key to broader acceptance of new technologies, like Web3, hinges on either discovering new mass-market use cases or significantly enhancing the user experience for existing ones. Web3 has not found a universal application or surpassed Web2 in user experience.

The popularity of SaaS platforms underscores this point. They dominate not because they're the most resilient or robust options, but because they're the most convenient. Despite the benefits of resilience and autonomy offered by Web3, most individuals opt for less resilient but more convenient SaaS solutions.

Conclusion

Despite the billions invested in Web3 and notable progress, its use for website hosting still has significant limitations.

The main challenge for the Web3 community is to either develop new, broadly appealing applications or significantly improve the usability of existing technologies.

Website hosting falls into the category of existing use cases.

Unfortunately, Web3 remains mostly limited to static websites, as it does not yet offer robust alternatives to SQL databases and server-side runtime.

Even within the limited scope of static websites, improvements to the user experience have been marginal, focused on individual parts of the technology stack. The overall end-to-end experience remains complex.

Nonetheless, the fact that my Web3 page is still up and running after two years is encouraging, showing the robustness of the underlying technology, even if its current use remains limited. I've grown quite fond of IPFS, and I hope to do more useful experiments with it in the future.

All things considered, I don't see Web3 taking the website hosting world by storm any time soon. That said, over time, Web3 could become significantly more attractive and functional. All in all, keeping an eye on this space is definitely fun and worthwhile.

My first Web3 webpage

Thu, 24 Feb 2022 04:19:24 -0500

Today, I'm going to publish my first webpage using Web3 technologies. I will upload a page to IPFS (InterPlanetary File System), make it available at dries.eth using ENS (Ethereum Name Service), and visit it with a Web3-enabled browser. If you don't know what that means, buckle up for a crash course.

Step 1: Buy an ENS domain name

Last year, I minted buytaert.eth, and more recently, I purchased dries.eth. Both are ENS domain names.

ENS, which stands for Ethereum Name Service, is an Open Source blockchain-based naming protocol. You can think of ENS as DNS for Web3. Where DNS maps domain names to IP addresses, ENS maps domain names to Ethereum addresses. And an Ethereum address can point to a cryptocurrency wallet, a content hash, and more.

ENS isn't just a service for Ethereum; it's a general purpose Web3 service built on Ethereum using smart contracts. Because ENS is built on the blockchain, it is more resistant to censorship than DNS.

Today, the primary use case for having your own ENS domain is to make receiving cryptocurrencies easier. If you wanted to send me some Ether, you have to send it to 0xbAD65DE65AE2c23f5eA30d12fC8c2f883cbe671f, the address of my Ethereum wallet. Because I own dries.eth, you can send it dries.eth instead. Much easier to remember!

It's pretty amazing that dries.eth can collect cryptocurrencies permissionless from anyone anywhere in the world without a single intermediary. However, that is not the topic of today's blog post. In this blog post, I want to show how dries.eth can be used to host a fully decentralized Web3 webpage.

If you want to buy an .eth domain, you can do so at the ENS Domains website. Because an .eth domain is an NFT (Non-Fungible Token), you can also buy and sell domain names at NFT marketplaces like OpenSea.

When ENS launched in May 2017, it only supported the ENS-native TLD .eth. As of August 2021, ENS added support for the full DNS namespace. So if you own example.com on DNS, you can use the ENS Domains website to set ENS records for example.com.

Step 2: Upload a HTML file to IPFS

IPFS, short for InterPlanetary File System, is an Open Source protocol and peer-to-peer network for storing and sharing data.

Today, most webpages are stored on a single server, hosted in a single data center. These sites are not very resilient to a single point of failure, denial of service attacks, or government censorship.

More advanced websites replicate their webpages using CDNs and other caching systems. My site uses multiple Kubernetes web nodes, Varnish and Cloudflare, but that is because my company helps run some of the largest websites in the world, not because my website requires it. All these technologies can be used to improve a website's resiliency.

With IPFS, your webpage can be replicated across hundreds of "IPFS nodes" around the world. Everyone in the world can run an IPFS node. The nodes create a single, global network, and each file in the network gets a unique, global identifier.

In theory, IPFS is more resilient than traditional website hosting. Because IPFS nodes are run by different people and organizations around the world, and content is replicated across them, the hosted content is more resistant to a single point of failure, denial of service attacks, or government censorship. The flip-side is that it is also more difficult to moderate misinformation.

I wrote "in theory" because content uploaded to IPFS only stays available as long as one node, somewhere in the world, chooses to host it. And by default, IPFS does not include a built-in mechanism to incentivize other nodes in the network to replicate data. Each IPFS node tends to host its own data. Other nodes can replicate data cooperatively, or as a service.

This is where Filecoin comes in. Like IPFS, Filecoin is an Open Source protocol. IPFS itself is not blockchain-based, but Filecoin is. Filecoin extends IPFS with a public marketplace for storing and replicating data. Miners can earn Filecoin (a cryptocurrency token) in exchange for storing and replicating IPFS data. Because Filecoin is blockchain-based, the marketplace is not owned by a single intermediary. Storage deals are brokered programmatically by nodes on the network.

Long story short, to host my webpage on IPFS, I need at least one IPFS node willing to host my content. There are two solutions for this: (1) I can run my own IPFS node or (2) I can pay a third-party IPFS service to host my content.

Running my own IPFS node

In the spirit of helping to build a decentralized web, running your own IPFS node should be the preferred option. Below you can see my local IPFS node hosting my index.html file:

A "Files" overview screen showing that my local IPFS node is hosting index.html.

A dashboard showing my local IPFS node's bandwidth usage.

Replicating my webpage

Because my local IPFS node runs on my laptop, my webpage is only available when my laptop is connected to the internet.

As explained, I can use Filecoin to pay other nodes on the network to replicate my content. However, I came up with a better solution: one of my best friends.

I asked him to "pin" my file on some of his IPFS nodes that are permanently connected to the internet. This way my webpage remains available even when my laptop disconnects from the internet.

A drop-down menu allows you to easily pin a file to an IPFS node.

With a few friends pinning each other's websites on IPFS, you don't need to pay for web hosting anymore!

Third-party IPFS and pinning services

If you don't want to run your own IPFS service, or you don't have friends who can replicate your data, you can use a third-party IPFS and pinning service.

I found a dozen pinning services, and tried the following:

Infura makes it easy to upload files using their command line tool:

$ ipfs-upload-client --id xxx --secret yyy ./index.html

xxx is the Infura Project ID and yyy the Infura Project Secret Key.

Fleek and Pinata allow you to upload files from your web browser:

Fleek conveniently allows you to upload files to IPFS from the browser.

Pinata allows you to upload files to IPFS from the browser. You can replicate content across multiple IPFS nodes run by Pinata.

If you're looking for Filecoin-based solutions, Web3.storage comes recommended.

Step 3: Visit your Web3 webpage

After uploading a file to IPFS, you get the "hash" (a unique ID or address) of the file. The hash of my index.html file is:

bafybeibbkhmln7o4ud6an4qk6bukcpri7nhiwv6pz6ygslgtsrey2c3o3q

Content hosted on IPFS can be accessed using an IPFS-compatible browser like Brave. Firefox, Safari and Chrome don't currently support IPFS natively, but various IPFS browser extensions exist.

Using Brave, you can visit my webpage at ipfs://bafybeibbkhmln7o4ud6an4qk6bukcpri7nhiwv6pz6ygslgtsrey2c3o3q (note the ipfs:// schema).

Brave showing my webpage hosted on IPFS.

Step 4: Map your webpage to your domain name

Being able to visit your IPFS-hosted website is pretty neat, but you're probably not going to ask other people to check out your new webpage at ipfs://bafybeibbkhmln7o4ud6an4qk6bukcpri7nhiwv6pz6ygslgtsrey2c3o3q. Using a 60-character hexadecimal hash isn't exactly ideal.

This is where ENS comes in. I just had to set the Content Resolver record of dries.eth to the IPFS hash associated with my webpage.

Mapping the IPFS hash to dries.eth is done by updating the Content Resolver record of the ENS domain on the ENS Domains website.

Updating an ENS record permanently updates the state of the Ethereum blockchain. This means you have to pay a "gas fee", or a network transaction fee. As you can see on Etherscan, it cost me 0.004369 Ether ($11.69 at the time) to update my ENS record.

You can now use an ENS and IPFS compatible browser to visit https://dries.eth. Voila, a truly decentralized website!

dries.eth rendered in Google Chrome with the Metamask extension.

Are ENS and IPFS the future of the web?

There are various big shortcomings:

It only works with static sites. Most organizations use dynamic websites such as those rendered by Drupal or WordPress. Of course, you can export simple Drupal sites (like this blog) to static HTML and upload those files to IPFS. But not all sites lend themselves to becoming static sites.
It is too costly for many. Every time you make changes to your website, and you redeploy to IPFS, you generate a new hash. A new hash means updating your ENS record, and updating your ENS record means paying gas fees. This becomes expensive when you have to update your site frequently.
It is too slow for some. Updating my ENS record was manual, requires approval of the transaction, and takes some time to settle on the blockchain. Not acceptable for news websites that need to get information out in real-time.
Lack of browser support. Mainstream browsers still don't support ENS out-of-the-box. Until they do, Web3 feels like a parallel universe.

I'm sure these shortcomings will be addressed in the years ahead. Some might already have solutions.

Shortcomings aside, I believe IPFS and ENS hold promise:

I prefer using the IPFS API over Amazon's proprietary S3 API. It makes my web applications more portable. Open Source protocols are preferred.
The idea that these services are both permissionless and programmable is mind-blowing. For example, it makes me wonder if I could create a smart contract that automatically pays miners around the world to keep my blog and photo albums online for the next 250+ years. I'd love to explore that in a future blog post.
ENS feels like a really useful building block for resolving and verifying various things. A global key-value store has many potential use cases.

What does Web3 mean for developers?

If you are a developer, think of Web3 as a growing collection of new "web services".

IPFS and ENS are two such web services. Today, they mainly provide improved resiliency and censorship protection. If resiliency and censorship protection are important for your website, use them. If they are not, you don't have to use them. As the owner and developer of https://dri.es, I don't care about censorship protection. For that reason, I'm happy to keep using traditional hosting technologies. But I do recognize that IPFS and ENS could become more interesting in the future.

In its current state, IPFS and ENS offer limited value to most website owners, but tremendous value to a very narrow subset of all website owners. That could change in the future.

What is the promise of Web3?

I do think it is important to watch the Web3 space. New and powerful Web3 services will emerge. The internet's desire to eliminate intermediates has raged on for 20+ years. It is an unstoppable trend. With Web3, more intermediaries face risk of disintermediation and decentralization.

That includes organizations whose business model depends on proprietary databases and ledgers; financial institutions, central banks, certain non-profits, social communities. Many of these could turn into truly decentralized web services.

For example, many commerce websites offer loans and loan repayment programs using intermediaries like PayPal or Square. In time, some of these intermediaries could be replaced by permissionless, distributed web services that charge less interest and/or smaller transaction fees. Imagine the day it becomes really easy for commerce websites to offer loan repayment programs directly to their customers without an intermediary. When profit margins stand to benefit, technology solutions gets adopted quickly.

The blockchain will also enable us to solve coordination and ownership problems in new ways. Everyone who creates content on the web (images, music, videos, blog posts) could benefit from that. The ability for others to use your content, and for value to flow back to you programmatically is quite exciting.

Most of all, I'm hopeful that these decentralized services will help us advance how we govern public goods, how we sustain Open Source projects, and how we can meaningfully shift power back from large organizations to individuals and communities. But that is the topic for a future blog post.

February, 2024 update: Two years have passed since I last engaged with my Web3 site. I decided to review its current state, expand on some points in this blog post, and explore Web3's progress in the context of website hosting. Read my update at Two years later: is my Web3 website still standing?.