TokenScript meeting #39

This meeting discussed what TokenScripts and ASN.X modules are needed for the MVP attestation use-case.

We need 3 Tokenscripts

  • cheque-generate-action.xml is an action on WETH token which allows ETH tokens to be sent to someone by cheque. It assumes an attestation-capable contract being approved by the user on the WETH token. (We haven't had a mechanism to check if that dependency is met.)
  • cheque-redeem-action.xml is an action available to the user if the user received such a cheque. It generates a redeem transaction.
  • identifier-attestation.xml is an anonymized attestation on identity. This is obtained from an authority.

We also need 3 data object (defined by <namedType>) in (2 modules)

In the meeting we went through the TokenScripts and discussed possible designs on this draft.

We also went through how introducing <ethereum:event>/<input> (or source/origin) removes the need to defining <ts:attribute> as well as its syntax.

Yes, and James Brown proposed a new element for a simple model which I agreed (instead of using distinct as we planned to do with <token>. Here is what he proposed (I called him up today to make sure we are on the same page as of the proposed use of <source>)

First, instead of this:

We should have this:

<ts:card type="activity" name="ownerApproved">
        <ethereum:event type="Approval" filter="owner=${ownerAddress}">
    <ts:item-view xml:lang="en" xmlns="">
        <style type="text/css">&style;</style>
        <script  type="text/javascript">&item-view-ownerApproved.en;</script>
    <ts:view xml:lang="en" xmlns="">
        <style type="text/css">&style;</style>
        <script  type="text/javascript">&gaveApproval.en;</script>

Notice that he used the word source and I'll go along with him for now (whether or not we consistently use source or origins is a separate topic).

Now, what to do with the JavaScript API? Remember we never standardised the JavaScript API, thinking that we first must fix the XML schema. We had some thinking on card property 9-meetings ago, like this:

			nodeRefs : namehash.hash(this.props.fullName)
		}, function(error, tokenProps) {
                ... view update code ...

I propose that sourced data is accessed throught .source insetad of .props. That is, if without using React.js, it would look like this:

const {from, to} = web3.card.source; // does the job of line 75-90

Now let me reason why card.source is not card.props. There are 2 reasons.

1. The same thinking can be applied for <input> and <output>

So we might have card.input[0] and card.input[1] at the same level as card.source. The same goes for constructing card.output albeit more complicated. There are just not enough namespace to hold data from 1st input, 2nd input and output all under .props.

2. structured data probably should be treated differently than card variables

when it comes to sourcing data from a module (in this case an event), the structure is tree-like and not flat like how <ts:attribute> used to work. For example, imagine you have an event that represents a vote, you might have structures like this as card.source (re├źncoded in JSON for the convenience of discussion)

    "author": {
        "name": "Weiwu",
        "address": "0x808735070620485"
    "representitive": {
        "name": "James Brown",
        "address": "0x8093804230437ac"

Which gets you stuff like and, unlike the traditional arrangement of attributes.

Now having explained the JavaScript API and XML schema proposed, let me propose card to be the top level. That is:

    const {from, to} = card.source; // does the job of line 75-90

Instead of

    const {from, to} = web3.card.source; // does the job of line 75-90

As of why card is top-level, let's not forget we are talking about how to code JavaScript in a TokenScript card, not how to access TokenScript card from a website. In this context, JS works in a special environment, card serves a similar purpose of window of a website, and developers have to worry about an already-existing global variable also going by the name card inherited from the website. Whereas web3 was designed to be called directly and we may still choose to provide API to websites under web3 namespace (and continue to use 'web3.token' if we like).

I have made a proof of concept implementation in java of this protocol along with asn specifications of the required objects and committed this to Within the data-model folder I have added a markdown file discussing implementation aspects of this.