The storage mechanism for resolvers is a key-value system.
field records: Map String ByStr
In order to store complex and nested data ZNS supports a very flexible keying system.
Instead of a flat representation of records like DNS.
A 127.0.0.1
A 1.2.3.4
AAAA ::1
BTC 13xb4...
ETH 0x12345...
We represent a nested structure of keys and values inside a simple map.
dns.A[0]=127.0.0.1
dns.A[1]=1.2.3.4
dns.AAAA[0]=::1
crypto.BTC.address=13xb4...
crypto.ETH.address=0x12345...
And on request transform them into this:
{
"dns": {
"A": ["127.0.0.1", "1.2.3.4"],
"AAAA": ["::1"]
},
"crypto": {
"BTC": { address: "13xb4..." },
"ETH": { address: "0x123..." }
}
}This enables us to use flexible JSON-Schema/Protobuf/OpenAPI standardizing to iterate faster.
Here is a tentative list of record types.
The crypto.* records are for receiving cryptocurrency. The system uses the
standard codes/symbols found on coinmarketcap.
For a Bitcoin address the key is
crypto.BTC.address=1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2
The Ethereum address the key is
crypto.ETH.address=0x0b8202db02472ecf3d4d0185eb26998889663cf2
If a currency requires the use of a custodial address like a Memo, Destination
Tag, or Payment ID i.e. currencies like EOS (EOS), Ripple (XRP), Stellar Lumens
(XLM), Binance Coin (BNB), or Monero (XMR), an extra field can be specified besides address.
This means an EOS address is represented as an account name and public key
crypto.EOS.address=eosisawesome
crypto.EOS.memo=EOStWeu4m4GFg7MSEYsxJtqTFn5AaNVN2MSEYstWetqTFn5Au4m47
A Stellar address can be represented as an account id and memo
crypto.XLM.address=G5CHCGSNFHEJMRZOX3Z6YVXM3XGCEZWKCA5VLDNRLN3RPROJMDS674JZ
crypto.XLM.memo=random@email.com*bittrex.com
TODO: Take a look at the full list of crypto keys that we support.
The ttl record behaves like a DNS TTL, instructing clients to cache their
records for a specified number of seconds. If this record does not exist it
defaults to 0.
ttl=86400
The tod record specifies a Unix time where all records become invalid. If not
specified all records are valid forever.
tod=1576872110
The img.* records link to various images to be used in GUIs.
The img.icon record provides a URL to a small image used to identify a user.
Optionally you can supply smaller sizes inside the keys. The plain img.icon
record, if provided, is assumed to be the largest image.
img.icon_32x32=https://someurl.com/icon-32x32
img.icon_192x192=https://someurl.com/icon-192x192
img.icon=https://someurl.com/icon-512x512
The dns.* records simulate traditional DNS records. All standard records
supported by the RFCs are supported. And all records that can support multiple
entries are arrays. i.e. A, AAAA.
dns.PTR=somdomain.com
dns.A[0]=1.2.3.4
dns.A[1]=5.6.7.8
The allowed_nodes[] records specify what ZNS nodes are allowed to resolve to a
name in the client. If left blank all names can point their resolver address
validly to the resolver.
allowed_nodes[0]=0xaa66da5bca1d0fc6475c2f88ae7b7591df79abcb92923bac79e41ccc44a89efc
allowed_nodes[1]=0xca74b52c4e518ee0e376a629a4a3d6670c479fff114af9e2ecec1b790107dd12
The app.* records are where all ZNS application integrations will go.
The website.* records are used to specify the assets for a website. The
website.type is used as a discriminant when specifying how the website is
hosted.
A url based website with website.type of url
website.type=url
website.url=https://google.com
An IPFS based website with a website.type of ipfs
website.type=ipfs
website.hash=Qmed66a3479fe37f17ca74b5214af9e2ecc6a6f4e518e0c029a4ec1b790107dd12
A Swarm based website with a website.type of swarm
website.type=swarm
website.hash=0x37f17caf4e518e0c029a4ec1b7901e74b5214af9e2ecc6a6d66a3479fe07dd12
An DNS based website with a website.type of dns
website.type=dns
dns.A[0]=1.2.3.4
The prefix record specifies a prefix to be added on to each key.
app.twitter.user=Maisie_Williams
app.twitter.verification_signature=0x029a4ec1b7901e74b5214a37f17caf4e518e0cf9e2ecc6a6d66a3479fe07dd12
Is equivalent to
prefix=app.twitter
user=Maisie_Williams
verification_signature=0x029a4ec1b7901e74b5214a37f17caf4e518e0cf9e2ecc6a6d66a3479fe07dd12
If you have an application that you only want to publish certain data you could make a resolver that hardcodes a prefix for you to only allow certain types of data to be read off of some subdomain. This is probably most useful inside an application specific context.
The invalid.* records are all invalid. To be used in conjunction with prefix
to disable resolver.