All Aragon Devs #19
Call #19: April 1, 2019 9am PST / 12pm EST / 3pm UTC / 5pm CEST
- Appoint note takers
- Introduce team members who haven’t already met each other (~0-10min)
- Aragon One updates from last call and current priorities (~5-10min)
- Aragon Autark updates from last call and current priorities (~5-10min)
- Aragon Mesh updates from the last call and current priorities (~5-10min)
- Security partner updates
- Aragon 0.7 on staging (A1)
- Pando release (Pando). Informations here.
- Organization identity (Autark)
- 3box comments API (Autark?)
- Forwarding UX improvements (A1)
- Q2+ security requirements from teams
- New hire with Aragon Association
- Helping Luis and Stefano.
- Taking on Nest work from Maria.
- Role will be more further defined in future.
- Graduated recently from a uni in London.
- Past: VC work, finance and accounting.
- Finishing up loose ends for 0.7
- Work on court
- Finalizing Payroll - soft launch for 0.7 - will add to the AGP18 Security partners pipeline
- aragonOS and payroll shoud be pinned be the end of the week.
- Finished up work for local identities and identity providers - not the entire spec yet, but there is local address book tagging ['local identity'].
- Will provide details on how to access staging and provide feedback.
- Court (Jorge). Published the mechanism and open sourced the repo. PoC mechanism almost there.getting appeals process finalized and testing strategy. Still thinking about the testing strategy.
- On the way to Rinkeby
- Work on the Address Book. How to articulate Address Book and A1 Identity Provider?
- Work on responsive design. Will come on second deployment.
- Improve testing - in the next two weeks should be in a state to have e2e testing for all apps.
- Bug fixing and improvements in response to the reviews.
- Major work on Allocations app to change how we handle payouts.
- Increased the amount of dynamic informative text across all applications so users have a strong idea of what votes, and forwarded actions do.
- Profiles - going forward with 3Box integration. Finalized plan to move their data structures to adhere to linked data standards.
- Started developing the Profiles solution this week.
- Discussions - Built a proof of concept IPFS backend caching layer.
Updates to aragonCLI in previous two weeks:
aragon ipfs view&
aragon ipfs propagate
- Planned features for CLI extensions
- The react boilerplate now has linting and testing for the contracts set up, thanks to David from P2P models (who's working on the Aragon Wiki app)
- The react boilerplate app was updated (Pierre - Aragon One).
- Internal improvements: docs, sourcemaps, etc.
Next two weeks goals:
- Finish WIP across some of the repos
- New package ipfs-commands for aragon-cli
- Create new guides for Frame and hopefully for the Agent app
(Alex dropped off call)
- The team added “pending-security–review” labels (github) - clearly visualize the state of changes in terms of security review
- Expect there will at least be one comment in the PR that summaraizes efforts/findings
- Will add inline comments to LOC too
- Ongoing review -> focus: https://github.com/aragon/aragon-apps/pulls?q=is%3Apr+is%3Aopen+label%3Apending-security-review
- Understanding the SDL
- working on proposal for next vote (sec partner)
- Idea to add a security-request label on github.
- Work on 0.7
- Work on the draft of proposal for next AGP ballot
Took efforts to better understand software development processes in Aragon. Earlier to get security review in processes, the cheaper it will be in the long run
Initial findings - havent written a report yet - there are certain security and quality gates already implemented and they are going to suggest more security gates so its easier for new members and for other projects to trust the core system
Aragon 0.7 on staging
- A1 maintains a staging environment on rinkeby
- Staging uses a separate ENS instance to the rinkeby release. That means staging DAOs are separate to rinkeby DAOs even though they're on the same network.
- Tries to deploy every 2 weeks to staging with new changes.
- Any time a new feature is merged or on the verge of merge, will deploy a staging build to test it out themselves and make it easier for others in the team to test.
- Not sure about publicizing all builds, but may be a way to get people more involved in testing
- Reach out if interested in testing the changes or if you know someone that wants to help.
- Latest version for local Identities and other changes for 0.7 published last week on staging.
- Released pando on rinkeby last week.
- See forum post for details: https://forum.aragon.org/t/pando-live-on-rinkeby/712/5
- There is a test DAO on rinkeby with onboarding guide on how to use pando.
- Pando cli is published on npm - anyone can use it and test it on rinkeby, can deploy a test DAO and see if everything is working
- Deployment process was almost easy except the IPFS aspect.
- ipfs-propogate command has been a great help
- There is a problem with the aragon dev chain. cannot publish on open.aragonpm.eth on the devchain
- The related issue.
@aragon/api-react Release Announcement
- Stable release
- Pierre over the last few weeks has been working on react api on FE for apps. Using hooks,very modern as far as react exprience goes.
- It should help people it gradually get into the aragon API aspect of things for front end.
- Makes things a lot more explicit
- A1 has started using it internally and will be migrating most of their apps to use this api in the coming "while"
- Widget approach - for a DAO to customize the information they want to include
- Ability to set a token defining membership. Maybe a more generic approach such as an ENS-based approach could make it to.
- Jorge: with ENS there are additional advantages. For example with melonport they have two types of members with different permissions. If you have one native token that will have to be the global
- Ability to create as many info blobs as the organization wants.
- Based on Markdown
- Vote-based process to update / change.
- Need the ability to add manifesto / important text for the DAO. It wont be stored on chain. Ability to create "word blobs" via widgets and markdown-based. Integrating a text editor - and ability to vote to change the data.
- Potentially this is something that could be managed completely by Pando repos.
- How does it stay on IPFS?
- Plans on using pinning service (pinata?)
- Right now using Infura bc they pin automatically but not a great long term solution.
- IPFS Consortium
- IPFS Cluster
- How does it stay on IPFS?
- Jorge: for the court the organization needs written rules, manifesto, etc. so it is important for that. Would love to be involved in the process of how this gets done.
- Potentially this is something that could be managed completely by Pando repos.
- Ability to provide specific informations about DAOs.
- Requirements for specific features ?
- Potential APIs
- Set a default token manager app
- Membership hook / abstraction layer in aragonAPI.
- E.g. as part of the settings "I would like to use this app as my membership provider" - then link to token manager for example
- Implement an app that only "attaches" (not "manages") a token, for its forwarding interface
- Aragon Trigger?
- Forum post soon
Few questions / doubts from John:
- Wondering how they are implementing querying and how that scales
- Need a good way to identify and access
- as far as he knows, not an easy way to do that
- If you're using a backend caching layer each comment has a hash
- Wondering how their implementation under the hood is actually better than a centralized caching layer
- Wondering if they are spreading theirselves thin? 3box supposed to tackle identity/profiles
- They may be taking on too much by doing commenting as well
Forwarding UX Improvements
Allow apps to be aware that an action is pending in a forwarder (e.g. into the voting app).
Other applications can display that something may potentially happen as a result of voting. eg. you are in finance app and create a new transfer. That creates a new vote, but finance app doesn't have knowledge of that action within the app.
- Decoding will be the most interesting part of how this gets built
- Information needed to decode the script is probably more accesible in the receiving app vs target app
- Decoding in two layers:
- Decode to determine type of EVMScript, and superficial details (e.g. target address)
- Decode actual target calls via apps' ABIs
- Decoding is easier if you have only one "interactive" forwarder at the end of the path, but gets more complicated if there are more than one (e.g. voting -> voting, voting -> futarchy)
- UI standarization
- How much of the information would actually be acted upon int he UIs?
- Will the application determine which functions are relevant? For example maybe have a badge that displays if an action is protected by an auth guard
- Perhaps the auth information could be shown in the signing panel
- Auth information is likely important for other users, not just the creator, so useful in interactive forwarders' UIs too
- E.g. Voting app: it should be more clear that you will be interacting with a contract or not
- Could render components from other applications to show more specific information
- However, this would likely require another iframe to sandbox correctly (which is not nice)
If you have any supporting links for high level doc, will be helpful for security partners so they can estimate their budget better for the AGP.
- Completely new code - Full audit vs incremental
- Network components - court is fairly large contract with many edge cases
- Staking component - meant to be simple and self contained
- Bonding curve component - similar to staking. Holds value - lot of care needed.
- When people want to become jurors this is done with a bonding curve.
- Incremental change - perhaps a new app for the Aragon client - associated to this app will be a few changes to the Voting app. Controller for the Voting app - pause this vote, cancel this vote. Has specific functionality to enable court features. More details in the blog/forum post.
- As far as contracts for existing applications - hopefully they wont change hence no audits needed. If they do change it's because something went wrong.
- Applications that will need full audits at some point:
- Range Voting
- Address Book
- The urgency of these audits is not a major pressure currently, ideally we'd like to have these applications published to Mainnet before the end of the year
- Possible to do audit of each app seperately or in phases to distribute the effort
The overall Apiary app is made of four contracts: * the tap which is pretty simple. * the pool which inherits the Agent app while adding the ability to add a list of guarded token and a safeExecute function checking that the target contract is not a guarded token + that the balance of each guarded token is kept constant before and after the transaction * the bonding curve contract which is the tricky one. * a wrapping Apiary contract behaving as an api contract on top of the three previous contracts to circumvent sandboxing limitations.
The tricky part is gonna be the bonding curve contract. The pool contract tricky part is limited to the safeExecute function. The other ones are pretty straightforward and fast to audit I guess.
The bonding curve is basically a BancorFormula contract (ideally we would need to review it too, though I guess Bancor contracts are already heavily reviewed) with batched orders to mitigate front running (plus AragonOS features like ACL and all of course). The network bonding curve may rely on this implementation so I may make sense to heavily review it :)
If we pass the next AGP ballot and Aragon Black becomes an official Aragon Team - and thus pando an official aragon app - it may makes sense to review the contracts too. Those are pretty simple and straightforward, though so it should not be that much work - an internal review may even be enough.
A1: Jorge, Brett, Daniel, Maria, Pierre, Bingen
Aragon Mesh: Daniel, Gabi
Autark: Yalda, Aurthur, Kevin
Open Work Labs: John Schwartz
Consensys Diligence: tintin
AA team: Louis
Community: Olivier (Aragon Black)