ETTP: a new standard for browser resolution

I would like to propose a new web standard URI scheme, ettp://. Currently there is no URI scheme that is well known and associated with Web3. ENS is known more broadly for identity. Looking out into the future, I believe the number of ENS names registered for other uses will be much larger than for identity.

ENS supports both native .eth domains as well as DNS domains. It is however not clear to most the differences between them, or what happens when a DNS name (e.g. .com) is registered as an ENS name, particularly when it comes to web browser resolution.

When it is possible to resolve an ENS name in a web browser, either by using a plugin (e.g. Metamask) or native browser support, (e.g. Brave Browser) there is still not one standard. With Metamask it is necessary to use a trailing slash with the ENS name. For instance, if using Chrome with Metamask, vitalik.eth returns a google search, and vitalik.eth/ returns a dapp, wherein the URI is also changed to https://bafybeihm77mt7bxtctilul2ko75gxzrzzc3kd5k5do7bjdjkgnguv7fe24.ipfs.dweb.link/.

When it comes to DNS names registered with ENS this becomes even more confusing. The solution I believe is to use a new Web3 URI scheme for resolving content data in web browsers.

The “ethereum:” scheme, https://github.com/ethereum/EIPs/blob/master/EIPS/eip-681.md, I believe is not sufficient for web page resolution. “ethereum:” can be thought of much like “mailto:” which is associated with a specific purpose, and that is payment. There is currently no way to disambiguate payment from web page resolution with “ethereum:” unless “pay-” is added, e.g. “ethereum:pay-www”. While this might be a possible way to disambiguate payment from web page resolution it doesn’t make Web3 content resolution more understandable. Also, ENS is not just a system for Ethereum, therefore it is desirable to use a more generic URI scheme.

The ETTP standard could include:

  • A single Web3 standard for browser resolution of distributed web content. e.g. ettp://vitalik.eth
  • resolving NFTs using only a contract address and id in the browser. e.g. ettp://nftcontract.eth/nft/1
  • resolving ENS resolver data in the browser e.g ettp://vitalik.eth/ens
  • resolving specific txt fields in the resolver. e.g. ettp://vitalik.eth/avatar
  • resolving in the browser a public distributed profile e.g. ettp://vitalik.eth/profile
  • resolving a distributed social graph including friends e.g ettp://vitalik.eth/friends
  • resolving Web3 content subscriptions ettp://vitalik.eth/subscriptions

The ETTP scheme works differently than traditional URI’s in that the path portion of the URI is part of the protocol. This makes sense, because with distributed files i.e. CIDs, it is inconvenient to use path variables. The only conflict this introduces is with CID’s of directories, which use the path part of the URI. For this case I propose the standard would be to use the query part of the path e.g. ettp://vitalik.eth?cid=QmPvaEQFVvuiaYzkSVUp23iHTQeEUpDaJnP8U7C3PqE57w/mytextfile.txt or ettp://vitalik.eth?path=mytextfile.txt
Because the way that queries work using key-value pairs, there are an unlimited number of key-value pairs that can be used. Others might include NFT standard e.g. nftstandard=erc721, chain id e.g. chainid=1, etc.

What does ETTP stand for? Ethereum Token Transfer Protocol, but the more important thing is that it is familiar, and new at the same time, and is specifically designed for browser resolution for Web3.

6 Likes

Sounds great but I have no idea how or where to start.

One way to start would be to use it for the ENS resolver for the avatar field. Currently many people are very confused about how to correctly format the NFT avatar URI. If the ETTP protocol was implemented within app.ens.domains resolver avatar field, it would simplify the process, and hopefully lead to less gas being wasted and less frustrated users.

e.g. https://twitter.com/nicksdjohnson/status/1462227327740350469

Currently the URI looks like this:

eip155:1/erc721:0xb7F7F6C52F2e2fdb1963Eab30438024864c313F6/2430

and with ETTP it would look like this:

ettp://0xb7F7F6C52F2e2fdb1963Eab30438024864c313F6/nft/2430

and if there was a ENS domain for the contract, it would look like,

ettp://animalnft.eth/nft/2430

Another idea would be to proactively create a ENS name for every NFT project on the web. Filecoin is doing this with NFT data with NFT.storage, proactively storing all NFT data. Particularly if it was using subdomains and a L2, the cost would be pretty low.

This might look like:

ettp://animalnft.contract.eth/nft/2430

2 Likes

This is one of the best ideas I’ve seen so far.

Currently we’re using CAIPs for specifying NFTs. I don’t think there’s a compelling reason to switch to a new, incompatible standard - though you’re right that it should definitely support ENS names for the token contract address.

I think ETTP serves a similar critical function as ENS. For example:

ENS: 0x7978C41C76Beb70b9bDf5163D1aE1daF82C4f87c

:arrow_right: firefly.eth

ETTP: eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d/771769

:arrow_right: ettp://cryptokitties.eth/nft/771769

I think the confusion around the Avatar record in the ENS resolver illustrates this point perfectly. CAIP-19 can’t work when it comes to actual users.

If end users are having to type URLs at all, that’s a UX fail - and our current UI is only temporary in any case. We should not pick a URL scheme based on what looks ‘friendliest’, especially when there are existing schemes that work fine.

1 Like

When looking at the next phase of adoption for Web3, the questions I see as important are:

  • What are the killer apps that will drive adoption?
  • What are the points of friction that are currently limiting adoption?

Starting with Web1, email is often cited as the first killer app. It basically presents the user a promise– compose a message, attach a simple human readable address and click send, and the message will magically appear in the inbox of the intended user. This promise was extended to websites, which is arguably the second killer app of Web1– enter a human readable domain into a browser, click enter and receive the desired web page in the browser.

Web2 built upon these promises, and added a new killer app, and that was the user profile. Web pages became apps with logins and passwords. Web3 can either be seen as a natural evolution of Web2 or it could also be seen as a rewriting of Web2, with a new promise – your data is your data, no one can take it away from you.

The first killer app of Web3 will most likely be payment. The promise is again clear, enter an address, enter an amount, and hit send and magically the intended recipient will receive the funds anywhere in the world. Early on, however, there was a problem, the address was not human readable. Crypto domain systems were proposed and today we have ENS which solves that problem. The next killer app will most likely be digital asset ownership, e.g. NFTs. The promise of NFTs is based squarely on the promise of Web3 – your data is your data, no one can take it away from you. The problem is currently the NFT digital assets are ironically intangible. There is currently no simple way to enter a human readable domain into a browser, click enter, and receive an NFT in the browser.

In order to combat this problem, websites like https://checkmynft.com/ have been created in order to try and work around this problem. When visiting the website, users are presented with pages of text describing all the ways that the simple promise of Web3 – your data is your data, no one can take it away from you, can be violated. Can NFTs deliver on the promise of Web3 without a simple and easy to use way of viewing an NFT in a web browser? Are URIs pointing to the key new type of digital asset on Web3, i.e. the NFT, necessary?