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.

Learn more about the Aragon Nest program

Updates from Nest teams

That Planning Tab Suite | Open source incentivization app

Challenges & how we have overcome them

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:

• Allocations: Propose new multi-party financial allocations, which are forwarded to the Range Voting app.
• Range Voting: Vote on the percentage of an allocation that distinct tasks, projects, or people should receive. Unique forwarding pattern allows for data to be added to EVM scripts within Aragon.
• Address Book: Maintain a list of Ethereum addresses (external contacts/collaborators) mapped to human-readable names.
• Consensus: Special voting tool to facilitate full consensus on the financial value of bounty, project, or salary.
• Rewards: Distribute rewards/dividends based on the number of tokens one has earned.
• Projects: Curate issues and allocate bulk-bounties via a vote. Integration with Github & StandardBounties.

Milestones achieved to date

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

See Video demos: Allocations Demo Video, Range Voting Demo Video, Projects Demo Video

Plans for next quarter

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:

• Projects App (Smart contracts integration + finish remaining work)
• Address Book App
• Allocations App v2 (Enhanced to include Dynamic Payout allocation type)
• Rewards App
• Consensus App (Front-end)
• Enhanced kit to deploy five apps (Projects, Range Voting, Allocations, Rewards, Address Book)

Refer to our Q3 2018 Team Update wiki for a more comprehensive update, including roadmap and other updates.

Pando | Open source incentivization app

First milestone summary.

Where we are now

During the first milestone we have been mainly focused on delivering an IPFS / web3 native VCS. The main challenges to do so were:

1. To implement a functional staging and branching system. Most developers are used to rely on git for their everyday activities. But we’re not always aware of everything that is going on beneath. To develop pando we’ve had to enter the arcane of git, mercurial and some other major VCS. That was a passionating but sometimes daunting journey. Anyhow, we are happy to finally come with a fully functional IPFS / web3 native staging and branching system: each version of each file is now identified, tracked and handled by pando through specific IPFS functions relying on ethereum native hash primitives - to assure cost-effective on-chain verifications.
2. To deal with IPFS internal roadmap peculiarities. IPFS is an amazing piece of software but IPFS implementations are not always on the exact same page and the documentation about the details of each implementation is sometimes scarce. This has led us to several refactoring of the pando.js library. Retrospectively though, this challenges have made us dive deep into IPFS internals, which is kind of a good thing.

Delivered packages

The following packages are available on npm:

1. `@pando/core`. Pando core smart-contracts and aragonOS apps.

2. `@pando/pando.js`. Pando typescript / javascript library.

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.

Where we are going

We have several ongoing works for the next milestone.

Refactoring

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.

Optimization

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:

1. Javascript. It has become a meme to complain about javascript’s performances so we won’t extend too much on that. Obviously we can't do a lot about this issue but to improve our own typescript / javascript codebase toward more efficient patterns. At one point we may propose a rust-based version of pando’s library but that’s far on our roadmap.
2. Blocking / synchronous functions call. In its current state the pando.js library heavily relies on async / await function calls. While this helps keep our codebase readable this also introduces a lot of unnecessary blocking function calls. For the next releases of pando we're gonna try to parallelize what can been parallelized to improve performances.
3. IPFS API. Our staging / branching system entirely relies on IPFS primitives. This is great, but in pando’s current architecture, this also requires a lot of slow socket calls through the IPFS API. For the next releases of pando we're gonna try to move some basic IPFS primitives - such as hash computation - into our own codebase to boost performances.

Key and signing management system

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.

IPFS Consortium

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.

Governance

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.

Gnarly | Optimistic UI for Blockchain Interfaces

• Refactored the internal architecture a bunch to allow parallel and time-independent reducers, so you can add additional indexes at run-time (i.e., track new non-fungible tokens (NFTs) or add a new metric to your open source block explorer dashboard in real-time)
• added retries for requests to ethereum nodes, vastly improving infura stability
• added an ERC20 reducer
• added block retention, necessary to fix some edge cases for replays, which is super exciting
• pouch db support in progress, which will give us server-client parity for indexes
• currently focusing on comprehensive testing
• a focus over the next 3 weeks is moving gnarly to plug-and-play beta with a focus on NFTs indexing, identity indexing, and gas-price oracles

Frame | OS-level Signing Provider

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.

What's next?

• Security audit. An audit from Cure53 is around the corner.
• Source and integrate feedback from users and developers. Frame is only useful if it solves real problems for both of these groups.
• Simple node administration. Frame will make it easy for users to opt into running their own node instead of relying on a third-party.
• Payload recognition. Frame will explore ways to add context to payloads to make their intent and effects human recognizable.
• Scaling the team. As fun as it's been to wear all the hats up to this point, it's time to grow the team. If you're interested in working on Frame or just want more information, email me, jordan@frame.sh

Prysmatic Labs | Ethereum 2.0 Sharding Client

https://prysmaticlabs.com/

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:

• Biweekly development updates through our Medium page
• Joined Aragon Nest
• Adopted design documentation pattern
• Made significant progress on our sharding implementation client
• Onboarded a new core developer

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.

If you have an expert level understanding of Ethereum, and have an idea for a proposal or wish to request funding for you or your team to work on one of those proposals, visit the Github repository!

Browse Nest Proposals at https://github.com/aragon/nest/issues

See Nest Requests for Funding at https://github.com/aragon/nest/pulls