The contribution contract implements an ERC721 interface which
represents any contribution.
The contributions are non-fungible (as opposed to the Kredits tokens)
and can be not be transferred. The contract stores the history of any
contribution.
Contributions can be claimed which will issue the Kredits tokens to the
contributor.
This is an early implementation and misses some access control and
probably more things.
This allows to filter contributors by the account entries.
For example:
```js
Contributor.filterByAccount({site: 'github.com'}); // returns all
contributors with github account
Contributor.filterByAccount({site: 'github.com', username: 'bumi'});
// returns bumi
```
This moves the whole checks if everything is running into its own class
and is no longer inside the different functions.
Makes the functions smaller and the healthcheck can be used from the
client only if wanted/needed.
This reuses the kredits library functions in the helper scripts and
seeds. We no longer need to add IPFS hashes manually but simply can
provider contributor/proposal data.
This moves the Kredits initialization to the instance which allows us to
be more flexible with handling contract addresses.
Example:
var k = new Kredits(provider, signer, {Registry: '0xabc'});
k.init().then((kredits) { ...});
var k = new Kredits(provider, signer, {Contributors: '0xabc'})
k.Contributor.add(...);
This allows to provide options like gas price/limit settings for the
state changing contract calls.
These options are simply passed to the ethers contract instance.
We need to provide the gas limit when using the jsonrpc provider.
(ganache failed with revert if not enought gas was provider)
This makes it easier to handle truffle arguments which we for example
need to specify the network.
So we ask the user for input instead on using the argv array which might
change.
This persists the state of the ganache db and uses a fixed mnemonic
code to create accounts.
It now acts more like a local presistent database and no need to
send funds to the accounts after restart.
The batchVote function accepts an array of proposal ids and votes for
every one.
Normally arrays without fix length are problematic and gas usage can not be
estimated really well. So we need to see how that works or what other
pattern could be used.
Adding a voterIds array to the proposal.
This allows us to check if a user already has voted on a proposal.
As this is not directly supported by the default proposals accessor this
also adds a getProposal function to get all proposal data.
So far we only allowed calls to the Contributors contract from the
Operator. With the new registry concept we can call functions again
directly on the Contributors contract (without the need to call it through
the operator).
This changes the authentication for the contributor management functions
to allow either core contributors or the operator to call them.
In the future I envision a bit more flexible and configurable
authentication concept that can more easily evolve over time.
This allows use to call the methods with a string but still store the
name as bytes32.
I also had some issues when calling the methods from ethers.js and a
string parameter so this is easier and safer.
Allows to seed the smart contract with development data specified in
config/seeds.js
Usage:
truffle exec scripts/seeds.js
or
npm run bootstrap which runs them all:
* truffle migrate --reset
* truffle exec scripts/seeds.js
* npm run build-json
This allows to manage different contracts (Token, Collaborator, etc.)
with one registry.
The registry serves as main source for all contracts and versions.
Versions are independently deployed and added to the registry. From
there the proxy contract's implementation can be upgraded to the new
version.
Currently no access control is implemented.
bumi
