Tech Planning - Decoding call data

[rossneilson]

This was a great tech planning session where we discussed the possibilities we have for both displaying existing proposals as well as how users will build their own proposals.

I think the conclusion we came to is that there are two layers to this. There is the most basic layer where we have the minimal amount of data, essentially just the ABI. This UX would be similar to what we already have DXvote of course with some improvements but we would be limited in how smooth we could make the experience. essentially we would be limited by the clarity of field names and potentially natspec comments assuming we could fetch them via sourcify.
This is fine for developers but ultimately would prevent non developers or technically minded people from creating proposals beyond the most basic moving of funds.

To achieve the UX we want from our figma designs and to bring the proposal creation process into the hands of more people requires more details than are contained in the ABI. The main ways we can do this is to give more detailed components for example with token amounts, time, date, integer, decimals these would all just be the same component if interpreting the uint256 types from the ABI but here we can make inputs easier for the user. Other things are mainly the detailed descriptions we can give to function calls as well as additional helper strings for fields. (Also lots more we can add here)
The rich data can be thought of as the core data of the ABI as well as the knowledge more experienced users have built into the contract data.
How we implement this is still undecided for the most part but the current thinking is to have DXdao have ownership over some sort of on chain registry available to all guilds choosing to use it (of course they could always fork their own).

However if we don't have rich data for a contract then we will always fall back to the ABI provided data.
Then another layer down would mean just displaying raw data but this shouldn't often be the case and likely these proposals should be flagged as extra dangerous in the UI.

[carlbarrdahl]

Great summary of the discussion @rossneilson!

The NatSpec (https://docs.soliditylang.org/en/v0.8.13/natspec-format.html) mentions a custom tag which could potentially to describe what kind of component this method renders, for example:

contract Tree {
    /// @notice Set the tree age to `numYears` years
    /// @custom:component NumberInput
    function setAge(uint256 numYears) external {
        // set the age into storage
    }
}

There's also the RadSpec (https://github.com/aragon/radspec) to create dynamic expressions:

Which outputs:

{
  "methods" : {
    "setAge(uint256)" : {
      "notice" : "Set the tree age to `numYears` years",
      "custom:component": "NumberInput"
    }
  }
}

It seems the notice, params and custom tags can be used to generate rich detailed UI for the functions.

[rossneilson]

Oh nice, will look into this, we discussed just adding an additional field but perhaps this works better
I've made an issue to update our schema to be compatible with natspec #714

[mprasanjith]

The issue is because the contracts aren't under our control, we won't be able to introduce the @custom: fields.

Btw RadSpec is super cool! Its by Aragon, curious if they're using it on their UIs anywhere.

[rossneilson]

Interesting idea I've just had. We were discussing having a registry vs just a json file in ENS for rich contract data yesterday. The issue with ENS was that it would just be a big long list and finding what had changed when updating would be difficult and could result in a small change elsewhere which could be malicious.
But we could absolutely build a UI for ENS updating that checks the ipfs file being updated to check if it is json and if it is then show a diff between the old and the new one, could get around that.
This would also be useful generally for ENS pointing to a json object.
(The remaining issue would be scaling, the list could get big and take time to download - dont think its too big an issue though)

[mprasanjith]

It would be even better if the registry becomes its own repo, with the master branch deployed to the ENS. All changes should require PRs, and that means we'll have diffs and proper reviews.

[rossneilson]

True, although we would want ultimate history to be on chain not gh