EIP-4804: Web3 URL to EVM Call Message Translation

[qizhou]

@SamWilsn

Is the intent to resolve the URIs through a browser? Although it’s possible to return HTML directly from a contract, I don’t expect that to be too normal (or gas efficient.) If the anchor is stripped before passing to a web extension, then yeah, it wouldn’t make sense to put it there.

Thanks for the comment. The intention is to resolve the URIs via a gateway (like ipfs.io) or a web browser extension. The browser just passes the full Web3 URI to the gateway/extension, and the gateway/extension would have full knowledge to parse the URIs to EVM call message and format the returned data back to the browser via HTTP protocol. This requires minimal changes on browsers so that we can use any browser (Chrome/Firefox/IE/etc) to browse Web3 URIs easily.

The standard would perfectly fit into NFT metadata/image data like SVG (I am also a big fan of it ). Meanwhile, we are exploring other non-binary data such as dWeb or even dynamic Web page generation (decentralized social network?). There are a lot of possibilities here enabled by Ethereum and ERC-4804!

@SamWilsn

I think if you had a URI like web3://foo.eth/balanceOf/address!bar.eth that would be sufficient to call the function. Actually, you could even do web3://foo.eth/balanceOf(address):uint256/bar.eth. What am I missing?

Are the types in the current EIP are there to disambiguate between overrides?

Many thanks for the comment. A couple of great design questions for the standard. Let me list them one-by-one:

Q1: For address from name service, should we use name type or address type? E.g.,

• web3://foo.eth/balanceOf/address!bar.eth ; or
• web3://foo.eth/balanceOf/name!bar.eth?

Using address type for both conventional 0x-20-bytes-hex ETH address space and name from NS should work as ETH address will never have “.”, but should we separate these types for better clarification?

Q2: Do we need type auto-detection, i.e., do we need the simpler URI at the price of potential ambiguity? E.g.,

• web3://foo.eth/balanceOf/address!bar.eth
• web3://foo.eth/balanceOf/bar.eth
  where the first is with mandatory type and the second’s type is auto-detected.

Actually, auto-detection may coexist with manual resolve mode better. Taking a dWeb as an example, the user may type (myhome.eth is in manual resolve mode)

• web3://myhome.eth/aaa.svg,

which will pass /aaa.svg as the calldata so that the contract can display the file directly. As a comparison, using the mandatory typed link in auto resolve mode will look like

• web3://myhome.eth/showFile/string!aaa.svg
  which is more verbose.

Q3: If types are supplied, where to put the input argument types and return types (which can be a tuple)? E.g.,

1. web3://foo.eth/balanceOf(address):(uint256)/bar.eth
2. web3://foo.eth/balanceOf(address)->(uint256)/bar.eth
3. web3://foo.eth/balanceOf->(uint256)/address!bar.eth
4. web3://foo.eth->(uint256)/balanceOf/address!bar.eth

I personally prefer “->” to prepend return types as it is clear to understand. In addition, current standard puts “->(outputTypes)” after the contract name (Option 4) so that the path part of the link looks almost the same as that of the Web2 HTTP link. Admittedly, Option 1 or 2 is closer to what current Solidity has, but seems to be incompatible with auto-detection for types.

@SamWilsn

This seems to imply that an ENS lookup would have to be web3://foo.eth.ens/... or web3://example.com.ens/...? The examples later in the EIP don’t match that pattern.

Nice find! I have changed the sentence to

In the second case, nsProviderSuffix will be the suffix from name service providers such as “eth”, “w3q”, etc.