aragon / govern Goto Github PK

We should test the subgraph ability to perform state changes with events that involve actions, like Scheduled, Challenged, or Executed.

See this note.

High level diagram explaining how the different Govern pieces relate to each other.

• increases consistency of all tests

TheGraph seems to be having issues, and we should regardless start indexing Govern subgraphs in our infra

Add the following features to the Govern API server:

• Authentication.
• GraphQL subscriptions.
• Create DAOs.

CD should deploy to mainnet when a release is tagged on master.

A demo DAO should also be deployed with the name 'cd-[version]'

Initial version of the Govern API server, including:

• Backend fetching data from The Graph: #59
• Frontend (GraphQL API, queries only): #60
• Single command launch (using Docker): #55

Works locally but on CD: https://rinkeby.etherscan.io/tx/0xe7f625ba36f45c84ad47243294bf0660e8b52cf5a0b60e52616334d55fb38b9d

After #27 I believe we can just get rid of the script

See this note; this is already included in the config.

We should have a minimal UI to do the following:

• Inspect the DAO & see relevant information
• See current and past actions
• Interact with actions (challenge, dispute, execute)

We can leverage the existing aragon/console repo for this.

PR: #111

Implement an IArbitrator that allows an address to resolve all disputes created by a particular address.

This will allow testing the new system in pre-prod/testnet in isolation, mocking protocol behavior

It'd be great to add a contract linting tool to the contract packages. Although not always useful, they can catch some issues or help align code.

Instead of solium, as our old codebases used, I would suggest adding solhint and using its prettier extension.

We should add the main data structures / contract types of Govern to ERC3K.js, so we can easily both receive and send actions, containers, collaterals, and so on.

Might be able to close #1

Abstract

API server to host at api.aragon.org or api.[govern app domain]. The Aragon Connect equivalent for Govern should hit the api instead of a subgraph directly

Why

• DX is incredibly important for our product's success. Aragon Connect changed Aragon forever.
• Aragon Connect is great, but having a more web2-like API is going to make it easier for non-crypto devs
• API will allow us to monitor real use of our tools to detect usage patterns

Deliverables

MVP deliverables by priority:

• Passthrough proxy to subgraph. Perform GraphQL queries directly to our host allowing us to hot swap the Graph node being used.
• Basic JSON views (/daos, /daos/[dao]/queue, etc)
• Basic API docs using something like https://swagger.io/resources/open-api/

Future features:

• Create DAOs, schedule, challenge and execute actions via API (API pays for gas)
• Register webhooks (eg. on DAO schedule send POST to dao.org/webhook)

Acceptance criteria

• Once first feature is done, we can deploy and continue evolving
• API is deployed on master pushes from CD on Github Actions
• API is monitored for errors
• API should be relatively easy to deploy for people to host mirrors (stop tradeoffs between great DX and decentralization)

Involved persons

• Owner: @bpierre
• Design: @bpierre + @izqui
• Implementation: @bpierre + @promaty
• Review: @promaty + @0xGabi
• QA: @Evalir + @izqui
• Documentation: @bpierre
• Ops: @promaty

Inspiration

• https://0x.org/docs/api (crypto api)
• https://developer.github.com/v3/ (rest + graphql)
• https://reactjs.org/docs/getting-started.html (great docs)

Phases

• Phase 1
• Phase 2
• Phase 3
• Phase 4

Buidler has been deprecated in favor of Hardhat. While there's not much urgency, we should try to stay on new tooling to avoid any migration pains later on.

• JS library (browser + node) fetching data from a Govern Server, through its GraphQL API.
• Reflects the Govern Server JS API.
• Inspired by the Connect API.
• Actions resulting in transactions can go through a local Ethereum provider or the Govern Server.

Should we use @aragon/govern.js as a package name? @izqui

Implementation: #77

See this note.

As per this note, we should reorder the payload properties being hashed to match how they've been defined in ERC3000Data.sol, for the sake of consistency.

Add the following features to the Govern API server:

• Register Web Hooks.
• Schedule, challenge and execute actions via API (API pays for gas).

Pls expand on what you are thinking to do @0xGabi @bpierre

Add the following features to the Govern API server:

• New frontend: REST API (might be a light, read-only version).
• Complete logs.
• Excellent self deploying story.

Document the current state of the GraphQL API.

We could start with a single markdown file for now, then move to another system later if it makes sense.

We just got https://daoscan.org and https://daoscan.app for it.

Let's brainstorm!

Tried to do it in #2, but codecov.io requires buying a plan for private repos.

Holding until this repo is public, which should be soon.