ZIP 001: Zano URI Scheme

[matthewjamesr]

UPD: Final URI scheme described in documentation:
https://docs.zano.org/docs/deeplinks

---

  ZIP: 001
  Title: Zano URI Scheme
  Author: Matthew Reichardt 
  Status: Draft
  Created: 2021-01-04
  Updated: N/a

This ZIP is based off of both the Counterparty URI Scheme and Bitcoin's BIP-21.

Abstract

This ZIP proposes a URI scheme for making payments with zano, provide the extended ability to authenticate users via signature requests, and manipulate on-chain marketplace transactions.

Motivation

The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.

Rationale

Bitcoin BIP 21 is a widely used payment URI scheme for bitcoin wallets. Zano should follow this same best practice and modify while extending the protocol to support signature requests and marketplace functions.

It is recommended to include an alias of zano: in a Android/iOS applications. This enables your application to provide a better user experience by easily enabling touch-based authentication and zano payments.

Specification

General rules for handling (important!)

Zano clients MUST NOT act on URIs without getting the user's authorization.

They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.

Operating system integration

Graphical zano clients SHOULD register themselves as the handler for the "zano:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.

General Format

Zano URIs follow the general format for URIs as set forth in RFC 3986. The path component consists of a zano address, and the query component provides additional payment options.

Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986.

ABNF grammar

(See also a simpler representation of syntax)

zanourn  =  "zano:" zanoaddress [ "?" zanoparams ]
zanoaddress  = *base58
zanoparams  =  zanoparam [ "&" zanoparams ]
zanoparam  =  [ amountparam / actionparam / callbackparam / iconparam / labelparam / messageparam / otherparam / reqparam ]
actionparam  =  "action=" *qchar
amountparam  =  "amount=" *digit [ "." *digit ]
callbackparam  = "callback=" *qchar <URL of remote server>
iconparam  = "icon=" *qchar <URL of remote server>
labelparam  =  "label=" *qchar
messageparam  =  "message=" *qchar
otherparam  =  qchar *qchar [ "=" *qchar ]
reqparam  =  "req-" qchar *qchar [ "=" *qchar ]

Here, "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this CIP takes as separators.

The scheme component ("zano:") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters. The rest of the URI is case-sensitive, including the query parameter keys.

Query keys

• zanoaddress: A zano address
• action: action to perform [market_buy, market_cancel, market_list, sign, stake]
• amount: Amount of asset to send see below
• callback: Web location that client queries when responding to action, URL must be sent as an encoded value
• icon: URL to an 48x48 icon file (48x48, gif/jpg/png) for use with authentication services
• label: Label for that address (e.g. name of receiver)
• message: Message that describes the transaction to the sender and receiver OR result of signing if (<action> == 'sign')
• (others): Optional, for future extensions

Transfer amount/size

If an amount is provided, it MUST be specified in decimal format
.
All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions.
e.g. amount=50.00 or amount=50 is treated as 50. amount=50,000.00 is invalid.

Forward compatibility

Variables which are prefixed with a req- are considered required. If a client does not implement any variables which are prefixed with req-, it MUST consider the entire URI invalid. Any other variables which are not implemented, but which are not prefixed with a req-, can be safely ignored.

Callback

A callback to the specified url will be called once the action is performed, and any data will be passed via a POST request.

The callback URL must be a valid URL beginning with http: or https:

When passing querystring parameters for a callback url, the URL must be a URL encoded value.

URL:

https://www.domain.com/folder/script.php?api_key=keyhere&foo=bar

Encoded URL:

https%3A%2F%2Fwww.domain.com%2Ffolder%2Fscript.php%3Fapi_key%3Dkeyhere%26foo%3Dbar

sign Callback Data

When the action is sign the callback data will contain :

• address: address that signed the message
• message: message that was signed
• signature: signature of message signed with address

The callback data will also include any querystring parameters specified in the callback url.

Message Signing Examples

Sign message with address and return data to callback url:

zano:<zanoaddress>?action=sign&message=<message>&icon=https://domain.com/logo.png&callback=https://domain.com/script.php

UI Suggestions

Present to the user whether or not the callback url has SSL enabled.

If action is specified, verify action with user to ensure action is truly desired.

If no address is provided (counterparty:?), prompt user to select address, or use current/default address.

If action is sign and no callback is specified, display the sign message dialog to the user.

If icon is provided, display icon to user when confirming signing action.

Appendix

Simpler syntax

This section is non-normative and does not cover all possible syntax.
Please see the BNF grammar above for the normative syntax.

[foo] means optional, <bar> are placeholders

zano:<zanoaddress>[?amount=<amount>&action=<action>&callback=<callback>&icon=<icon>&label=<label>&message=<message>]

Examples

Just the address:

zano:<zanoaddress>

Address with name:

zano:1JztLWos5K7LsqW5E78EASgiVBaCe6f7cD?label=Devon

Request payment of 1.3 ZANO from "Theagildev":

zano:<zanoaddress>?amount=1.3&label=Theagiledev

Request payment of 5 ZANO from "Theagiledev" with a message:

zano:<zanoaddress>?amount=5&label=Theagiledev&message=Donation+for+all+your+hard+work

Some future version that has variables which are (currently) not understood and required and thus invalid:

zano:<zanoaddress>?req-somethingyoudontunderstand=50&req-somethingelseyoudontget=999

Some future version that has variables which are (currently) not understood but not required and thus valid:

zano:<zanoaddress>?somethingyoudontunderstand=50&somethingelseyoudontget=999

Characters must be URI encoded properly.

Copyright

This document is placed in the public domain.

References

Authparty Authorization Spec by Jeremy Johnson and Matthew Reichardt
Bitcoin BIP 21 by Nils Schneider and Matt Corallo
Counterparty URI Scheme by Devon Weller

[cryptozoidberg]

Final URI scheme described here:

https://docs.zano.org/docs/deeplinks