Skip to content

All Aragon Devs #23 (Agenda)

Call #23: May 27, 2019 8am PST / 11am EST / 3pm UTC / 5pm CEST


  • Appoint note takers
  • Introduce team members who haven’t already met each other (~0-5min)
  • Updates from the last call and current priorities
    • Aragon One (~5min)
    • Autark (~5min)
    • Open Work Labs (~2min)
    • Aragon Mesh (~5min)
    • Aragon Black (~5min)
    • Association (~2min)
  • Topics
    • John Light on dev tools comms channel
    • Potential caching solutions (A1 / AB): moved to next call
      • The Graph
      • Centralized cache server
    • Forwarding API
    • IPFS follow-up: moved to next call
    • Markdown editor in aragonUI




Aragon One

  • Application caching on subsequent loads
  • aragon/api package (v1 won't change), but v2 betas will be out soon
  • Migration document to be written and released later
    • Will be ready for the Aragon 0.8 release, along with the new design guidelines
  • If you're using an organization on rinkeby or mainnet (with the caching) right now, much faster load times
  • Court: good progress - PRs have been getting merged, now working on edge cases and more tests. Go to GitHub for more information
    • All the moving pieces are put together, tests are passing, now working on minor issues
  • aragonOS:
    • Kill switch
      • Supporting many alternatives to know what the best option is
      • Simple first implementation
      • Close to finishing it up (still need to discuss edge cases)
    • Progress made on meta-txs for aragon apps. Allowing a DAO to pay for their members' txs.
      • Avoids too many changes to existing Aragon Apps as the signer is appended to the calldata, but the gas fees might become a little steeper. Is there another better way? Two PRs up on this topic on aragon/os
    • These two features will prob be landing in aragonOS 5. Once changes merge, focus will be on new version of aragonOS rather than adding features to version 4


  • 2 weeks revving up work on profiles. Ready for initial testing
  • Initial home app (not feature complete)
    • All of the frontend work is complete. Most of the contract & integration work is handled (should be completed before next all devs)
  • Initial implementaion of forwarder API spec
    • Just need to test with the application. Modifications may be needed to merge it with the new caching solution.
  • Next AGP proposal coming soon! Stay tuned.
  • Need to wait for some new aragonOS changes to build "default app" functionality into the home app.
  • Basic IPFS pinning to start next week

Open Work Labs

  • Profile work soon to be built into aragon/aragon repo. How often should we check in with aragon/aragon team?
  • IPFS pinning cluster with leader/follower nodes to get started on this or next week

Aragon Mesh

  • Previous two weeks: released new aragon/cli. Mostly for stability. Updated dependencies, created end-to-end tests for aragon-run
  • Created a DAO on rinkeby with projects app deployed.
    • Three bounties have already been paid out from that DAO! wooooo
    • More information, its on rinkeby, but gabi and daniel have installed TPS projects app, bridging mainnet payments by asking people for their address and paying it out manually through mesh team finance app.
  • Helped on Aragon hack documentation.
  • Current priorities
    • Iterate on the IPFS command for stability
    • Better feedback whne fetching a file and better error messages
  • Create a DAO to experiment with AGP 28 and aragon package manager governance.

Aragon Black

  • Pando: refactored background scripts to fetch the IPLD data to comply with their new spec
    • Finished tests with that as well
  • Implemented frontend markdown editing - shoutout @OTTO for coordinating some of that work. Lingering question, since we're using similar deps to actually do the markdown editing, should we get this into aragon/ui?
  • Apiary (aka aragon fundraising app): frontend is basically done, responsive, filtering of orders and chart history, just needs minor refactoring to make the code clean
    • Might need final feedback on the design but the current design is good enough for this iteration
  • Market maker contract is now ready, there's only 1 thing left (to do with fees on sell orders)
  • Up and coming audit scheduled from june 10 to july 1
  • Getting the kit working and also looking into how they can get onboarding screens for the kit. After that, working on web3 integration - making the frontend work with the smart contracts.

Aragon Association

  • Short update:
    • Planning the audit for Apiary
    • Treasury is up from 22m to 60m which is awesome
    • Nest has been approving for second nest grant - there are some new proposals, go take a look and give feedback
    • #161 and #162


  • Dev tools comms channel (John Light)

    • Conclusion from last call: use twitter + for dev tool release announcements. People who would like to follow up on the updates can use the watch releases functionality on github.
    • Seems reasonable - topic has come up several times - historically for external communication is to tweet from maintainer (individual tweet or thread). Aragon project will retweet that from aragon account.
      • This gets more visilibity into this release
      • People look on twitter there for aragon related news
    • Another thing is rocket chat - the maintainer might do an @all channel message in the appropriate channel to announce the release
    • How have release communications been working for maintainers so far? Is it adequate? Do you need/want more visibility?
      • If we do want more visibility, what new channels can we use to promote new releases
      • aragon/ui, aragon/cli, aragonpm - do they need to expand to the ethereum ecosystem, do they need more open source contributors?
      • Maintainers / release strategy right now is done on a per repo basis - no standard.
    • aragon/cli is the highest priority for communications because it's one of the first touch points
      • Perhaps we could have smaller stability releases and then larger feature releases. Make more noise when the functionality releases land (new commands, new features...etc).
      • Can be done doing a Twitter thread. Coordinate with John on release day for some communication to be put out.
      • John is open to coordinate with any maintainer to communicate more about dev updates
      • Gabi was implementing a system for bounties on the cli and they tested the first bounties they are calling for collaboration on that, also for the bounty standard definition details.
      • Gitcoin is a pain to manage due to bounties being locked to one account
      • Gitcoin started charging 10% - instead go with TPS!
      • Brett suggests making a micro-site to promote these bounties related things.
  • Collaborating on Aragon client (Jon / A1)

    • Even a large PR should make sense
    • The concern is being synced to master branch
    • Yalda and Jon point to profiles integration design compatible with the next top-navigation bar release
    • Sync with @luis on feature spec, start migrating work to aragon/aragon but hidden behind a feature flag
  • Forwarding API
    • Testing this week, should be ready for aragon/api non-beta version. Autark could submit the PR today...
    • Haven't tested setting it up in an actual application yet - that is the next step
    • Basic pattern → new forwarded action in the api, and an observable for updated forwarded actions in the api
      • Concerns: storing state, which wasn't in the initial spec. Persisting executed actions so that the information is still accessible.
      • Ready to make changes if it doesn't work or adhere to spec correctly
      • Event caching changes might change this forwarder API?
    • Conclusion - see the PR sooner
      • Helpful to see what's going on and make decisions
      • Idea now: keep going on towards betas until 0.8 release and know for sure that we don't need another breaking change in the future (or at least for this iteration round for the API)
    • Next steps: submit a PR.
    • Questions:
      • UI Design patterns: needs another look. What should it look like? Can we establish a good visual pattern across applications?
        • Might not be consistent across all apps? - yalda
        • One use case: allocation. Right now allocations app, there is already a table on the bottom of different allocation proposals - what's missing - "pending a vote". Coming up with terminology and diff icons for what things means, states...etc
        • Issue curation / funding: those are use cases that are a little different. There's nowhere in the projects app that displays these proposals. Another design that's being worked on now.
        • Initial designs finished by tomorrow
      • Activity panel - quite confusing with forwarded actions. Activity panel doesn't tell you very much about what's actually happening.
  • Deep links within aragon apps
    • If you can click on an a pending action and it takes you to the forwarded location on the other app where that action is pending
      • Main problem is how to figure out app routing, and how to send these params down between apps
    • aragon/api has a context api that hasn't been used (ever), but it was meant to do this type of thing. Mostly its the aragon client not wiring together navigation between URL params and the app context
      • There's some potential to use context API for something like this, or to completely start a new navigation API
      • Next steps: sync between Otto, Kevin, Pierre on how this API could look like
  • Markdown editor in aragonUI


Aragon Black: Cory and Deam

Aragon Mesh: Gabi, Daniel

Aragon One: Brett

Autark: Arthur, Yalda, Otto, Kevin

Open Work Labs: Jonathan Schwartz

Aragon Association: Louis



This template is modified from the Ethereum All Core Devs call notes template and inherits the same CC-BY-SA 3.0 License.