ETTP: a new standard for browser resolution

🧑‍💻 ENS Development Standards
1

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.

10 Likes
2

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

3

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

4 Likes
4

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

5

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.

6
7

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.

8

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.

2 Likes
9

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?

10

I don’t see how adding a prefix helps any of that. In fact prefixes are generally user unfriendly: most users don’t type http://www. anymore for anything, just foo dot com. It’s even more confusing for sites that don’t automatically switch to https when you type http and the user sees an error.

I also think it’s a mistake to try to solve payments with browser resolution with content etc. It’s much better to be focused on one solution and do it well. In your case, the one thing I see is the Vitalik.eth example. I do agree that web resolution is a vastly underused aspect of ENS and we should work to fix that, and that will only come together with broad browser support to hash based systems.

So let’s break down:
\https://bafybeihm77mt7bxtctilul2ko75gxzrzzc3kd5k5do7bjdjkgnguv7fe24.ipfs.dweb.link/avatar/

https:// this bit should probably be replaced by ipfs:// (or whatever protocol is being used for getting the files) if the browser had native support for it.

bafybeihm77mt7bxtctilul2ko75gxzrzzc3kd5k5do7bjdjkgnguv7fe24 this should definitely be replaced by Vitalik.eth just like IP addresses work

.ipfs.dweb.link this website is just a bridge to IPFS websites and works as a trusted system that can be replaced. If IPFS and ENS were supported natively it wouldn’t be necessary.

/avatar the last bit is finally the web structure and should be kept respecting how DNS already works.

So basically that link would read in a browser as:

ipfs://vitalik.eth/avatar

which would be displayed on the browser as just

vitalik.eth/avatar
vitalik.eth/friends#top?search=foo
etc

PS: Mist changed urls to make them all be ordered hierarchically so it would display the same address divided by triangles which I thought was clever but very very non standard.

eth ▸ vitalik ▸ avatar ▸ top ▸ search: foo

4 Likes
11

I think it is necessary to look at a few examples because ENS domains are not only for identity but also for Web3 resources and data. Also ENS domains are for all top level domains not just .eth. If we apply the promises of Web3 including a single domain to represent a profile, ownership of data, and the internet of value, then I would say that the ENS domain should be able to be used for:

1. Payment - It should be possible to send and receive crypto currencies or tokens.

2. Asset Ownership

2.1 Identity - It should be possible for any ENS domain to be verified as the one and only owner of that domain on any Web3 forum, social media platform, or dapp.

2.2 Content - Any Web3 distributed file content, e.g. IPFS, should be able to be accessed as verified content.

2.3 Avatar/NFT - An avatar or media NFT should be verified as the owned by the domain.

2.4 Phone Number – It should be possible to make a phone call to ENS domains.

2.5 Social Media Handles – It should be possible to use an ENS domain for all social media dapps.

Payment

This is essentially a solved problem, most wallets already support this feature by just using the domain as the recipient.

Asset Ownership: Identity

It is currently possible to verify the ownership of Primary ENS Names, e.g. Vitalik.eth, using two queries to two different ENS contracts, using scripting. The level of coding ability is above an average web user, therefore, only professionally made dapps can do it. Also, for a large number of users, it is necessary to query indexed data, e.g. GraphQL. This adds further complexity and makes it even less possible for an average user to do it.

With ETTP it would be possible to specify as part of the domain object a verification method. For example, ettp://xavier.xyz/verify?addr=0x6150E47878d1680C4147071B01C439cb51eCA8A3 would return true or false.

Asset Ownership: Content

It is currently possible to retrieve IPFS content associated with a ENS domain, however, it is not supported by any major browser. It is not likely to be supported by any browser in the future, because there is currently no method for disambiguating an ENS name from a DNS name. Using Metamask browser extension it is possible to add a slash, i.e. vitalik.eth/, which will prompt Metamask to try and resolve the ENS domain in the browser, loading any IPFS content which is associated with the domain. This results in unexpected behavior, for instance a domain could point to one website for “Xavier.xyz” and a totally different website for “Xavier.xyz/”.

With ETTP it would be clear, a call to ettp://xavier.xyz would result in the decentralized version of the website, and https:// would result in the DNS version of the website. This is much clearer than adding a slash to the end of the domain, or any other system that uses https://.

Asset Ownership: Avatar/NFT

Currently it is possible to register an NFT with an ENS domain. To display the NFT however, it requires a dapp to query a smart contract and id, as well as load the metadata and image. This is beyond the abilities of an average web user. Further it is possible to verify the ownership of that domain, but this requires further queries to smart contracts or indexing databases. Displaying a list of users and their associated avatars is not trivial and requires a high level of programming skill.

With ETTP it would be possible to simply form a URI and receive the avatar image, e.g. ettp://xavier.xyz/avatar. It would also be possible to add a query string, e.g. ettp://xavier.xyz/avatar?size=thumbnail, in order to receive a smaller version of the image. It would also be possible to change the avatar based on different seasons or events, e.g. ettp://xavier.xyz/avatar?version=december, in which case a holiday avatar would be displayed.

ETTP would also manage state, calling on indexing databases, e.g. The Graph, for fast data retrieval, and only reverting to the smart contract when the data is not available. The URI could be used within HTML, e.g. <img src=”ettp://xavier.xyz/avatar?size=thumbnail”>.

Asset Ownership: Phone Number

Using current systems, this should be straightforward for apps to accomplish, but it is difficult for average web users.

ETTP would allow any web user to create a link in HTML, e.g. <a href=”ettp://xavier.xyz/phone”>Call Me </a>

Asset Ownership: Social Media Handles

Using current systems, this should be straightforward for apps to accomplish, but it is difficult for average web users.

With ETTP it would be possible to display handles within HTML, e.g. <a href=”ettp://xavier.xyz/twitter”> Twitter </a>

ETTP makes ENS domains and associated data reverse compatible with HTML. It makes it possible for even casual web users to embed key ENS domain data into a blog, supporting journalism and the arts. It upgrades key Web1 media types, e.g. images, video and sound, adding verified ownership. It makes the Web2 profile into a base media type, and makes it reverse compatible with HTML.

Without ETTP the production of web content will actually become more centralized, as the difficulty of creating dapps will make it increasingly difficult for independent creators to build independent Web3 content. The role of HTML on the web will be reduced, favoring a Javascript first web. According to Google Trends, every year HTML becomes less popular, while frameworks like React become more popular. React is the technology most often used for Web3 dapps, and it is not friendly to average web users. ETTP takes additional complexity that already exists and dramatically simplifies it for the average web user, allowing for ENS domains to be reverse compatible with HTML.

12

I’m not sure who your target user is here, one that finds it too hard to query smart contracts but is willing to query a ettp address to see if it returns true or false. I personally, find it easier to query contracts than to call a web api, but that’s just because I’m more used to it. I don’t think the goal is to have a user do either of those, that the app/wallet/browser the user is doing will handle all these things for them: catching websites, phones, avatars, etc. Is it possible that the “average web user” you’re describing is yourself?

It seems to me that most of the issues you’re describing would be solved by (1) having a browser support ipfs links and have ipfs standardize querying ens links and (2) having the browser/wallet the user is using standardize to supporting ENS.

It is not likely to be supported by any browser in the future, because there is currently no method for disambiguating an ENS name from a DNS name.

I think it’s actually quite likely we’ll see IPFS native support in major browsers in the future. Of course, it would be better that there would be a meta-standard for all content addressing standards (which includes swarm, jstore, etc) but IPFS is so far ahead the others aren’t catching up, and it’s not the scope of ENS to do that.

You point an interesting problem: it’s ambiguous if the user typing example.com wants actually the decentralized version of example.com, but it’s a super edge case and I don’t think any user actually expects that, and they could simply point to ipfs://example.com

The other queries: identity, avatar, phone, social media, etc, is something I see being supported on the client level, not something the user needs so I don’t see why it needs a new epps thingie

1 Like
13

In earlier posts to this thread, I have outlined the benefits of ETTP as a single Web3 protocol that can provide HTML level access to the key new data type of Web3 – the NFT. In this post I will respond more directly to claims that developing ETTP is unnecessary, given other standards under current development.

Claim 1. ipfs:// is sufficient for web browser resolution.

One of the key features of Web3 is unambiguous ownership of and provenance for data. I would argue that the most important role of decentralization in Web3 is in providing a secure method of ownership (including censorship resistance). Provenance is provided by blockchain transactions. The reason that NFTs have become so popular is that they provide a single entity that combines decentralized file storage, demonstrable ownership, and enduring provenance. IPFS is a decentralized file storage system that is designed with certain biases, making it only suitable for certain use cases. The concept of decentralized file storage and delivery is actually a very active area of research, innovation, and economic competition. Even though IPFS might be the most popular file system today, that might change in the future. Current examples of competing technologies include arweave and Livepeer. I believe it could harm the development of the Web3 economy if IPFS became the standard everyone would have to live with.

Claim 2 . We can simply query smart contracts using JavaScript to get file information.

For many years the Web relied on HTML as the industry workhorse. With the rise of Web2, the role of HTML has been reduced, firstly because of increased use of mobile browsers and demand for responsive websites, and more recently because of JavaScript-first frameworks like React. There is currently a possibility that HTML will go basically extinct, replaced by JSX or some other JavaScript framework. This could significantly impact the adoption of Web3, making full stack web development the prerequisite for independent publishing of anything on Web3.

The alternative I propose is an HTML compliant standard for NFTs, including media and avatars, that enables their easy embedding into HTML documents without compromising any NFT features - including ownership, provenance, and decentralized data storage. Part of the standard could include, for instance – being able to right-click on any embedded NFT to see who owns it and to display its provenance information. Adobe has recently come out with complete end-to-end file provenance that can be attached to an NFT – but not to an IPFS file.

Claim 3. IPFS can be made to recognize ENS domains.

I believe IPFS developers would be strongly disinclined to do this. The job of IPFS is to provide a uniform system for content delivery and identification. The job of ENS is to link domain names to all types of content, including files residing on IPFS as well as systems in competition with IPFS. If IPFS were to create their own registry for content using ENS, that effort would be in direct competition with the ENS open system.

Thus, I propose ETTP, an NFT-first protocol for Web3 capable of supporting any decentralized file system. ETTP will be HTML compatible, will be used to disambiguate centralized versus decentralized websites (e.g., the ENS content record of makertop.com vs. its IP address), and will support broad adoption of Web3 by makers of any technical skill level.

14

IPFS already supports resolving ENS names in their default client.

1 Like
15

I don’t believe this is possible or feasible with IPFS. The documentation on IPFS shows only using a gateway or Metamask to resolve domains in the browser using the “/” which is unworkable and confusing.

"In a few minutes, you’ll be able to go to Your_Domain.eth/ and view your website. Note the trailing slash / . Because .eth is not a registered DNS top-level domain, it is normally inaccessible through regular browsers.

Eth.link (opens new window)provides a way for any browser to access your website. Just append .link to your domain. For example, Your_Domain.eth.link . There are no additional steps required for this."

16

I understand the issue, but I don’t think a new prefix is the solution.

Taking a step back: the protocol (http:, https:, ftp:, file:, mailto:, etc.) is the protocol that the client uses to connect to a resource. How a resource is resolved is a different issue.

Our problem is that DNS resolution is so deeply embedded in every Internet activity and protocol, that how to resolve hostnames is not even mentioned. And now we (ENS) comes, and proposes an alternative way.

We must have in mind that a ENS domain may resolve to a web page, an email, an avatar, a crypto address, and so on. For example, I can see mailto:vrypan.eth working for an email client that is able to look up ENS domains and check if vrypan.eth has an email record defined. I could also imagine having an IP record in an ENS domain and doing ssh://root@vrypan.eth.

In my opinion the first step is to define a URI scheme. How do we identify record X of foo.ens in a way that is compatible with existing clients?

For example, mailto:email@vrypan.eth makes sense and it seems OK, but https://url@vrypan.eth is not (browsers will try to authenticate as “url” to the host vrypan.eth, if the were able to resolve the later).

Some of these issues can be resolved by registering the .eth TLD (@brantlymillegan you wrote on twitter that is has been reserved, right?) and creating a DNS bridge.

However, our vision can not be to hide ENS behind a hacked version of DNS, right? So, what is our vision regarding ENS? Mapping ETH addresses to strings was the easy part, but playing nicely with the Internet infrastructure is an other question. There are so many fundamental questions to be answered…

2 Likes
17

What happens when the ENS domain is not .eth but instead .xyz. The browser doesn’t know which domain to use—the ENS decentralized domain or the DNS domain. There needs to be some way to disambiguate decentralized domain names. If it is not the scheme then what is it?