Skip to content

Latest commit

 

History

History
172 lines (118 loc) · 6.48 KB

sip-47.md

File metadata and controls

172 lines (118 loc) · 6.48 KB
sip title description status type author category created
47
Signum Name System (SNS)
Proposal for standardized way of resolving aliases and custom URIs into URLs
Review
Standard
ohager
SRC
2022-11-28

Abstract

The Signum Alias feature can be used to resolve URIs into URLs. In browsers, it is possible to use an extension, e.g. XT Wallet, to resolve URIs in the browsers navigation bar to any arbitrary URL. This SIP proposes a simple standard for such URI resolvers, and even supports subdomains and deep resolution to fetch additional values like account id, or avatar image data.

Motivation

If a user enters a customized URI, e.g. sig://johndoe, https://$johndoe or https://johndoe:signum in the browsers URL bar, it is possible to resolve this customized URI into an internet URL.

Aliases in Signum are mutable on-chain data owned by users. Using the standard descriptor, it is possible to reference to any internet resource. To make browsers understand the custom URI, an installable extension is required, such that a URI can be read, resolved and updated according to the resolved URL. The XT Wallet will support this feature, once this proposal is accepted.

Specification

In the following, a structured URI Scheme is proposed, that works in conjunction with the SIP44 description standard and the Alias System, and can be resolved to any other URL, in special to other internet resources.

The proposed structure for the URI follows the official specification as described in RFC3986. The generic version of an URI looks like this

URI = SCHEME://[AUTHORITY]PATH[?QUERY][#FRAGMENT]

For this proposal the relevant components are

URI = SCHEME://PATH

SCHEME = [sig|http|https]
PATH = [$]?[ALIAS.]?ALIAS[:TLD]?[/PATH]?
TLD = [signum]
PATH = ALPHA[ALPHA|DIGIT]
ALIAS = ALPHA[ALPHA|DIGIT]{1,100}
ALPHA = [a-zA-Z]
DIGIT = [0-9]

The TLD is only needed, if the SCHEME is not signum, or no shortform prefix $ is being applied. When using ALIAS.ALIAS, the first ALIAS is considered as subdomain.

The PATH segment can be used for deep resolution.

Examples:

Without subdomain:

sig://johndoe or semantically identical https://johndoe:signum, https://$johndoe

With subdomain:

sig://projects.johndoe or semantically identical https://projects.johndoe:signum, http://$projects.johndoe

URL Resolution

The Alias System of Signum can be used to store the target URL. For resolvers, it is necessary to encounter structured data inside aliases, such that the referenced URL can be read consistently. Thanks to SRC44 this is possible, and the required field for resolving a URL MUST BE hp. The alias name in the URI can either serve as domain, or subdomain. The resolver MUST always start looking for the alias name according to the domain, and then resolves the subdomain.

Example:

The URI sig://johndoe only provides a single domain. The resolver reads the descriptor of the alias johndoe and resolves to the URL provided in hp, which is here https://github.com/johndoe

{
  "vs": 1,
  "hp": "https://github.com/johndoe"
}

Subdomains

The URI schema allows support of subdomains. As mentioned before, the URL resolver must resolve the domain alias first, and then the subdomain alias. Therefore, aliases can reference forward to other aliases using the al field. The URL resolver MUST detect circular dependencies and stop further resolution.

Example:

The URI sig://myprojects.johndoe provides the domain johndoe and the subdomain myprojects. The resolver reads the descriptor of the alias johndoe and resolves to the URL provided in hp, which is here https://github.com/johndoe

The SRC44 compliant alias descriptor for johndoe may look like this:

{
  "vs": 1,
  "hp": "https://johndoe.com",
  "al": "johndoe0myprojects" 
}

The alias johndoe0myprojects can be any kind of valid alias, i.e. jd0000001, or 0xDEADBEEF. It's just a reference to another on-chain data.

As the domain alias is forwarding to johndoe0myprojects, the resolver MUST look up the referenced alias and check if the nm (name) field matches the queried subdomain

The SRC44 compliant alias descriptor for myprojects subdomain (using the Alias johndoe0myprojects) may look like this:

{
  "vs": 1,
  "nm": "myprojects",
  "hp": "https://github.com/johndoe"
}

Multiple Subdomains

As an account can have multiple subdomains (no fixed limit set), the resolver MUST resolve each referenced alias until it finds an alias with a matching nm field.

The search MUST stop if

  1. nm field matches requested subdomain
  2. no further al field is available
  3. the al field does not resolve to an existing alias
  4. a circular reference occurs

Keep in mind that resolving to subdomains takes more time the more subdomains are linked to the alias reference list. Resolving subdomains can cause O(n) requests.

image

Signum Default Domain

For simplicity - while typing the URI inside the browsers URL bar - the http and https schemas are acceptable, but this requires the user to type the defaults (non-ICANN) Top Level Domain (TLD) :signum or using the shortform prefix $. The following URIs resolve always to the same URL:

  • sig://arts.johndoe
  • http://$arts.johndoe
  • https://$arts.johndoe
  • http://arts.johndoe:signum
  • https://arts.johndoe:signum

Custom TLDs

When using non-default TLDs, i.e. not signum, it has to be appended to the URI, using :<tld>. The shortcut $ does not apply here.

  • sig://arts.johndoe:web3
  • http://arts.johndoe:web3
  • https://arts.johndoe:web3

Deep Resolution

Per default a URI resolves to the alias' hp field, but it is possible to select a specific field inside the SRC44 compliant structure as long as it is available. This way it is possible, to use the URI and resolve to an Account Id (using the ac field), or even custom fields.

Example:

The URI http://johndoe:signum/ac would return the account Id for johndoe, if it exists, while http://johndoe:signum/tp returns the type and so forth.

This counts also for custom fields, so it is possible to do http://johndoe:signum/x-myfield.

Compatibility

This proposal does not require compatibility considerations.

Copyright

Copyright and related rights waived via CC0.