A user obtains a TokenScript in two ways.
-
If the user purchases or obtained a token through a website, the TokenScript for that new token is shipped from that website[^1.
-
If the user needs a TokenScriptn without going through a dapp website, (e.g. he receives a token from a friend), the user-agent (wallet) tries to find the TokenScript for that token by accessing a repo server, sourcing data from this repo.
This repo can be decentralised with the rise of reliable decentralised storage.
When you deploy your Tokenscript, please also send a copy to this repo in the form of a new Pull Request. By doing so:
-
If a user gets a token without going through any of the dapp websites with your TokenScript deployed, they can still get a copy from here.
-
When we upgrade the schema, we know who to talk to for updating existing TokenScript.
When you submit the TokenScript, create a new directory following the convention as specified.
- A user receives a token directly.
- A user scans a QR code or opens a link that represents a token-holding smart-contract.
- A user gets a "MagicLink" which allows him to redeem a token.
- A user recovers a key backup, and the user-agent discovers that he/she owns a few Token.
Check user-agent behaviour for how a user-agent is supposed to communicate with a repo server.
Likely so in 2019 and perhaps 2020 as well. In the first two years, TokenScript schema and namespace are versioned in the same way. A user-agent only works with TokenScripts whose schema and namespace are both supported by the user-agent.
Beyond 2020, a user-agent would work with any TokenScript whose namespace it supports, even if its schema is not supported. By such an arrangement, TokenScript schema can evolve at a faster pace than its namespace, by adding new elements and not removing old elements; but it leaves room for mistakes, resulting existing Tokenscript becomes invalidated. We think it's a fair trade-off.