Why do we use cards vs mini Dapps

Tokenscript Design
1

Why do we use cards instead of mini apps?

Would not users want really rich experiences on tokens, than simple cards with limited visual design/interaction capabilities?

@weiwu.zhang

2

Technically, it's about composability.

Let's imagine that you are buying beer from EtherBeershop which is a web3 service. With TokenScript, in the purchasing transaction, you will have two Action Cards from two different issuers.

One is the proof of age, an action of your "AustPost Identity Token", which produces an attestation; the other is "Pay" action, of your "Bartercard Payment Token", to pay down the payment for the beer.

These can work together to create an attested transaction using that attestation that shows the buyer is of drinking age. The "proof of age" Action Card is an action of your identity token; the "pay" action is an action of a Payment token, each card are written by their corresponding token issuer.

If using MiniDapp, you might have two MiniDapps, one is called "AusPost Identity minidapp" which gives you a proof of age, the other is "Pay MiniApp" which allows you to use a payment token for checking out. They need to figure out an interface to work together, or they will have to resort to trusted 3rd party model (you prove age to the shop separately from the transaction, instead of doing an attested transaction). The decentralised web needs stuff like that from different sources.

A similar situation happens if you need to "Enable" (approve) a 3rd token (e.g. AAVE) to deposit your DAI, then transact using that 3rd token (AAVE). Imagine the DAI minidapp gives you the enable functionality, and AAVE gives you deposit functionality. A user is left to do them separately (or worse, blindly trust the AAVE minidapp to sign transactions to his DAI contract, knowing that AAVE minidapp is not signed by DAI folks).

In terms of design philosophy, it reflected the difference in web3 vision. Is web3 a tokenised web, or is it a web for tokens? In MiniDapp, the token is the protagonist on the stage. MiniDapp allows you to do token functionality, and you use minidap to access Token functions. In TokenScript, the web service (and web application) is the star of the show, the tokens are the enabler and cast. Observe the EtherBeerShop example, the star is always been the beer or any service you wish to enjoy through the use of the token. The cards simply enabled a tokenised functionality, finish its task quickly and let the web service enabled by it to continue. For a more elaborate example, my article has differentiated App and Token through the Aranjuez user story.

If you watch Rick and Morty, in the minds of MiniDapp, a token is like Rick with all the power and smartness; users' can't get their eyes off him.

In TokenScript design, a token's action card is more like a Mr Meeseeks, pop into existence to solve a problem and go away; the people it serves are the star (Rick, Morty, Jerry). A token is like Mr Meeseeks Box.

meseeks

To put that design philosophy to an actual example, let's say that you have the following token:

Unsold Voucher: Sunshine Cost

Book 4 nights in a row in a hotel in Sunshine Cost with spare capacity, once.

The TokenScript method:

  1. User access a hotel website like Marriott or hotel search engine like Agoda. (or select one from those listed in the token card
  2. The user uses a token card to narrow down the search to the hotels.
  3. User book, checkout, and at the point of payment, in an action card, produce a transaction that trades the token in exchange of a hotel booking.

In this story, cards are used 2 to 3 times and pop into existence and go, like a Mr Meeseeks.

If you envision a "Dapp-like" structure that provides "rich experience", more like Rick, the process might be:

  1. User click "Book Hotel" from the token card
  2. A new card opens with a listing
  3. User checks each listing, the animosities, the location etc. Each hotel opens a card and the user can go back and forth between them.
  4. User chooses the right hotel, pops up a card to fill in name and address;
  5. User pays the hotel with the voucher.

Such a scenario would not be "Tokenscript-ish" and if that is what you want, a card would be a misdesign, as it fails to support the rich experience like search, browse, show pictures, choose check-in time etc etc. But it also diminishes the very reason you tokenise something - tokenisation allows "frictionless market" and "integration" - by having everything in the token miniapp, you are not really making it easier to exchange in a market, merely replacing the existing market like Agoda with your market. and by having Token doing all the work, you are not really using token to integrating a decentralised web, merely replacing the integration with your own token app.

But isn't decentralised app supposed to be an app?

Yes, and I would call Agoda - in our example of "Unsold Voucher" - a decentralised app, as you can book various hotels using various tokens. I see TokenScript as a vital component of such a decentralised app.

If you think Agoda is still too centralised because they became a portal, you can set up another hotel booking web app, and leverage on tokens to provide better experience and competition.

For example:

  • If a token supports reviser bidding (user deposits how much they want to pay and hotels bids for customers), you can use that token to improve booking experience. The reverse bidding is created by an action card.

  • If a subscription token allows subscribers to have 5 free hotel stays a year (50% off for the next 5 stays), you can gear the purchase experience towards such token holders, for example, recommend holidays that is just 5 days long.

  • Since you know what users' token can do, you can write a better AI and beat Agoda. For example, an American Express Centurion token holder might have different preference in their user experience (might require the user to play that card).

  • You can also issue tokens - if the user finished a booking, you can create a booking token out of that transaction so the users can see their booking in their wallet. That token is another "Meseeks" that can do magic, for example, swipe open the hotel's BBQ area door (a card), serve as an authorisation token to get you to connect to the hotel wifi (another card), or access hotel in-room dining menu without first report your room number and surname (login-less access to web services through TokenNegotiation - a card is not needed for that to happen).

What you will then create would also be a decentralised app too, and perhaps a better one than Agoda. At every turn of technology, there are new startups taking advantage of it and win over the aging competitors.

Composability also allows new techs that improve trust. For example, when it comes to the Delivery-versus-Payment transaction, you pay 10 "Payment Token" to get a "CryptoKitty". Ideally, you want to see what you are buying in the action, however, the buying action might be provided by the signed code from "Payment Token" issuer and the rendering of the kitty you are buying is done through the signed code from "CryptoKitty" issuer. Cards provided a fine way to compose the two sides and give user confidence what they are going to get.