DAORegistry scheme specification

[corydickson]

Currently, we have this implementation: https://github.com/daostack/arc-hive/blob/master/contracts/DAORegistry.sol

With the defined interface:

propose(address _avatar) public;
register(address _avatar, string memory _name) public onlyOwner;
unregister(address _avatar) public onlyOwner;
isRegistered(string memory _name) public view returns(bool);

The DAO avatar will own this contract, and so the question becomes do we use the generic actions scheme to interact with this contract, or do we create a new scheme to handle these registries.

For example, we can define the RegistryScheme:

proposeRegisterDAO(Avatar _avatar, string memory _registryName, string memory _proposedName, Avatar _proposedAvatar);
proposeUnregisterDAO(Avatar _avatar, string memory _registryName, string memory _proposedName, Avatar _proposedAvatar);
executeProposal(bytes32 _proposalId, int256 _param) external onlyVotingMachine(_proposalId) returns(bool);

naive implementation here: https://github.com/dOrgTech/DAOfeatures/blob/master/features/registrars/contracts/DAORegistryScheme.sol

This will use the proposal pattern with the DAO avatar address and the _registryName as the mapping keys to the registry that it owns and is allowed to update.

When a proposal passes, executeProposal depending on the scheme parameters 1/2 (add/delete) it will call either proposeRegisterDAO/proposeUnregisterDAO.

We could generalize this further by instead of having the proposal functions use _proposedAvatar, it could be a struct with many other fields that are accessed depending on enumerated uint types that are mapped to strings registryName.

Depending on the types it would update different registries in which the structure is well defined beforehand, and this would facilitate better upgradeability

[orenyodfat]

Well ,as i see it , proposeRegisterDAO and proposeUnregisterDAO should save encodedABI(Register or UnRegister) on the proposal storage .
The encodedABI can be created on the fly by the contract itself or can be passed to it as a byte32 param( in this case we need to have some sort of support for that on the UI layer).

• when a proposal passes, executeProposal will do a genericCall (via the controller interface) with the encodedABI param of the proposal. regardless if it is register or unRegister decision.

• supporting multiple registries can be achieved by setting a different _contract in the genericCall

• see GenericScheme . it might be used as is or maybe it can be inherit and add some specific needed staff like proposeRegisterDAO and proposeUnregisterDAO .