Because accountability is key on funding new teams to work on decentralized ecosystems
As we have said previously, making Decentralized Autonomous Organizations widespread is an extremely ambitious mission that cannot be accomplished by any single team in the world. We have started to decentralize the development of the project. We onboarded a second team, the AragonDAC to work on fundamental Aragon infrastructure.
We see Nest as another way to decentralize the development of the project and as the first step for the Nest teams to have a more active role within the Aragon community. It can be totally possible that in the future, one of these teams will be working on the core work of the Aragon project as an independent team.
One of the future plans for Nest is to start involving the community further so that it can participate in the decision making process regarding Nest's yearly budget and its governance. You can read about these plans here.
With those plans in mind we want to share with the community the progress of the first batch of the teams funded. The challenges they have faced, and the milestones they have accomplished. We plan to have the teams do these public updates every quarter. One of the key differentiators of the Nest program has always been transparency.
Whenever we starting working on the Planning app (see original Nest white paper), we assumed that we would be able to build a single Aragon app using multiple interconnected contracts, which would be able to spawn additional contracts within it. Smart contract development occurred independently without fully taking in the intricacies of the aragon.js architecture, and we didn't become aware of this technical limitation until very late into our first Milestone.
To accommodate for this challenge, instead of making a single app with a very large smart contract, we had to make design sacrifices and develop a new architecture composed of six total apps (Allocations, Range Voting, Projects, Rewards, Consensus, and Address Book) which we are now calling That Planning Suite.
The suite includes:
The six apps described will be what we develop through the entirety of the Nest grant. The first Milestone consists of three of these apps.
1. Allocations & Range Votings Apps
a) Completed front-end, smart contracts, and kit to deploy these two apps
b) Integration between smart contracts/front-end is a work in progress
2. Projects App
a) Front-end and Github integration is 90% done
b) Smart contract work punted into next milestone
We plan on tying up loose ends for Milestone 1, and then complete Milestones 2 & 3, whose timelines have been readjusted to accomodate for the new technical approach. These two Milestones include the following:
Refer to our Q3 2018 Team Update wiki for a more comprehensive update, including roadmap and other updates.
During the first milestone we have been mainly focused on delivering an IPFS / web3 native VCS. The main challenges to do so were:
The following packages are available on npm:
1. `@pando/core`. Pando core smart-contracts and aragonOS apps.
3. `@pando/cli`. Pando CLI to use on the desktop.
Feel free to play with it but keep in mind that these packages are in a very alpha development stage and are not meant to be used in production yet.
All of these packages are maintained through the following monorepo : https://github.com/ryhope/pando. Feel free to fork, open issues and submit pull requests.
We have several ongoing works for the next milestone.
We intend to leverage what we've learned during the first milestone to provide a more robust and modular architecture for the pando.jslibrary. We have already been through a lot of refactoring lately and should reach an almost stable interface in the next couple of weeks. Once this interface is stabilized we will also update pando’s white paper and provide a minimal documentation for developers who would like to join in and help us with the development of pando.
The actual implementations of pando’s library and CLI are fully functional but kind of slow. In their current state, they make the use of pando to maintain big projects difficult. During the next milestone we intend to focus on optimizing pando’s performance and have already identified several bottlenecks:
The web3 library has been designed upon the hypothesis that everyone would run its own Ethereum node to sign their transactions. Obviously, this is not the case. Some external softwares such a Metamask have solved this issue when it comes to running a DApp in the browser. But until now, there existed no equivalent to Metamask especially designed to sign transactions at the OS level.
This was a major issue for us as it required pando to locally handle private key and transactions signing. Happily, the Aragon Nest program is also funding an amazing project which aims at solving that exact problem - and in a gorgeous way: Frame. Right now, Frame « only » handle hardware wallets. During the next milestone, we intend to work closer with @floating, Frame’s main dev, to add support for other kinds of wallets - mostly encrypted keys. This will enable pando to delegate key management and transactions signing to Frame, while contributing to make Frame a de facto standard for OS-level key management.
As anyone building DApps on top of IPFS we are waiting for the release of Filecoin to enforce data replication in a distributed and efficient way. In the meanwhile we will rely on IPFS Consortium to do so. We are already in touch with the amazing team behind DappNode, a tool which provides everything one needs to actually decentralize the distributed web, to integrate pando more tightly with IPFS Consortium and eventually turn it into a one-click installable package on DappNode.
The most exciting feature we are going to work on during the coming milestone is the implementation of more governance kits for pando repositories. Right now pando’s access control mimics git’s one: one can own push rights or not over a given repository. While this may be useful for projects which need to move pretty fast, this governance scheme is still quite centralized: it relies on the existence and the good will of a few « maintainers ». The current governance kit we are working on will be much more decentralized - and fair, from our point of view. Every contributor will earn authorship / authority tokens on the repository thanks to their actual contributions. This authorship / authority tokens will grant contributors the ability to decide on which contribution to merge, which authorship / authority to grant to its author, etc. Eventually, these authorship / authority tokens will allow for a DAO-wide governance scheme based on the actual contributions of its shareholders.
I’m happy to announce Frame had its first official release, the developer prerelease. This is a testnet only release of Frame and is an opportunity for developers to test Frame with their dapps before it moves to the mainnet. After working for months to get to this point I'm excited to start gathering feedback from the community to help shape the future of Frame.
Providing users (especially non-technical users) with a secure and reliable dapp experience is important for adoption. Hardware signers provide a great foundation for this and Frame makes it easy to use them with any dapp. With the help of hardware makers, we will keep improving these integrations and continue innovating on what's possible.
To get started using Frame visit https://frame.sh
If you'd like to use Frame with existing web dapps you can do so by using the Frame browser extension. You can also connect to Frame without the need for a browser extension by pointing a provider to ws://127.0.0.1:1248 or by using eth-provider as a drop-in replacement. Visit github.com/floating/frame for more info.
This quarter has been a really exciting time for our team as our first full quarter of work. We started out in Q1 and we've reached an incredible velocity by the end of Q2. Some of our favorite achievements from Q2:
However, advancing the ultra-bleeding edge of technology has some painful moments. As new ideas come to light, the specification of an Ethereum sharded universe changes. During periods of high uncertainty in research specs, we found that it was hard to split up work. We also need better ways to encourage recurring contributors, as many of them did not have enough context to contribute to sharding extensively.
Sometimes these spec changes have drastic impact on our progress. In other words, we've had to be nimble and pivot our project. This often means discarding non-trivial work that has already been completed. While this sounds frustrating, we welcomed these changes to make a better Ethereum 2.0
Now, we're working hard to build towards our first major milestone where we aim to run a small sharded system, with the latest research, on a local network. Our focus is on implementation of the Random Beacon Chain with Casper FFG as well as the sharding validator roles.
Browse Nest Proposals at https://github.com/aragon/nest/issues
See Nest Requests for Funding at https://github.com/aragon/nest/pulls