This is the regular monthly progress report for Autark and our partner 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: June 2019, May 2019, April 2019, March 2019.

General Updates

Our funding proposal to continue our work in the Aragon Flock program was approved on July 27th, 2019 in Aragon Network Vote #3! This proposal awarded 1,600,000 DAI for another year of operations. We are so excited for what is to come and what more we can do to build the Aragon ecosystem. Read more about the vote here.


July 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

Since our last update:

  • External intents: Our aragon.js PR for external intents has been merged, we need to make UI changes to the aragon client PR before that can be merged.
  • Dynamic Forwarding: We're waiting for a full review of Dynamic Forwarding from Aragon One to move forward with that work.
  • Forwarder API: We're still in the process of making requested changes from our PR review to the forwarder API.

What's Next

During this month, we expect to have the forwarder API changes merged into aragon.js, and begin work on leveraging these features in our revamped Dot Voting app. For the time being we're moving forward with a local version of Dynamic Forwarding pending the next aragonOS release cycle.

Review June 2019 update

Progress: 70%

The majority of the Dynamic Forwarding work has been completed and we are now working on integrating Dynamic Forwarding into Dot Voting. In June we've created a new execution type for forwarders and are excited to see how developers and the community respond to the new forwarder patterns that this will allow.

For what we have scoped in AGP-19, we feel that this initiative is close to completion, with PR reviews, integrations, and testing remaining. A summary of our deliverables:

  • Forwarder API: Makes data accessible for actions that have been forwarded to another app (aragon.js PR)
  • External intents: Ability for an app to interact with an external contract (aragon.js PR, aragon client PR). This was developed to support contextual discussions, and we believe a good step toward multi-contract Aragon apps.
  • Dynamic Forwarding: Allow for more tightly coupled forwarder interactions where the forwarded call data can actually be leveraged and modified within the Forwarder contract. (in the process of preparing an aragonOS PR)

All of the features described above will be showcased in a revamped Dot Voting app. While this initiative is close to completion for the deliverables we have scoped, we see it as a continuous effort, as we don't think cross application UX is close to being solved at a macro level. As an added bonus: we are developing solutions for deep linking that we will share in our next update.

Review May 2019 update

Progress: 40%

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

In June, we built a contextual discussions proof of concept application. In July, we’ve made significant improvements to the proof of concept - it’s starting to become a real, usable application:

We’ve also decided to hold off on creating a contextual discussion node module until there’s more demand for including contextual discussions in other applications. In the meantime, we’re happy to assist anyone who wants to incorporate contextual discussions in their own Aragon app (hop into our community chat here).

Additionally, we have not built token-weighted likes into contextual discussions. We haven’t heard much from the community about this feature, so we decided to deprioritize it in favor of other, more pressing feature additions and enhancements.

What's Next

In the next few weeks we will be making the current implementation more robust to bring our AGP-19 work into conclusion. Any additional feature-adds will be addressed in AGP-73's Expanding Social initiative, after we do more user research and testing.

Review June 2019 update

Progress: 70%


The technical architecture behind contextual discussions has evolved since we started. Originally, we imagined a centralized query layer built on top of IPFS to support discussions. But after publishing our ideas in more depth, the community seemed to prefer more decentralized approaches. We researched Textile, OrbitDB, and 3Box and published our key findings (OrbitDB and Textile notes; 3box notes).


In short, Textile (originally designed for mobile environments) won't work for Aragon apps yet because each user would need to run a node locally on their machine. Orbit and 3Box don't integrate easily with Aragon apps because they require access to storage APIs, which are restricted in Aragon app iframes. The next best option is to use smart contracts.


So in June we built a proof of concept contextual discussion app using smart contracts. This required a few feature additions to Aragon to support external intents that we described in I01. Most importantly, an Aragon application will soon be able to initiate transactions with external smart contracts (currently, an Aragon application is closely tied with a single contract).


Getting this to work in a dynamic and secure way required some other additions as well. If you’re interested in more information, here are the pull requests (which were also linked in I01 above):
https://github.com/aragon/aragon.js/pull/328
https://github.com/aragon/aragon/pull/850
In July we are working on building easy to import UI and state building modules for adding contextual discussions into your own Aragon application.

Review May 2019 update

Progress: 30%

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

For the purpose of AGP-19 we consider the Rich User Profiles initiative completed. We launched an experimental version of the client where you can create your profile. There are more details on our blog post that showcases our work on Aragon profiles.

Here is a breakdown of how what we have delivered compares to some of the features we imagined in the original AGP-19 proposal.

Features we delivered

  1. Built the first identity solution for Aragon, with an interoperable Ethereum Profile through a 3Box integration
    • As there existed no Identity app for us to extend as we initially conceived, we had to build a Profiles solution from the ground up. After performing our initial research, the community consensus achieved via All Devs calls and the forum was to use 3Box.
  2. Ability to edit your name, bio, and website
  3. Ability to manually input work experience
  4. General purpose message signing functionality in Aragon (unplanned)
    Using 3Box required enhancing the Aragon stack to allow signing arbitrary messages:
  5. Ability to manually input education (unplanned)
  6. Ability to edit your avatar & cover photo, with a seamless click-to-change interaction (unplanned)
  7. Check and display verified GitHub and Twitter profiles (unplanned)

Features we didn’t deliver

We weren’t able to deliver the following features. Some of them had to get deprioritized to make time for unplanned features and others had technical limitations.

  1. Ability to display memberships to other Aragon DAOs on your profile
    • The technical limitations around verifying if an ethereum address is a member of an organization caused us to punt on this feature. There are several ways to accomplish this, but the time and effort to complete any secure and verifiable solution did not seem worth it.
      • The ideal solution involves enhancements to Organization Identity for an organization to add a list of tokens that represent membership to the organization. Once this dependency is complete, we will be able to add this more user-friendly pattern. We already completed front-end support for this feature with mock API support.
  2. Ability to import data from LinkedIn
    • LinkedIn has restrictive APIs and does not allow this feature unless being approved as a partner. After speaking with LinkedIn support, we were informed that we did not fit their partnership qualities for the integration we had envisioned building.
      • Instead, we added the capability to add your education to your profile.
  3. Ability to import commit history from Github, highlighting top projects
    • Authorization to third party applications in a core feature like Profiles requires enhancements to the stack, and also more buy-in from product owners. It also presented some interesting UI challenges. We deprioritized this to remove immediate friction with delivering profiles.
      • Instead, we added the capability to view your Github and Twitter social verifications.
  4. Ability to curate a portfolio of images (such as design work) hosted on distributed storage
    • This feature got deprioritized simply because we had to prioritize more important features such as message signing and managing your avatar and cover image within Aragon.
  5. Integrating our profiles solution with the Aragon IdentityProvider so the avatar and name show up in place of ethereum addresses within Aragon.
    • This feature was never in scope for AGP-19, as our initial plan was to extend an Aragon Identity app (vs. building a fresh solution). We had wanted to deliver this piece, but there wasn’t time in AGP-19 with all things considered.

What’s Next

In AGP-73, we have the Expanding Social initiative which includes continuing our work on profiles. At the very least, we plan on integrating profiles with the Aragon Identity Provider, targeting for completion in September. We also will add the capability to add organizations to your profile as the dependency will have been completed. Additional features can be developed on an as-needed basis, prioritizing top user requests, but our primary goal is to fully ship profiles with the current features so it’s part of the client and easy to use.

Review June 2019 update **Progress: 90%**

In June we have been putting the final touches on our Aragon Profile app. We converted it into a node module so it can be imported into the Aragon Client, making it easier to maintain in the near-term before it becomes fully part of the client.

We’ve also been fixing small bugs and making performance improvements. There are a few issues left to be worked out with Aragon One on finalizing the profile integration; more information can be found in this pull request.
Review May 2019 update **Progress: 70%**

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.
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

We implemented the previously established strategy for quasi-transferable tokens using a transferability oracle in the Token Manager. This approach ensures full backwards compatibility with previously deployed Token Managers.

We've also provided a basic example oracle allowing for sender whitelisting. In the future we expect to need at minimum a receiver and a sender/receiver oracle but using this development approach we're sure more complex patterns will emerge!

We've also developed a basic template that includes the setup of this new Token Manager.

What's Next

All of these deliverables are currently entering into review and we expect them to be fully completed this month.

Review June 2019 update

Progress: 50%

We solidified a strategy for quasi-transferable tokens that will allow for both recipient and sender whitelisting with only modifications to the TokenManager and not the token contract itself. We should have the initial proof of concept for quasi-transferable tokens (and as a result reputation within Aragon) by next month's update.

Note: in our previous update we mentioned the Projects app contract upgrades, but so things are more clear going forward we will talk about Projects in I07.

Review May 2019 update **Progress: 30%**
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

To conclude our work for this AGP-19 initiative, we published the spec for Smart Contract Based IPFS Storage for DAOs. This specification will be the basis of our work for Smart Contract IPFS Pinning Initiative from AGP-73. Read our June 2019 update below if you wanted further details on our work on this initiative.

Review June 2019 update

Progress: 90%

Similar to contextual discussions, our goals with respect to storage this grant cycle have adjusted as we've learned more about what the community wants. There are two main findings: first, we learned that migrating off third party IPFS storage providers like Infura was a favorable initial step towards a more decentralized architecture. Second, Aragon teams and users need more sustainable and secure IPFS pinning architectures, so we put together a spec of what DAO tailored IPFS pinning solutions could look like. We feel like we're very close to accomplishing these goals.

During our offsite, we deployed our own IPFS node and are starting to host our user generated content and applications there. Soon we will no longer rely on any centralized service providers (but we may continue to back up copies of information there). We have updated all of our applications to use our IPFS node and are doing some more testing this week to ensure our node is stable.

Lastly, we have been working with the greater IPFS and Ethereum communities on an IPFS Pinning architecture for DAOs. We plan on formally publishing this spec this week, but if you're interested, here's a sneak peak. The spec is being continuously peer reviewed and refined, so if you have any feedback, please let us know! We are excited to build this architecture in our next AGP!

Review May 2019 update

Progress: 30%

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

In July, we polished up the UI of the Home app and published the Storage and Home apps to Rinkeby. We also deployed an experimental version of the client so you're able to change the default Home app. Check out this guide that walks you through the install process or check out this DAO that has a custom Home app.

Background

Whenever we initially proposed the Organization Identity initiative we had described an “About app” to manage organization data blobs such as a manifesto, mission statement, team information etc. In April 2019, we began to make the case that instead of a separate About app, an organization should be able to customize their Home app. We received buy-in from the greater community on this approach.

To implement this, it required:

  1. Building a new background app, the Storage app, to allow organizations to store custom settings. It’s a background app similar to the vault, such that there is no UI for it.
  2. Extending the Aragon Client to connect the Settings page to this Storage app. It needed to save and fetch data from the Storage app, and provide a new setting in the UI for changing the home app that is in the left navigation.
  3. Building a custom Home app, that allows organizations to manage the information displayed on the Home app. This is where you can add your mission statement, team members, link to your manifesto, etc! This is managed with a new markdown editor component that we developed, with the content stored on IPFS.

What's Next

We plan on wrapping up our work for this initiative in August by completing the additional "Organization Settings" features. Check out some of our thoughts here on what we want to implement, and the designs below.

Review June 2019 update **Progress: 60% **
We've taken our next steps towards allowing more settings to be saved at an organization level. To these end we've completed the aragon-storage application that will allow for the client to generate use case specific data. This is a "behind the scenes" application similar to the Vault, only instead of funds, it holds data. Long term this will allow us to save custom styles for organizations, but for now we are leveraging it to allow organizations to configure their default home application.

We've also completed complimentary work in the client so that this storage application can be saved to and read from as well as the specific work to allow for home the default home app to be set in the client.

Now that that dependency work was in place, we were able to bring the Home app MVP to close completion: the background worker integration with IPFS was completed, and an organization can set this new Home app to be the default (or any other app of their choice). We are still going through code reviews, testing, and minor cleanup but you should be able to run the code locally and check it out!

Review May 2019 update **Progress: 40% **
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 update Whenever 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 Open Enterprise

For the purpose of AGP-19, we are considering this initiative completed. In April we said we will consider it "90% once all apps have been handed off for a security audit" which included a lot of enhancements to contracts in parallel, although that was never what was actually scoped. This was the only initiative we could place our updates since the Rinkeby launch – but the Rinkeby launch marks a better completion date of the scope of AGP-19.

As far as what we did in July:

  • We completed integrating StandardBounties v2 into the Projects contract, performed an internal audit, and handed it off for external audit
  • We finalized the revamped contract for Dot Voting, performed an internal audit, and began incorporating changes for the hand-off to our external auditors
  • We made changes to the Rewards and Address Book contracts based on the external audit feedback
  • We finalized the revamped contract for Allocations.
  • We began redesigning the Open Enterprise apps based on the aragonDS (Aragon Design System) guidelines

What's Next

We have an Open Enterprise initiative in AGP-73 and this will move into that bucket on subsequent updates. Regardless, all of the revised contracts will be in the hands of the auditors this month. Allocations is currently undergoing an internal audit and that's the final internal audit.

What will then be remaining for late-August to October is:

  • Incorporate all auditor feedback and get it re-reviewed
  • Upgrade all apps to aragonDS
  • Develop additional frontends and web3 integrations based on contract changes and API enhancements
Review June 2019 update

Progress: 80%

In preparation for our security audits, we have started to upgrade our contracts and also perform internal audits. We performed internal audits of our Address Book and Rewards contracts, and our security audit was kicked off on June 24th.

We upgraded Address Book so an Ethereum address is associated to an IPFS hash, which will allow organizations to eventually store more metadata besides a name and type. This upgrade will also make the Address Book more compatible with the Aragon IdentityBadge component down the line.

We are nearly complete with integrating the Projects app with the new StandardBounties contract and are now exposing features such as being able to cancel bounties at the contract level. Additionally, activity with Projects-funded bounties that occurs outside of Projects will now be captured, such as external fulfillments. Note that the frontend development is still pending for these new features, but we are aiming to republish Projects to Rinkeby soon™.

In July we will be finalizing the Projects, Allocations, and Dot Voting contract upgrades and handing them off to our security auditors.

Note: we have rebranded That Planning Suite to Open Enterprise, so this initiative has also been renamed.

Review May 2019 update **Progress: 70%**
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. 😍😍😍 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.

July 2019 Spending Report

July 1, 2019 — July 31, 2019

Previous Balance

  • USD: 29,305
  • EUR: 67,856 (76,060 USD)

Total: $105,365 USD

Costs

  • Autark Payroll (2 pay periods): $51,751
  • Open Work Labs Payroll (2 pay periods): $10,000
  • Contractors (Accounting, Design, Recruiting): $3,843
  • Offsite: $2,224 (partial spending, previous costs occurred last month)
  • Co-working space memberships: $526
  • Software: $802
  • Business lunch: $45
  • Misc. Transaction/Conversion Fees: $206

Total: $69,397 USD

Current Balance

Based on our accounts:

  • USD: 26,728
  • EUR: 9,472 (10,617 USD)
  • ETH: 1.725 (389 USD)

Total: $37,734 USD

Verify: $105,365 (previous balance) - $69,397 (costs) = $35,968 USD

We have more in our bank than expected, and I think this is due to the fluctuation in the value of Euro. We still haven't had time to fully reconcile, but at least it's above our projection.