Specification: Data Structure

[lkngtn]

We need to determine what data needs to exist within the registry and where it should be stored.

It needs to be possible for a wallet which is preparing a transaction for a user to query the registry and find a mapping between the function they are calling and the registry entry if it exists.

If the user is interacting with a proxy, the wallet should be able to identify that it is a proxy and indicate that to the user along with the radspec docstring for the actual function being executed.

It's not strictly necessary for the query to be directly to the registry though that would be preferable from a privacy standpoint. If necessary there can be a centralized service but it should be easy to validate the returned result agains the chain directly, as the intention is not for the the user to trust the centralized service provider to provide the docstring.

[willjgriff]

If we are just storing the radspec string for a function I think the data structure should be as simple as

mapping(bytes4 => radspecString) private registeredFunctions; // Function signature => radspec string

Unless we need to also populate the radspec string with the functions arguments before returning it, in which case I would suggest storing the functions argument types in an enum array in a struct in the mapping. However, presumably this isn't necessary as the current radspec processing must input the arguments after fetching the string.

In which case the registered radspec string will need to formatted to use standardised identifiers to determine where arguments are in the string. Eg _0, _1, _2 for each of the 1st, 2nd and 3rd arguments in the function. Eg

Burn `@tokenAmount(self.getToken(): address, _0, true)` in exchange for redeemable tokens.

For

redeem(uint256 _burnableAmount)

If the radspec strings or doc strings are likely to be significantly bigger then we could store the hash of them in the contract along with an IPFS hash (which is probably the same) that can be retrieved by the calling code.

As for determining whether a contract is a proxy or not, the only way I know of is by calling a function on the contract that only a proxy will return a value for eg proxyType() on the Aragon proxies.

[onbjerg]

I think you're on the right track @willjgriff, but I think storing IPFS CIDs instead is the way to go, since strings could potentially grow large, especially if we facilitate tooling to write strings that are not necessarily on one line (i.e. an editor in the registry app or something).

Furthermore, we should think about internationalisation. Most strings would presumably be written in English, but I think there might be value in supporting other languages in the long run. We can always fall back to English. This could either be done by having a file format such as a hash of ISO 639-1 language codes to Radspec strings, which could lead to large files on IPFS, or we could store it on-chain using multiple mappings/a mapping and an array or something similar.