Skip to content

Commit

Permalink
EIP-1710: URL Format for Web3 Browsers (#1710)
Browse files Browse the repository at this point in the history
  • Loading branch information
Bruno Barbieri authored and axic committed May 19, 2019
1 parent b1dd057 commit c2eca1e
Showing 1 changed file with 66 additions and 0 deletions.
66 changes: 66 additions & 0 deletions EIPS/eip-1710.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
---
eip: 1710
title: URL Format for Web3 Browsers
author: Bruno Barbieri (@brunobar79)
discussions-to: https://ethereum-magicians.org/t/standarize-url-format-for-web3-browsers/2422
status: Draft
type: Standards Track
category: ERC
created: 2019-01-13
requires: 155
---

<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->

## Simple Summary

A standard way of representing web3 browser URLs for decentralized applications.

## Abstract

<!--A short (~200 word) description of the technical issue being addressed.-->
Since most normal web browsers (specifically on mobile devices) can not run decentralized applications correctly because of the lack of web3 support, it is necessary to differentiate them from normal urls, so they can be opened in web3 browsers if available.

## Motivation

<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
Lots of dApps that are trying to improve their mobile experience are currently (deep)linking to specific mobile web3 browsers which are currently using their own url scheme.

In order to make the experience more seamless, dApps should still be able to recommend a specific mobile web3 browser via [deferred deeplinking](https://en.wikipedia.org/wiki/Deferred_deep_linking) but by having a standard url format, if the user already has a web3 browser installed that implements this standard, it will be automatically linked to it.

There is also a compatibility problem with the current `ethereum:` url scheme described in [EIP-831](https://eips.ethereum.org/EIPS/eip-831) where any ethereum related app (wallets, identity management, etc) already registered it and because of iOS unpredictable behavior for multiple apps handling a single url scheme, users can end up opening an `ethereum:` link in an app that doesn not include a web3 browser and will not be able to handle the deeplink correctly.

## Specification

<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->

### Syntax

Web3 browser URLs contain "dapp" in their schema (protocol) part and are constructed as follows:

request = "dapp" ":" [chain_id "@"] dapp_url
chain_id = 1*DIGIT
dapp_url = URI

### Semantics

`chain_id` is optional and it is a parameter for the browser to automatically select the corresponding chain ID as specified in [EIP-155](https://eips.ethereum.org/EIPS/eip-155) before opening the dApp.

`dapp_url` is a valid [RFC3986](https://www.ietf.org/rfc/rfc3986.txt) URI

This a complete example url:

`dapp:1@peepeth.com/brunobar79?utm_source=github`

which will open the web3 browser, select `mainnet` (chain_id = 1) and then navigate to:

`https://peepeth.com/brunobar79?utm_source=github`

## Rationale

<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
The proposed format attempts to solve the problem of vendor specific protocols for web3 browsers, avoiding conflicts with the existing 'ethereum:' URL scheme while also adding an extra feature: `chain_id` which will help dApps to be accessed with the right network preselected, optionally extracting away that complexity from end users.

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

0 comments on commit c2eca1e

Please sign in to comment.