Radspec: move known function list to be a parameter / run-time extension

[sohkai]

Radspec itself should defer to a number of sources to fetch function descriptions, but ideally we would allow the user to specify their own overrides either during instantiation or runtime. It is also likely important that these overrides can be applied globally, or only for some contract addresses.

Doing so will allow us to move hardcoded function names away from the package itself to be closer to their intended use case (e.g. #87).

[0xGabi]

What you think of allow users to publish using aragonPM to the radspec.eth or open.radspec.eth subdomain and have a convention that if the contract value is: 0xFFF...FFF then we know the content will be a radspec description file like:

{
	address: "0x0123..0123"
	knowFunctions: {
		'setOwner(address)': 'Set `$1` as the new owner',
	  	'setOwner(bytes32,address)': 'Set `$2` as the new owner of the `$1` node',
	  	'transfer(address,uint256)': 'Transfer `@tokenAmount(self, $2)` to `$1`',
		...
	}
}

I'm still trying to figure out how we can get the information from the Agent 🤔
An idea is assigning a specific "radspechash" to each contract subdomain definition and during publish we have a system to only allow a owners of the contract to publish, in the future we can create an intent to decided with a vote on the aragonPM dao.

[onbjerg]

I wonder if it is feasible to just have a mapping of 4bytes -> description as opposed to having to apply descriptions to every method of every address, since a lot of contracts on mainnet are really just duplicates of existing contracts or implementations of a specific interface/standard (like ERC20).

Each of these contracts probably share the same descriptions, such as the case with ERC20 and other token standards.

Radspec has the capacity to tweak the descriptions depending on the context of the contract (e.g. include the appropriate token symbol by fetching it from the contract).

I think that would greatly simplify the format that descriptions need to be stored in on an on-chain or off-chain external registry, and it would also provide opportunities for fast lookups and caching.

Thoughts?

[sohkai]

I wonder if it is feasible to just have a mapping of 4bytes -> description as opposed to having to apply descriptions to every method of every address, since a lot of contracts on mainnet are really just duplicates of existing contracts or implementations of a specific interface/standard (like ERC20).

I think this is the way to go, and I believe it's pretty much what we're doing by checking the on-chain registry (and we may also want to check 4byte.directory), but we will still want overrides for specific addresses once we know about them.

For example, deposit(uint256,uint256) has all sorts of meanings depending on the contract type.

[onbjerg]

There is an on-chain registry?

Also, if it is any help then we can fairly easily pull out a list of all 4bytes and their Radspec descriptions for all existing Aragon apps from Apiary :)

[sohkai]

There is an on-chain registry?

There's the parity one that is used by some wallets (see how we use it and eth-method-registry). I believe 4bytes also has an on-chain registry (it may be the same one).

However, the problem with these registries is that any one can register the signature, and it's first-in-first-come.