Proposal to Integrate Dynamic Decentralized Website with ENS

The proposal is to integrate dynamic decentralized websites with ENS

What is a dynamic decentralized website?

A dynamic decentralized website is a smart contract hosted by an EVM-compatible blockchain (Mainnet, Testnets, L2s (Optimism/Arbitrum), etc). When users browses the website, we will call the contract (together with additional web arguments such as pathinfo), and the contract will return dynamically generated web contents (HTML/SVG/PNG, etc).

To browse the website, a user can type a web3:// URL defined by ERC-4804. An example of a Web3 URL is

web3://enshomepage.eth/

or using Web2 gateway, the equivalent URL is

https://web3q.io/enshomepage.eth/

Browsing the web3 URL will find the contract address of enshomepage.eth, call the contract following ERC-4804, and return the generated web content back to the browser.

What is the difference with IPFS?

The major difference is that the content of IPFS is static, while the web3:// websites are dynamically generated thanks to the programmability of EVM! With this feature, developers could easily create an interactive website such as a decentralized blogger with user comments, and decentralized social networks just based on Ethereum and ENS technologies!

The following is an example of a decentralized blog powered by ENS!

web3://w3home.eth/#/blog/0x362AD160C9622F95D042D8D83258909F3676AA9B

Would it be expensive to upload all web data to Ethereum?

Admittedly, uploading the web data to Ethereum will be very expensive due to the high gas price and storage cost. One way to solve the issue is to deploy the content to Ethereum L2 solutions such as Optimism/Arbitrum. However, these solutions mainly optimize for transaction throughput, but not large storage. To enable richer dweb applications, we are currently closely working with ETH community on the L2 solution for storage scalability. A couple of technologies will be involved are:

  • EIP-4488: Calldata Gas Cost Reduction
  • EIP-4444: Bound Historical Data in Execution Clients
  • Dynamic Data Sharding
  • W3IP-4: EVM Memory Optimization
  • ERC-5018: Filesystem-like Interface for Smart Contracts
  • etc

You can check out web3://w3home.eth/ for more info!

What is the addon value to ENS?

We believe the dynamic decentralized website can bring a lot of value to ENS. Users can now easily interact with .eth dwebs and dynamically change the content defined by the smart contract. Furthermore, users can just use using existing Ethereum wallets/accounts without additional effort.

Note that ERC-4804 allows translating a .eth domain to an EIP-3770 chain-specific address - this means that we can use .eth domains to locate any contracts on any EVM-compatible blockchains.

What are the next steps?

We cordially invite ENS community to build the decentralized dynamic website ecosystem together! A couple of directions in our minds are

  • Integration;
  • ERCs improvements;
  • Dynamic website application development and support (blogger, social network, on-chain generative NFT, etc);
  • Etc

Feel free to us know if you have feedback/suggestions/ideas! A lot of exciting stuff!

10 Likes

Fantastic idea.

I’m one of the leaders of .eth websites Subgroup of ENS DAO. So far we really focused on ENS+IPFS/IPNS/Arweave/Skynet websites, but your proposal is a different fascinating kind of animal.

The next call of the Subgroup is in about 2 weeks (an announcement will be made here later on). Would you like maybe to discuss this proposal there?

5 Likes

Of course! I would definitely join the call and share the details of the proposal. Many thanks for the invitation!

2 Likes

Some info here on a similar system:

3 Likes

Very exciting post! Something similar (but not as thorough) had been discussed some time ago on Esteroids Discord but only in passing. Looking forward to this!

4 Likes

After reading this, feels like something great is gonna happen.

1 Like

Thanks for sharing @qizhou,

I knew @neiman would like it, just waiting to see now what @slobo has to say :smiley:

3 Likes

This is a great proposal, which could enrich the usage of ENS, and bring more users into ENS and ETH ecosystems.

It solved the traditional web2 pains as well, for the website owners, they could remove the dependency from the server hosts.

Hi @slobo.eth
I am thinking of we could support this project with small grants.

4 Likes

I’ve been thinking about how Chris Dixon described the three iterations of the web as

image

and how the evolution towards a Dynamic Decentralised website would be the natural progression for web3 but this iteration would be in ‘Own Read Write’ order, with the all-important building block of ENS to begin with.

3 Likes

thanks for highlighting this thread @Premm.eth

@qizhou what are your thoughts on the concerns raised in that thread?

Great idea, looking forward to in-depth progress

Thanks for the comment! There are a couple of interesting ideas in ettp:// such as resolving NFT/Avatar/Profiles. In the comparison with ettp://, the major difference is that

  • ettp:// protocol processes path with different special purposes such as resolving NFT/Avatar/etc
  • in web3://, processing path is deferred to smart contracts - supporting other Web3 resources such as NFS/Avatar is completely up to dDapps.

This means that web3:// does not need to address the concerns of standardizing the NFT or other records of a ENS domain.

In fact, the major goal of web3:// in ERC-4804 is to provide a general-purpose Web3 resource locator in HTTP-style.

That said, it differs from HTTP in that

  • domain resolving: DNS vs ENS (via web3 text record)
  • resource host: IP server vs smart contract

However, web3:// does inherit some important properties of HTTP:

  • support relative URLs: E.g., when web3://ensdomain.eth/files/index.html references ../images/a.jpg, it will reference web3://ensdomain.eth/images/a.jpg
  • support MIME type detection according to the suffix of the last path argument
  • web3:// does not process path: path string is just passed to the smart contract so that the smart contract can do whatever it wants according to path.

With these features, we can have

  • Smart contract as a common gateway interface (CGI) program (and it is transparent!)
  • EVM as backend
  • Solidity as backend language
  • EVM-blockchain-network as the web server

Please let me know if these address the concern or not. Thanks!

2 Likes

ETTP is an NFT first protocol. The use of the URI path is minimized as much as possible and instead subdomains are used. Instead of,

ETTP would look like,

ettp://a-jpg.image.eth

This is intentional, because the path variable cannot be used to convey ownership, and with ETTP, as much as possible, resources are ownable, i.e., everything is an NFT.

ETTP relies heavily on the query part of the URI, which makes it possible to include a wide variety of attribute–value pairs, some of which could be passed directly to a smart contract.

For example, the web3 URI below,

web3://wusdt.eth:4->(uint256)/balanceOf/charles.eth

would look something like,

ettp://wusdt.eth?chainid=4&call=balanceOf(address)&data-address=charles.eth

ETTP is designed to be NFT first and user first. It is designed to be readable by average users and doesn’t require the user to memorize complex path specifications.

It is actually in the interest of users to adopt standards. Users won’t care whether an NFT is an ERC-721 or ERC-1155, or some other standard. They do however care a lot about how simple and easy to read a URI is.

With ETTP a NFT can be displayed simply using the key word nft as the path component,

ETTP: ettp://nftcontract.eth/nft/1

With web3:// I am not sure how it could even be done, maybe like this?

WEB3: web3://nftcontract.eth:1->(uint256)/tokenURI/1

This would appear to only display a URI in the browser, not an NFT.

To display the media file of an NFT (e.g., JPG/PNG), the NFT should have a method that returns an HTML to redirect to the link of the media file (which can be done by an on-chain wrapper contract), and the users just browse the link as web3://nftmedia.eth/showNFT/0xaabbcc/1.

Or the preferred way is to generate an NFT on-chain without an external link. The following is an example of on-chain rendering of media files of cyberbroker NFTs:

web3://cyberbrokers-meta.eth/renderBroker/50

or via gateway

https://web3q.io/cyberbrokers-meta.eth/renderBroker/50

Does this work with standard ERC-721 and ERC-1155 NFTs?

On-chain generative NFTs are not standardized in ERC-721/ERC-1155, but to my knowledge, some ERCs are working on it, e.g., ERC-4883: Composable SVG NFT.

1 Like