search

eosdac / eosdac-client-legacy

This is the frontend to interact with the DAC smart contracts.
MIT License
14 stars 19 forks source link

Enable placeholders for constitution #83

Closed michaeljyeates closed 5 years ago

michaeljyeates commented 5 years ago

For the DAC Factory we need to be able to offer a standard constitution for them to get up and running without having to clone and modify one in github

We are going to create a boilerplate constitution which has handlebars style variable placeholders, these should be substituted with data from the dac (eg. number of custodians, dac name, thresholds) and then hashed. It will do the same when setting a new one

If the configuration is changed then it will also invalidate the constitution so we should probably include an updated one when any settings are changed that will affect it. Appending the hash to the url of the constitution will prevent any problems when submitting new ones.

michaeljyeates commented 5 years ago

I am thinking that we should start with the dac configuration from here for the substitutions.

https://api.eosdac.io/v1/eosdac/dac_config

This will mean that we have a consistent set of data, the data from this api should map to the template variable dac_config

We should do some pre-processing on this data to allow for datatypes such as times to be substituted, eg. the periodlength property should be available to the template in days, weeks, etc

piecesnbits commented 5 years ago

ok, where shall we "host" the default constitution? and how will it be inserted in the memberterms table when the factory creates the dac?

piecesnbits commented 5 years ago

also, when the config changes, how will the new "hash" be added to the memberterms table? ideally changing the config trx should have a secondary action to update the memberterms. if these two actions are served as separate msigs to the custodians there is a chance that only one will get approved.

michaeljyeates commented 5 years ago

The constitution will be in github, the factory will create it with the initial has, but you are right we would need to update the constitution hash whenever the config is changed (if it would mosify the hash)

piecesnbits commented 5 years ago

it will make things complicated when changing the config with cleos.

piecesnbits commented 5 years ago

probably best to create a default constitution in the factory repo...

piecesnbits commented 5 years ago

or add dedicated "default" branch in our current constitution repo.

michaeljyeates commented 5 years ago

It is going to be a totally new constitution, not based on our one so we will probably have a new repo for it. People can then easily clone it and modify for their needs