This is our regular monthly progress report for Autark and Open Work Labs' work on AGP-19, which was funded via Aragon Network Vote #1. This post is broken down into the initiatives in our original proposal. You can review previous updates here: April 2019, March 2019.

In this report we are experimenting with progress meters per initiative. Since each initiative has a different effort weight (which is not displayed, as we didn't have time to calculate it for timely delivery of this report), averaging them out doesn't accurately represent our macro-progress. From a bird's-eye view, we feel on track with our work.

Next week we are having our first team off-site and we plan to return with a draft of our roadmap for Aragon Network Vote #3, including a community curation process. Here's a sneak peak of some of my thoughts below (not all will make the cut). Share your feature requests here so we can collectively prioritize!

If you are a Solidity developer with a background in cryptography and security, please DM @stellarmagnet on Twitter as that's a role we are trying to recruit for our next grant.


May 2019 Progress Report

Autark's AGP-19 Initiatives. I03, I02, I06, and I04 consume dependencies from I01, I05 and I07.

I01 - Cross-Application User Experience

aragonAPI: Forwarder API

Currently, if you create a transfer using the Finance app which requires a vote for approval, the Finance app will have no knowledge of this transfer until the vote concludes. This is due to limitations in the API where data is not accessible for actions that have been forwarded to another app. The enhancement we have developed, the Forwarder API, will enable application developers to implement more traditional web experiences, where members of a DAO will have better knowledge of the pending actions within the application that originated the action.

We have completed development of the API, which generally follows the specification outlined by Brett on the Aragon forum, and submitted a PR to aragon.js which is pending review. This API will be a very useful tool for us to eventually display actionable data within the Home app and hence supports our Organization Identity initiative as well.

Dynamic Forwarding

We've started initial work on Dynamic Forwarding with aimed completion of the initial spec ready for review by our next monthly update. These changes will allow for more interesting forwarder interactions and allow access to application defined options to unfold in forwarder applications. Once developers have these tools they'll be able to change the way forwarded actions are executed based on the state of the forwarder at the time of execution. This will allow for increased experimentation with non-boolean voting patterns.

Review April 2019 updateBased on development survey results and our own experience developing Aragon apps, we published a forum post that describes features that will be important to enhance the user experience for Aragon users.

After further review, we have decided to prioritize the development work based on our other initiatives that are dependent on these enhancements. Hence our initial focus will be areas that are related toward the Organization Identity initiative.

Read more in the I06 section of this update for details.
Review March 2019 updateWe created a survey to understand the developer’s experience with creating Aragon apps and received five responses. We are in the process of writing a report for the forum which will synthesize the findings from the survey along with notes from a meeting that took place at the end of January at AraCon. The purpose of this report is to discuss our recommendations with the broader community which will lead toward a spec to enhance the aragonAPI and Forwarder, to deliver on our Cross Application User Experience initiative.

Since our report is still in progress, we are still accepting answers to our survey. If you have experience developing Aragon apps, please participate — it should take no longer than 5–10 mins.
Review AGP-19
aragonAPI
A major limitation of the Aragon architecture is the tight coupling between an individual application front-end and contract. With this limitation, there is less freedom to design feature sets with the optimal user experience, where multiple contracts may be more logical for a single application.

To improve upon the architecture, aragonAPI will be modified so as to support both relationships between a single app front-end and multiple contracts, as well as add tools to allow for contract data to be displayed across multiple user interfaces without coupling at the contract level.

Once the flow has been defined within aragonAPI we will create at least one example of how we see ideal one-to-many and many-to-one relationships working.

Expanded Forwarder Options
Currently the forwarder is mainly designed to pass isolated actions where the forwarder has little to no knowledge of the forwarded action. We will research potential ways to expand its usability by creating additional specifications for script execution. This will allow for more tightly coupled forwarder interactions where the forwarded call data can actually be leveraged and modified within the Forwarder contract.

At minimum we will design the specification and implement it in aragonOS for forwarder interactions that expect data to be passed between the forwarding and forwarder contracts at the contract level.

I02 - Contextual Discussions

There are no additional updates since our previous report. This work is expected to continue mid-June, once Profiles is in a more finalized state.

Review April 2019 updateAs mentioned in our March update, we completed the technical spec for discussions. This month there has not been any development work directly related to discussions, although there has been dependent work that this initiative is consuming from the Data Storage initiative. Read more in the I05 section of this update for details.
We plan on beginning Discussions application development work after completing the Profiles initiative.
Review March 2019 updateFor discussions, we created a V1 spec for a traditional database that stores data on IPFS and resolves requests for content through hashes, not arbitrary IDs. This is in tune with what we proposed as the “short term” solution in our Flock proposal.
Review AGP-19Many applications throughout Aragon would benefit from contextual discussions or commenting. For example, if there is a transaction displayed in the Finance app, a member of the organization may be interested in beginning a discussion related to a transaction in the table. Additionally, Votes, Surveys, and Range Votes will all benefit from having the discussion located within Aragon.

At the high level, discussion capabilities will have:
  • Ability to add, edit and delete comments
  • Support for markdown
  • Ability to like comments, weighted by the amount of DAO’s tokens held at time of snapshot based on context
We will ensure that the work we do in enhancing aragonAPI will enable us to support this use case, and will deliver at least one fork of an existing app that has integrated discussions.

I03 - Rich User Profiles

Profiles in Aragon are nearly feature complete, and we've started to integrate our work into Aragon client. A user can associate information about themselves to an Ethereum address including a name, bio, website, location, work and education history, and also a profile and cover photo! Since the profiles are built using 3Box, a user's profile from Aragon will appear on any other application using 3Box for profiles.

Soon there will be a more global way to share identities across Aragon, including your work history. We think this is important for worker DAOS. Our new software engineer Chad Ostrowski, who just joined us this week, is creating his profile and adding his Autark role!
Review April 2019 updateWe began development of the Profile app and completed the 3box integration; right now we are building out the remaining frontend features.

To support this effort, we submitted 3 PRs to Aragon repositories to integrate signing arbitrary message into Aragon, in attempt to make Profiles compatible with 3box:
  • https://github.com/aragon/aragon/pull/708
  • https://github.com/aragon/aragon.js/pull/282
  • https://github.com/aragon/aragon.js/pull/276
There is still some more work to be done to resolve iframe sandboxing security restrictions, in order to become compatible with OrbitDB (which 3box utilizes).

While we began the prototype as an app, we think that profiles should be included in the Aragon client, as the MVP of a user profile is organization-agnostic. We plan to present our case for this in the coming weeks.
Review March 2019 updateSo far, we’ve created a complete profile spec as well as a proof of concept application that scrapes profile data from LinkedIn, formats it according to linked data standards, and stores it in a 3box profile. Unfortunately, LinkedIn’s developer program rejected our request to use their full profile API, so we will not be integrating with them. Once message signing within Aragon is resolved, we can implement 3box in an Aragon app.
Review AGP-19While Aragon One’s identity app will provide much-needed features; an identity is more than a name, bio, ENS domain, and avatar. We propose to expand identities to allow for more rich profiles. This will be useful as the network of organizations within Aragon grows and a freelancer culture develops. This supplementary data can be useful in assessing allegiances, expertise, and clout.

The additional data elements that will be relevant to expose in relation to a profile can be:
  • Memberships to other Aragon DAOs
  • Work Experience
    • Ability to import data from LinkedIn or manually input work experience
    • Ability to import commit history from Github, highlighting top projects
    • Ability to curate an portfolio of images (such as design work) hosted on distributed storage
While we are aware 3box is developing “Ethereum Profiles” which may cover aspects of this initiative, we will perform an assessment to see if it makes sense to leverage their framework before going all in on a fully custom implementation.

I04 - Expanding Governance

Our Projects app currently interfaces with the StandardBounties contract developed by the Bounties Network, and they have recently released an upgraded version that will help enhance this initiative. We have started to analyze the new contract and plan to begin integration in June. This enhancement will provide support to this initiative as we extend the capabilities of the Projects app and eventually bring support for non-transferable tokens.

Review April 2019 updateThis is an initiative that expands upon our Planning Suite work by providing more features for reputation/merit based organizations, and we are in the process of planning the development timeline for the quasi-transferable token solution which is the core of this initiative.

This month we did develop a template for the Planning Suite and once we complete quasi-transferable tokens, it will be really easy to modify it to support the DAO Template aspect of this initiative.
Review March 2019 updateThere were no updates in March.
Review AGP-19Reputation System
Implementing a reputation system within Aragon will expand governance possibilities and allow the usage of Aragon for reputation-based governance without requiring the integration of external applications such as Colony or DAOstack which can add security risks.

The most logical place to implement the reputation system will be within the Projects application. To support reputation, changes to the Token Manager will be required, to allow minting a special type of quasi-transferable tokens that can be transferred only by a whitelist of addresses (e.g. the Standard Bounties contract or a specific Aragon application). Additionally, the Projects app will have to be enhanced to allow multiple tokens to be allocated to bounties.

The end goal is that when a user completes a task using the Projects app, they can collect a variety of tokens -- standard ERC-20s in addition to non-transferable reputation tokens.

DAO Templates
At the moment, there are only two templates: Multisig and Democracy. To expand governance possibilities and allow for an easier user experience when a new DAO is being deployed, it will be beneficial to develop additional templates for the ecosystem. As part of this initiative we aim to create one additional template that will support reputation-based organizations.

I05 - Data Storage and Standards

There are no updates since last time. This work will be finalized in parallel to the discussions initiative as it is related.

Review April 2019 updateWe began to share research and ideas on the forum related to IPFS pinning and querying -- and this impacts three of our initiatives (I02, I03, I06) that rely heavily on user-generated data in different ways.

We wrote an overview of our research on OrbitDB, Textile and 3Box that will also be shared in a blog or forum format soon.

Our Flock proposal mentioned intermediate caching solutions, and hence we developed the beginnings of a backend REST API that pins files and metadata to IPFS and stores information in Mongo. The file adding, dag putting, pinning functionality, and Mongo storing are working. We’ve backseated this API for now as the discussions on IPFS Pinning solutions mature into an action plan.
Review March 2019 updateOur goal is to support Aragon discussion and profile applications with production level storage solutions for off-chain data by August 2019. Initially, we researched OrbitDB and go-textile — two distributed database solutions built on IPFS — to see if we could use their technology. We’re extremely excited about the potential of both of these projects, however, using either to build a production grade browser application in five months would require a significant amount of work on DevOps and private key management.

Generally speaking, we see two viable options — either leverage other technologies built on Orbit or textile that assume most of the risk, or build an infrastructure today that’s designed to scale into a fully distributed system later. For profiles, we think that 3box, an Ethereum profile API built on Orbit, will be the best solution. Not only does this seem to have Aragon community support, but it’s easy to use and we’re very close with their founding team in case any unexpected obstacles arise.

Review AGP-19Discussion forums, rich user profiles, and other familiar collaboration features are unique because they rely on data that is not efficiently stored on Ethereum. Our long term goal is to support these features with completely distributed storage while maintaining capabilities like optimal querying and dynamic access control. We’ll start with a “web 2.5” storage solution, learn more about users while relevant technologies mature, and remove intermediate services over time.

DAOs should be able to store their data with these qualities:

Accessible — all data from discussions and features alike will be available in distributed storage. This allows anyone to view and backup work without hitting a centralized server.

Standardized — by content addressing data and following open data standards, we can make people’s work more compatible across DAOs and other open source projects.

Timestamped — contributors should be able to create snapshots of their work across platforms. One way to do this is to store data on IPFS and write the hash to Ethereum.

Next 6 months - Immediate support for discussions and profiles

A near term storage solution preserves important qualities of decentralization without jeopardizing technical feasibility or user experience. It has a distributed data layer (i.e. IPFS) with intermediate services running on top of it. These services should be open source and provide clients efficient read/write capabilities to/from distributed storage.

Our initial architecture will likely have a distributed data store with intermediate services on top for caching, indexing, and writing to distributed storage. Although clients can always fetch data directly from distributed storage, our intermediate services will give enhanced access to it.

We’ll also be exploring how events relating to DAOs from centralized apps and Ethereum could be captured and displayed within Aragon apps. Some example events could include GitHub commits, issue comments, external forum discussion, etc.

Over time we can replace intermediate services with their distributed counterparts such as OrbitDB, BigChainDB, Threads, Solid and others. Part of our goal over the next six months will be to better understand the feasibility of using these technologies.

I06 - Organization Identity

After sharing a design concept on the forum, we received feedback from Aragon One to go for a more simplified approach with respect to how the content is managed, yet to also provide flexibility for organizations to decide which app is their default "home app".

In order to allow for more organizational customization we have begun development on a storage module which we will integrate directly into the client. This will allow us to have dynamic access to decentralized assets with all of the benefits of the ACL.

Storage will be a contract-only application and is the technical building block that will enable DAOs to customize the existing Home app. While you could easily make Voting, Finance or your app of choice your home page, we hope many will opt to use our new Home app. Over time we will continue to leverage this new Storage module to allow users more control over Organizational Settings!

We have almost completed the MVP for our Home / About app, which currently includes a markdown editor and rendering. A few missing pieces are signing/saving data updates and some enhancements are still needed to the stylesheet.

Review April 2019 updateWhenever we initially proposed the Organization (DAO) Identity initiative we had described there would be an “About app” to manage various data blobs such as a manifesto, mission statement, etc. Although in the past month, we began to make the case that instead of a separate About app, that this should instead be the Home app.

We received buy-in from Aragon One on this high level strategy and in the past few weeks we have been starting to share design and technical research to receive buy-in for the ultimate implementation.

We delivered an initial design concept which presents a widget-based approach for customizing an organization’s homepage. In order to accomplish this, we need the ability to: pull individual application state into the client, store information about the home app, interpret information pulled from individual applications, and provide information back to individual applications. Refer to the technical architecture proposal for some initial ideas.
Review March 2019 updateThere were no updates in March.
Review AGP-19Organizations and entities have unique brands, which help them differentiate from one another and convey a fine-tuned message. One value add for the Aragon platform will be to provide features that allows an Organization to showcase their unique identity. At the moment, Organization avatars are the only way to differentiate. With the DAO Identity initiative, this will be expanded by allowing a DAO to tailor the branding and theme of the Aragon platform and also providing a user guide for self-hosted domains. To kickstart this, we will:
  • Design at least three additional themes (including dark mode) and enhance the Organization Settings to support switching between themes
  • Enhance the Organization Settings to support changing the background image (at the moment it’s an Eagle)
  • Develop a simple read-only “About” Aragon App where the DAO can input and display their manifesto, mission statement, values, code of conduct, contact information
  • Write a user guide for hack.aragon.org that describes how to deploy Aragon to a self-hosted domain

Eventually, the long-term goal for this initiative is to move toward a “Wordpress for DAOs” experience, with a rich library of themes and many ways to easily customize layouts. To support this ultimate vision, we will begin research to assess any architectural changes required.

I07 - Rewards Application and Planning Suite

In April, we reported our launch of That Planning Suite (TPS) onto Rinkeby which we feel is complete with respect to our original Nest proposal. But the Cross App UX initiative (I01) and the Expanding Governance initiatives (I04) are important dependencies needed for us to get v1 of TPS into a mainnet stage. To support the mainnet track, in May we performed QA for cross browser compatibility, made progress on end to end testing, and addressed bugs reported by alpha users. In June we will be performing our internal audit and begin integrating enhancements.

What we weren't prepared for is our alpha users immediately using our Rinkeby apps for real DAO operations! The Aragon Mesh team has been paying bounties on mainnet after a ticket is completed in Rinkeby. 😍😍😍

The first bounty facilitated by That Planning Suite!

1Hive is another related organization that has started to use TPS on Rinkeby for operations as well and we are even featured on their homepage! We have been addressing bugs they have found and are also starting to prioritize their feature requests for our next AGP.

For our progress meter, we will mark this initiative as 90% once all apps have been handed off for a security audit. Hence the 20% between there is addressing feature requests, bugs, and enhancements taking up new components we are developing.

Review April 2019 updateRewards
Last month we were in the middle of the application development for the Rewards application, with the integration between the front-end and smart contracts remaining, and this month we completed the development.

Reward distributions can now be created using an snapshottable reference token that conforms to the Minime function signature. Rewards can also be created and calculate retroactively (so long as they don’t predate the creation of the reference token).

Planning Suite
We completed making all of our applications responsive. We got fully acquainted with the process of publishing applications and updated our application manifests to conform to the new app center standards with screenshots, simple descriptions and icons that are complementary to the other Aragon core apps.

We launched That Planning Suite on Rinkeby and created a demo Dune DAO that comes with our apps installed.

We developed a template to create a Planning Suite DAO, basing it off the Democracy and Beta Base templates, and also integrated it with a frontend to make it really easy for people create a Planning Suite DAO without touching the cli. This resulted in us spinning up a server to host a version of the client at rinkeby.autark.xyz. We did also create a guide for people that are interested in installing the apps individually via the cli.

While we are on Rinkeby now, there is always room for improvement. Our next steps are to finish implementing end to end testing, perform QA for cross browser compatibility, address bugs reported by alpha users, perform a thorough internal code review and audit, lock down our contracts so we can then hand it off for an external security audit, and make adjustments as necessary for our mainnet release.
Review March 2019 updateThat Planning Suite (TPS) is a suite of aragonOS apps that allow DAOs to curate issues, collectively budget, and design custom reward & bounty programs.

We began the development of the suite as part of the Nest program where the work was divided into five milestones. As mentioned in our Flock proposal, the plan was to roll up Milestones 4–5 into Flock. To provide some additional context, Milestones 1–3 included the following apps: Range Voting, Address Book, Allocations, and Projects. Milestones 4–5 includes the development of the Rewards app in addition to fine-tuning the entire suite — and these milestones have been one of our primary development efforts in our first five weeks as a Flock team.

For the Rewards app: we completed the smart contract work and the front-ends, and have began integrating the two.

As far as the “fine-tuning” of TPS, we have:
  • Implemented Cypress for end-to-end testing
  • Implemented the store to handle concurrent events
  • Integrated various aragon-ui components to make consistent with existing Aragon apps
  • Began the work to make TPS mobile-friendly / responsive
  • Addressed various code review comments from Aragon One from our previous milestone reviews
  • We are on track for deploying That Planning Suite to Rinkeby by mid-April.
Review AGP-19This Flock proposal includes team members that were awarded a Nest grant for a Planning Suite, which contains five applications: Allocations, Range Voting, Address Book, Projects, Rewards.

The plan is to finish Milestone 3 by the end of January, before the Flock funding would begin. This Flock proposal includes rolling up Milestone 4 and 5 into Flock which entails the Rewards app, and any final “clean up” to get the Planning Suite into a stage to launch. Since we are rolling up Milestone 4 and 5 into this proposal, that means that we will not get paid those additional milestones which value to $40,000. Instead, the team will be paid via Flock payroll.

Since the completion of the Planning Suite overlaps with the timeline of this Flock proposal, we think it makes sense to roll up the remaining work as it will be delivered more expediently with more full-time team members.

May 2019 Spending Report

May 1, 2019 — May 31, 2019

Previous Balance

  • Fiat: $30,122 USD
  • DAI: 21,185 DAI

Total: $51,307 USD (assuming 1 DAI = 1 USD)

Income

Payment from Aragon Association (2nd half of our Flock): 175,000 EUR ($195,174 USD)

We decided to take our 2nd payment in EUR, as if we took DAI we could have had about 3% slippage which means a $5,850 loss. We didn't budget for such exchange rates. In our next AGP we will take slippage into account and also research the most cost effective ways of converting DAI into fiat.

Costs

  • Autark Payroll (2 pay periods): $45,474
  • Open Work Labs Payroll (2 pay periods): $10,000
  • Offsite: $8,311 (partial spending for 7 people, more in June as our offsite takes place June 2-8th)
  • Co-working space memberships: $526
  • Equipment (3 laptops, standing desk, misc. peripherals): $6,556
  • Software: $349
  • Misc. Transaction/Conversion Fees: $509

Total: $71,727

Our costs were higher this month compared to April as we made equipment purchases, onboarded a new frontend engineer, and began booking transportation, accommodation and activities for our offsite.

Current Balance

We converted our DAI and some of our Euros into USD for operations.

  • USD: 45,110
  • EUR: 116,310 (129,644 USD)

Total: $174,754 USD

Verify: $51,307 (previous balance) + $195,174 (income) - $71,727 (costs) = $174,754


If you are a Solidity developer with a background in cryptography and security, please DM @stellarmagnet on Twitter as that's a role we are trying to recruit for our next grant.