This quarter we have been hard at work developing the new v0.5 release. This release paves the way for Aragon to be an extendable governance tool which supports all possible use cases. It has required an immense amount of changes, including a re-architecturing called aragonOS.
Why the v0.5 release? With the new architecture, v0.4 was basically skipped, since the benefits of this allowed us to put our focus straight into the next version. You can find our newly updated Development Plan here.
The main highlights for our development work this quarter has been:
As a result of the new architecture which we unveiled last week, aragonOS, many changes have been made to the aragonOS contracts. If you want to read more about these changes, check out last week's post:
The Kernel and the default apps we built for v0.5 are now feature complete, the codebase is at 88% code coverage right now and we have written documentation for all components which can be found in our wiki.
We will be locking the codebase soon and start the first round of audits to make sure the contracts are secure to be deployed and manage real funds.
node-aragon is the library we made for interacting with the Decentralized Autonomous Organizations, their kernels and applications. It will be used by our team to implement the front-end for the default core apps, but it will also be used by 3rd party developers to create their own modules.
We've recently pushed the initial version of node-aragon along with a technical document outlining how it works. This initial version includes all of the core functionality that node-aragon will have, though there are some major improvements that are still being worked on for the v0.5 release.
At its core, node-aragon is two components: the wrapper and the client. The wrapper is responsible for all of the magic (like permission escalation), as well as for interacting with web3.js to get and transition states. The client is an RPC client that communicates with the wrapper. This allows us to sandbox modules in order to ensure the safety of our users.
node-aragon is still in development, and we'd appreciate feedback from developers who might be interested in creating modules for Aragon.
Going forward we will implement the currently missing features, collect feedback, improve the documentation and elevate the developer experience while making modules for Aragon.
For managing the different versions of the Aragon Core apps as well as third party modules, we built a very simple on-chain package manager. The main advantage of having this component on-chain, is the ability to set any Ethereum address (which can be a multisig, a DAO or a vanilla private key) as the owner of a given package. This ensures maximum security for performing upgrades to critical packages.
In order to install or upgrade a module on an Aragon organization, two different components are needed:
aragonpm keeps track of a package's different versions for the pair of smart contract address and a content URI.
For discoverability purposes, we made aragonpm use the Ethereum Name Service for locating packages. We will run an instance of it at aragonpm.eth, which will allow for registering package names in the form of liquid-democracy.aragonpm.eth.
The DApp is currently going through a complete refactoring from using Meteor to Vue.
We have been working on a full redesign for this release, here's a sneak peek at how it will look:
Aragon v0.5 design mockup
This design is built around aragonOS, making sure that applications are first-class citizens and that third party developers can easily create apps that fit beautifully into the user experience.
We have also introduced the signer view that will inform the user about the action about to be performed. In case the user doesn't have proper permissions to execute the action, they will be presented with multiple options for other apps to handle the request and eventually execute it.
With the new aragonOS architecture, reusability of app logic is very important, as apps should do just one thing. For example, in version 0.3 of the DApp, Ownership app had to keep track of all the tokens in the organization. In 0.5 the Tokens app, its replacement, only has to take care of a single token. Since you can initiate any amount of instances per app, you get the same functionality while reusing most of the applications logic. This results in better user experience and enhanced security.
During this quarter we worked on multiple community tools that improve the project's transparency and empower the community. The first of them is the Transparency Framework which is a public view of our Multisig that also shows human readable descriptions of the transactions that we make. This allows community members and ANT holders to see that our use of funds is productive and responsible.
We also started the Aragon Governance Proposals, in which the community can propose governance systems and discuss the specific proposals that require community debate. An example of this was AGP5, in which the Aragon community and other projects in the space coordinated the migration off Slack.
We have also been working on taking AGPs a step further and allowing ANT holders to signal their support on different proposals. This will be our first experiment at network governance and we are very excited too see how it turns out.
While still being developed, we are looking to do the first signaling governance proposal soon.
Screenshot of the signaling DApp
Part of the team during offsite outing to Malaga's Fair
During this quarter the entire team met in Marbella, Spain to do our first team offsite in which most team members met for the first time and we spent a whole week working together and plotting out the future of Aragon.
The week was extremely productive and triggered some of the improvements that were outlined in this post.
During Q4 we are making special effort on expanding the team. We are currently hiring for multiple technical and non-technical positions, you can check all the listings in our wiki jobs page.