MENU
Writing & Talks / BUIDLing a .eth Website With Pure Decentralized Infra
BUIDLing a .eth Website With Pure Decentralized Infra
Kay Feng
May 26th

TL;DR Learnings From Last Week

  • At present, it is very cumbersome to build a Web3 website, mainly because of Static Site Generators' use is highly limited to the Geek community.
  • So, we are bullish on a (not yet available) Web3 version of WIX / Strikingly
  • In the Web3 world, there is a lack of a database product available for production environment (neither the current L1 / Decentralized Storage Solution is available)
  • Therefore, we are bullish on a Web3 database that provides a basic level of availability
  • Therefore, bearish on most "Web3 applications" at this stage
  • As a Web2 company, CloudFlare's impact is underestimated in terms of active support for ENS and IPFS

In the past few months, I've been busy raising for a new fund, Aperture Digital, and have been going through a lot of centralization process. I was forced to wrestle with repetitive pitches, paperwork, and compliance, which are not that different from a traditional VC.

As it was all coming to a close, I was thinking about how a Web3 / Crypto VC should be somehow different in brand perception from a traditional VC. Inspired by my friend, I decided to build a website with completely decentralized infra for the fund.

Aperture should be one of the first few VC firms to do so, if not the first.

The whole process has given me a much better understanding of what's going on with Web3's infra (rather than just looking at a bunch of "Web3 Application-Layer" projects), and I'm glad to share the whole process and experience with you.

This is not a handy tutorial but more like a patchwork of pieces - because that's exactly what it's like to build a website in the Web3 world right now.

vitalik.eth

Anyone even new to the rabbit hole of the crypto world would be well off not knowing about ENS, and the mapping of ENS to the Ethereum network addresses. For instance, last week, we were concerned about whether the 30,000 ETH transferred by the vitalik.eth call contract from the wallet marked Vb3 had made it to the exchange (of course, it didn't).

But few people know that vitalik.eth is actually also a website, and you can access Vitalik's website in two ways:


EIP-1577

Whether you agree or disagree, both of us are familiar with EIP-1559. Actually, there are more proposals of EIP, such as our protagonist today, EIP-1577 (opens new window), which provides a contenthash field for ENS domain, allowing users to add the content on IPFS / Swarm to the ENS resolution. Generally, the content is a static website, and the whole process is like this:

(image from Cloudflare)

Static Site Generators

For developers, this is not something new: a decade ago, when GitHub was in its early age, it was Jekyll and Github Pages that attracted a lot of devs.

In brief, for products such as blogs that require no real-time or excessive back-end services, a Build can be done at each update to generate a static page of blog content and host it. User only need to modify CSS styles related to the theme, edit the Markdown file, and generate a basic usable website. A third-party service like Disqus does the dynamic part (like comments).

However, for the Web3 world, this is actually a reluctant move. Although by definition, both storage and L1s are somehow "databases", they face two problems:

  • If the L1s are treated as a database, even if there are no other problems, it is obvious that the performance cannot even meet the "basic availability" at the MVP level

  • If the native service of a storage service like IPFS / Arweave is treated as a database, its data structure is very different from traditional Key-Value databases and relational databases, and it is challenging to develop.

Is there such a service in the Web3 world? We have done some research.

  • IPFS Network: OrbitDB, seems to be generally available, but its development is stagnant
  • Arweave: Kwil, which is in a very early stage

(Obviously, we don't need to rebuild all the Web2 infrastructure in Web3, but it still frustrates me a bit that there isn't a basic usable database solution in a world where everyone is talking about "Web3 applications". What a pity!)

In a nutshell, static site generators seem to be the only option for building sites in the Web3 world now and in the mid-term. Fortunately, plugins for developers such as Jekyll / Hexo are already quite abundant, and common features are not difficult to implement.

With the above infrastructure, we can build a truly Web3 site with all aspects decentralized:

  • Domain: ENS
  • Front-end: Static Site Generators
  • Back-end: None
  • Server: IPFS

In addition, we need an IPFS Hosting / Gateway to help us sync the site's files to IPFS. There are many service providers for this, and GitHub officially maintains a list for availability monitoring (opens new window). The one I use is Fleek, which has several vital features

  • Import GitHub Repo directly
  • Monitor every Git Push and build in Docker
  • Resolve decentralized domains like ENS / HNS instantaneously

Imperfection

The only imperfection is the subscription function of NewsLetter, as there is no available back-end solution, and it is challenging to build the service independently on IPFS - even a basic message collection form is difficult to implement.

The subscription part is essentially using the Mailchimp service (there is an npm package called vuepress-plugin-mailchimp that can be used).

I forgive this last hint of centralization.

Thanks to Fleek and CloudFlare, our site is now steadily accessible via aperturedigital.eth.link (opens new window) or aperturedigital.eth.limo (opens new window), and you are welcome to subscribe to our Newsletter.

Whether you are a developer or a startup, if you have an idea for a Crypto / Web3 startup, please feel free to contact us at hi@aperture.xyz and we will be happy to accompany the project from Day One.