Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-831: Standard URL Format #831

Merged
merged 7 commits into from
Jan 25, 2018
Merged

EIP-831: Standard URL Format #831

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
a870e8b
Add URL Format ERC
ligi Jan 15, 2018
f156733
Add period
ligi Jan 16, 2018
d90db83
Remove "Replaces: 67" and move to Rationale that replaces Motivation
ligi Jan 22, 2018
359f345
Fix a problem with separating prefixes from payload
ligi Jan 23, 2018
25eaa57
Improve rationale
ligi Jan 23, 2018
e790f96
Fix punctuation - clean dashy text
ligi Jan 24, 2018
afabcb5
Add references
ligi Jan 25, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions EIPS/eip-831.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
## Preamble

EIP: 831
Title: URL Format for Ethereum
Author: ligi <[email protected]>
Type: Standard Track
Category: ERC
Status: Draft
Created: 2018-01-15

## Simple Summary

A standard way of creating Ethereum URLs 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.

## Specification

### Syntax

Ethereum URLs contain "ethereum" in their schema (protocol) part and are constructed as follows:

request = "ethereum" ":" [ prefix "-" ] payload
prefix = STRING
payload = STRING
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpicking:

How to distinguish

payload = "with-hyphen"
request = "ethereum:with-hyphen"

against

prefix = "with"
payload = "hyphen"
request = "ethereum:with-hyphen"

?

Perhaps, if prefix is omitted, payload can contain no "-"s?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. We can use the property of 681 that if the prefix is omitted the payload must start with 0x (be an address) - will add this constraint - thanks

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dam - doing this I noticed that it is not working as the address can now also be a ens-domain. And AFAIK the ens-domain can contain a "-" - so this is really a problem - think then we really need to prefix ens - think this is a good idea anyway for future updates - @nagydani - what do you think - or do you have a better idea?


### 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.

`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.

## References

1. ERC-67, https://github.com/ethereum/EIPs/issues/67
2. ERC-681, https://github.com/ethereum/EIPs/pull/681

## Copyright

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