TokenScript meeting #40

Tokenscript Design
1

This meeting is about the data origins of a card.

We already know that card attributes (or card variables - we used those words interchangeably) are provided to JavaScript in different namespaces.

This meeting concludes that <origins> tag, which used to specify the token holding contract of a token, the origins of an attribute value, should apply to activity cards.

An example of such an activity card can be found in the pull-request:

The events top-level elements are treated the same way as if one defines an <attribute…> in the card. For example, in this case, the card has from, to, amount, all of them are defined in the event's data module:

Two problems

<origins> is not an ordered list in the activity card

The origins can be data objects used in attestations too:

    <ts:card type="activity" name="renew">
        <ts:origins>
            <ts:attestation type="Renew" issuer="Attestor"/>
        </ts:origins>
        <ts:item-view xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
            <style type="text/css">&style;</style>
            <script  type="text/javascript">&item-view-renew.en;</script>
        </ts:item-view>
        <ts:view xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
            <style type="text/css">&style;</style>
            <script  type="text/javascript">&renew.en;</script>
        </ts:view>
    </ts:card>

We have not reached the conclusion whether or not multiple-origins work the same way as attributes. For the moment, I think <origins> in an activity card means that for each instance of the origins there is an activity card. For example, with the following TokenScript:

    <ts:card type="activity" name="renew">
        <ts:origins>
            <ethereum:event contract="attestation-registry" type="Renew" 
             filter="subjectPublicKey=${ownerAddress}"/>
            <ts:attestation type="Renew" issuer="Attestor"
             filter="subjectPublicKey=${ownerAddress}"/>
        </ts:origins>
    …
    </ts:card>

If there are three renew events in the contract, and two renew attestations, then the result is five distinct activity cards.

This differs from when it is used for <attributes>, where multi-origins doesn't mean multiple values for the attribute, merely that the TokenScript engine should fetch attribute values by the ordered list of origins specified, and stops when it hits a value.

We decided to ignore this inconsistency for now, since we have not used multi-origins attributes in practice anyway.

Inconsistence with Token Card

With the current draft, a token card's token attributes are in this.token.props namespace. Its card variables is an empty set unless explicitly defined or filled by JavaScript. However, when it comes to Activity Card, the card variables are initialised with the data object of the activity (typically Ethereum event). One might ask that if Activity cards take the "attributes" of its data object into its card variable namespace, why not Token cards take the attribute of its token into its card variable namespace?

However, this behaviour is consistent with action cards, where the card variables are about actions. The token attributes are in a different namespace than the card variables. This is because card variables have a different life space than the tokens, also because such distinction is required for multi-input action cards (e.g. marrying a kitty with another), where both input tokens have their own attributes (e.g. this.input[0].props and this.input[1].props.

Presently, we simply say: "Token attributes are always separate from token attributes even in TokenCards", and we reason that a token card is not necessarily the unique view of a token. For the sake of argument, let's suppose that you got authorised to use a car (you borrowed a car). You have the car token card accessible from your wallet, which is based on the authorisation from the owner (which may be in the form of an attestation or blockchain event - either way, a data object). The card is not an activity card per se because it represents a token with all token actions. Yet, the card variables originate from the authorisation data object (e.g. "maxDistanceInKm: 500", meaning you are authorised to only drive the car up to 500KM).

This also relates to the thinking that the token's representation (TokenCard) depends on the context. For example, an airline ticket looks differently if the plane is on time or late. In the future, it might be designed such that the plane ticket token card is associated with a data object related to the plane's information. It's too early to say for sure how we are going to design context with TokenCards.