search

cambiatus / backend

Cambiatus GraphQL API
GNU Affero General Public License v3.0
21 stars 18 forks source link

Provide multisig entities #190

Open lucca65 opened 3 years ago

lucca65 commented 3 years ago

Story

I, as the community admin want use EOSIO multisig features in the app To have an improved governance

Telas

No screens yet

Casos de uso

Given a admin role user When opening the community they are an admin of Then it will show all the communities proposals

Given a new role on the blockchain when event-source gets the block Then it saves the new role config in the community

Given a new proposal form when an user with the admin role tries to create a new proposal then it can assign a role to it, and the frontend will have access to the full list of people belonging to that role

Given a new proposal from the admin account When someone from the admin role access the app Then the user with the admin role will be able to vote it

Description of the problem

We currently don't support multisig which is an important part of governance within a community. While frontend implements it the backend could help with additional data to make the process go a lot smoother

henriquecbuss commented 3 years ago

@lucca65 just thought I would write down the pain points I've been experiencing on the fronted and some important information I've found:

  1. We need a way to know who can propose or vote on proposals (the roles thing you were talking about). It's important we still know the account who created the community though, so we can configure it and use it as a multisig account
  2. Eos proposals don't have a description. The only field we could use is their name, which must be <= 12 characters long, and must be unique per user (one user can't have two proposals with the same name). Having markdown descriptions would be :ok_hand:
  3. Proposals are scoped per account name, so we would need to make one request per user who can vote on the community. Also, because it's scoped by user, we don't know what community the proposal is related to.
  4. To get the full data from a proposal, we need to join two tables (both from the eosio.msig account, both scoped by the user who proposed the proposal): 4.1. The proposal table gives us the proposal name and the proposed transactions (they're serialized as a string, but we can deserialize them on the frontend) 4.2. The approvals2 table gives us the users/permissions who have voted and who have not voted yet.
  5. I think it's worth mentioning again that multisig doesn't allow users to vote "No". Users can only vote "Yes" or remove their "Yes" vote.

I'm doing some more work to make the frontend draft PR more customizable, that way you can test it out better, I'll let you know when it's good enough to try it! And if you need any help with this multisig thing, hit me up! I've read quite a bit about it over the last week :smile: