status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 831 

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing draft EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
ligi 2018-04-20 20:44:06 +02:00 committed by EIP Automerge Bot
parent 491e5df13e
commit 521c3723e1
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
EIPS/eip-831.md
View File

@ -1,6 +1,6 @@
---
eip: 831
title: URL Format for Ethereum
title: URI Format for Ethereum
author: ligi <ligi@ligi.de>
type: Standards Track
category: ERC
@ -10,17 +10,17 @@ created: 2018-01-15
## Simple Summary
A standard way of creating Ethereum URLs for various use-cases.
A standard way of creating Ethereum URIs for various use-cases.
## Abstract
URLs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URL format allows for instant invocation of the user's preferred wallet application.
URIs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URI format allows for instant invocation of the user's preferred wallet application.
## Specification
### Syntax
Ethereum URLs contain "ethereum" in their schema (protocol) part and are constructed as follows:
Ethereum URIs contain "ethereum" in their schema (protocol) part and are constructed as follows:
request = "ethereum" ":" [ prefix "-" ] payload
prefix = STRING
@ -28,19 +28,19 @@ Ethereum URLs contain "ethereum" in their schema (protocol) part and are constru
### Semantics
`prefix` is optional and defines the use-case for this URL. If no prefix is given: "pay-" is assumed to be concise and ensure backward compatibility to ERC-67. When the prefix is omitted, the payload must start with `0x`. Also prefixes must not start with `0x`. So starting with `0x` can be used as a clear signal that there is no prefix.
`prefix` is optional and defines the use-case for this URI. If no prefix is given: "pay-" is assumed to be concise and ensure backward compatibility to ERC-67. When the prefix is omitted, the payload must start with `0x`. Also prefixes must not start with `0x`. So starting with `0x` can be used as a clear signal that there is no prefix.
`payload` is mandatory and the content depends on the prefix. Structuring of the content is defined in the ERC for the specific use-case and not in the scope of this document. One example is ERC-681 for the pay- prefix.
## Rationale
The need for this ERC emerged when refining ERC-681. We need a container that does not carry the weight of the use-cases. ERC-67 was the first attempt on defining Ethereum-URLs. This ERC tries to keep backward compatibility and not break existing things. This means ERC-67 URLs should still be valid and readable. Only if the prefix feature is used, ERC-67 parsers might break. No way was seen to avoid this and innovate on the same time. This is also the reason this open prefix approach was chosen to being able to adopt to future use-cases and not block the whole "ethereum:" scheme for a limited set of use-cases that existed at the time of writing this.
The need for this ERC emerged when refining ERC-681. We need a container that does not carry the weight of the use-cases. ERC-67 was the first attempt on defining Ethereum-URIs. This ERC tries to keep backward compatibility and not break existing things. This means ERC-67 URIs should still be valid and readable. Only if the prefix feature is used, ERC-67 parsers might break. No way was seen to avoid this and innovate on the same time. This is also the reason this open prefix approach was chosen to being able to adopt to future use-cases and not block the whole "ethereum:" scheme for a limited set of use-cases that existed at the time of writing this.
## References
1. ERC-67, https://github.com/ethereum/EIPs/issues/67
2. ERC-681, https://github.com/ethereum/EIPs/pull/681
1. ERC-681, http://eips.ethereum.org/EIPS/eip-681
2. ERC-67, https://github.com/ethereum/EIPs/issues/67
## Copyright