Many thanks for your comments. A couple of my responses:
Nice! I have added the sentence
Moreover, this standard enables interoperability with other standards already compatible with URIs, like SVG. in the motivation part.
Thanks for the comment. I feel that
eth:// may be a bit narrow because the protocol itself can support any EVM blockchains such as Polygon/BSC or even testnets. For
evm://, I feel it is a bit technical because a lot of Web2 people may not have an idea what EVM is.
I have been struggling to choose the best scheme name. I finally choose
web3:// because the major goal of the protocol is to be the counterpart of
http:// in Web2. Further, given the fact that Ethereum/EVM has been the de-facto Web3 technical stack, using
web3:// could strengthen the position of Ethereum/EVM in Web3 without creating confusion. Feel free to let me know if you have other thoughts.
Thanks for the comment. The hashtag will be pre-processed by the browser so that the type info may not be passed to the gateway or web extension. If we want to process them on the client side, we need to return an HTML that processes the type info, which may be complicated. Instead, if we could process them on server side, then the user can browse the formatted result either in browser or curl/wget or programs easily.
Thanks for the comment.
balanceOf should match method in the grammar:
Web3URL = "web3://" [userinfo "@"] contractName [":" chainid] ["->(" returnTypes ")"] path [? query] contractName = address | name "." nsProvider path = ["/" method ["/" argument_0 ["/" argument_1 ... ]]] argument = [type "!"] value
As the result, the protocol will call “balanceOf(address)” with
charles.eth's address from NS. Please let me know if I miss anything.
I agree that retrieving ABI definition is not easy in this case. Actually, mandating the types in the link still needs ABI definitions for implementers. So the cost should be the same no matter whether the types are mandatory or not.
The reason for providing auto-type detection is to make the URL as simple and natural as possible. Further, in our current gateway implementation, we will return
web3-return-type in HTTP response headers for better debuggability. The following is an example of