Progress of development from the last quarter of 2017
In the last quarter of 2017 we were heads down developing everything for the version 0.5 release of the Aragon Core app. Lots of progress was made, first audit of the smart contracts was conducted with good results and we're on track to get the testnet release out really soon™.
It has been an incredible quarter of building, in which we have laid down the foundation for everything that is to come in 2018. Brett and Pierre joined the development team, who together with Olivier are an amazing founding technical team.
Without further babbling, here's a list of some of the bigger changes that took place in Q4:
New projects we started in Q4 2017:
As we've been doing this major overhaul of the project that started with the re-design of the front-end and was further expanded with the creation of aragonOS, new tools were also needed.
The new approach makes Aragon modular and granular so that users have a choice of how to run their organizations, but also with the ability to create any functionality they feel is missing. We've started creating the tools necessary to build any apps on top of Aragon and these are the latest ones to help support the constructing of the Aragon ecosystem.
The audit motivated some changes in the codebase, but no critical problems were found.
Further audits and public bug bounty programs are scheduled to begin in January 2018. If you're interested in taking part and contributing on these bug bounties or any other bounties in our GitHub repositories, look for the bounty labels in the differentrepositoryissues!
Starting with the next version, v0.5 — The Refactor Release, Aragon will feature an entirelyrevampedinterface. The decision to redesign the DApp was simple. There was a need to align the app and it's updated graphical identity, design principles and use cases to the origin of the project.
Simplified permission instance parent to permission owner in the ACL
In the current iteration of the Kernel ACL, every permission instance has its own 'parent'. A more detailed explanation can be found in the ACL section of the aragonOS doc. In this model the parent of a permission instance means two different things:
Parent can always revoke a permission instance.
If an entity has a permission and it is also its own parent, it can regrant the permission.
The problem with this permission model is that in case a permission has been granted to an entity that cannot do arbitrary calls (i.e. Finance or Fundraising)
Proposed new model
Introduce a permission owner at the permission level and remove the permission parent from the permission instance level. The owner is able to grant or revoke an arbitrary number of permission instances of that permission.
The idea behind having a Factory deploying organizations is only needing 1 on-chain transaction to completely set up a default organization with sane permission defaults.
It performs a deploy of a KernelProxy, one MiniMeToken and one instance of every default aragonOS apps.
The default permissions give too much power to the Group called 'Founders Group' in which the creator of the organization is added. For very destructive actions (such as upgrading the Kernel), a voting is required. The voting app uses the created token as its governance token, the creator of the organization is given 1 token so the voting app is usable.
When launch approaches we should create multiple types of factories (kind of like organization templates).
After calling votingApp.changeMinAcceptQuorumPct(uint256 _minAcceptQuorumPct), a vote that was thought of not being approved because minimum quorum wasn't met, could become executable because of the quorum change.
The reverse case can also happen, in which a vote looks like it will be approved but changing the acceptance quorum makes it unsuccessful.
The proposed change is for every vote to keep track of what the minAcceptQuorumPct value was at creation time.
Instead of returning a hash of the evm call script, return the entire script.
Remove useless vote.open boolean from storage.
Improve calculations for support and min quorum for small quorums
Added ability to execute initialization payload on AppProxy deployment
Adds the ability to provide a payload to be executed when an AppProxy is deployed. This allows to perform an atomic deployment and initialization of any app without the need to have a specific factory.
It shouldn't introduce any security vulnerabilities as the proxy will forward any call in the same way after it being deployed.
Aragon UI is the interface toolkit used by Aragon and its related projects.
The big change on aragon-ui was the move from Vue to React. Otherwise progress on this front-end toolkit has been steady and moving ahead very nicely.
Move to React
Note: this PR also includes the color system.
The objective I have in mind is to release a documentation website (looking like an Aragon website), also providing the design specifications.
Eventually, I'd like to provide to Aragon developers a unified website, containing everything needed to build on the platform: node-aragon API, Aragon UI components API, but also guides and guidelines.
Storybook provides a super nice environment to develop components (it's my go-to solution), but I don't think it would be flexible enough for our case (or it would mean disabling its main features like the bottom panel).
To summarize: more control, trivial to implement (menu + routing + stories), dogfooding, and eventually a better experience.
Loader is the only component missing, I think it's too specific for now. I'd like to see how we manage loading states in the Aragon client before adding a generic Loader component.
Using the transpiled library solves all this problems, except one. Most modern build systems have some mechanism to import non-JS dependencies, which allows, in the context of a components library, to have the assets of a component in the same directory (instead of using a global folder).
When the modules are transpiled, the link between the importing module and the assets is lost in the process, and all the links to the assets are broken.
The solution implemented by this commit is the following:
The library is transpiled to universal JS, with and without ES6 modules (for tree shaking, if the parent project build system supports it).
The parent project imports the transpiled version of Aragon UI, and also copy the Aragon UI assets into a directory where they can be served by a web server.
The parent project wraps the Aragon UI app into AragonApp, which allows to set the public URL of the toolkit assets: <AragonApp publicUrl=/>
That way, each Aragon UI component using an asset is aware of the URL where they can be fetched from.
Showing display names of styled components in builds
Enables display names for users of this component library.
Increases the build size by ~2--3kb, which I think is OK for now given the quality of life upgrade. In the future, we can have a production build where this is turned off, or perhaps even better, change the plugin so that all the display names are under a NODE_ENV flag.
I've added the README as src/Form/Input.md, since I can see src/Formcontaining multiple components in the future (all the other input types, etc). In general, it might be interesting to have folders under src/ be groups holding actual components, with each component's documentation living as <component name>.md.
Adds support for scaffolding in the init command (for example aragon-dev-cli init [app ENS name] [template name, github repository name])
The command will clone a GitHub repository into a folder. It defaults to cloning aragon/aragon-react-boilerplate. The contents will be cloned to the base name of the application's ENS name, e.g. for foo.aragonpm.eth it would be cloned to a folder called foo.
Given we have multiple official boilerplates, we can alias them (for example, instead of typing aragon/aragon-react-boilerplate, simply typing react is good enough).
We somehow need to update the name key of the manifest.json file in templates, but they might be in different locations