This is actually a pretty good question, I wonder how I missed answering it in May.
For example, maybe I wanted to accept Pizza Payment Tokens (PPT) as payment and utilise Pizza Delivery Tokens (PDT) for the delivery. In the top-right, I'd like to show the user's current PPT balance and I'd also like to show PDT held by the user after the purchase occurs (similar to the screenshots in the design paper).
Let's look at PPT and PDT separately. If a user has PPT (Pizza Payment Token), he should already has the TokenScript for that token running in his wallet (he obtained it when he acquired the token in the first place), which can handle the balance display in the checkout together with its token action (like "spend 100 get back 20"). The interesting thing here happening is the PDT: Pizza Delivery Token.
Since your website sells Pizza, you should know what actions are relevant to the users. Let's say the Pizza delivery token has 4 actions.
- Redeem pizza.
- Authorise someone to redeem pizza.
- Share your recipe.
- Get 1 for free when you have purchased xxx.
Let's say that you run the Pizza operation from a vantage location and you are not doing "Get 1 for free when you have purchased xxx" promotion per se. The smart contract for managing the pizza token (likely not made by you) has the function to do so, you just don't enable it for the Pizza tokens issued by you. What you can do is:
- Get the signed TokenScript available for PDT (the PDT contract author has it on their website or they can email it to you).
- Delete the 4th action card (this won't break the signature if you do it right)
- Serve it from your web site
- Link to it on the checkout page of your Pizza website through a reference using HTML
What the user does is this:
- Checkout (use "spend 100 get back 20" action if he can).
- Hit "confirm" - he gets a confirmation screen where he sends the Ethereum transaction. At this confirmation screen, the slimmed down TokenScript is used to render the PDT on the confirmation.
- When the Pizza Delivery Token arrives† the user's wallet, the TokenScript is activated to display the token in the user's wallet (with a countdown if pizza is ready soon) and allow the user to perform the actions (like "Redeem Pizza" which might display a QR code at the shop)
† The actual smart contract event which signals the arrival of the token is in the TokenScript he downloaded at the confirmation screen.
Now let's circle back to the problem how did user acquire the TokenScript for PPT in the first place. The TokenScript for that token is provided by the website which sells that. It can be from an imaginary Pizza Token Association which metes out such tokens to members, or it can be your pizza website too, a bit like Crown Plaza selling casino chips and the stuff that casino chips can be used to buy. In reality, though, I don't think there will be a Pizza Payment Token at all. In the Internet economy, there are only rooms for a few payment tokens. Most likely, the user acquires a Pizza Gourmet token which can't be used to pay for Pizza but allows 10% discount for Pizza paid in Ether or any other payment token.
Now, to Victor's question:
What are the benefits of doing in this way?
A website knows when the user is about to get a token, and what actions are relevant to the user. It can smartly provide actions without the user downloading 1MB TokenScript at the outset. Normally, if you use a website, the content is downloaded on the go. The users don't first download a full website then start browsing, so why TokenScript should be different.
If a token is acquired through using a website, the website can be assumed available, hence having TokenScript there doesn't add additional availability constraints. Had we designed in such a way that the user acquires a token through transacting on a website, the TokenScript, however, comes from github, then the users can only successfully acquire and use a token if 𝑏𝑜𝑡ℎ your website and github are online.
TokenScript itself is designed to run actions in a security sandbox (implementation pending). It needs to interact with the web elements surrounding it. Having it linked in the webpage allows such interaction. This kind of interaction isn't apparent in the "checkout" case because Pizza is a simple product, but very relevant if the user is getting a Legendary Elf Sword in a game.