Agora Suite

[sembrestels]

The Agora suite is a set of Aragon apps that prettend to help DAO governance.

The apps would be:

• Documents - For documents and agreements (in the future we can have another more specific app for Agreements)
• Proposals - A proposal would be text in IPFS and optionally an EVM script. It would be voted and if it passes, the EVM script is executed in the voting app context.
• Blueprints - An app to design, import, export, and propose changes in DAOs structure, including adding/removal of apps, permissions, and/or token holders, that can be voted in just one voting.
• Connections - An app that connects a DAO with apps from other DAOs through permissions (probably using an agent underneath)

Documents app

A document app contains a set of pages (title + ipfs hash) that can be created and updated by entities with CREATE_PAGE and EDIT_PAGE permissions respectively. The Agreements app in the above scheme could just be a plain Documents app.

The Documents app could be used to storing meeting minutes, invoices and other important data for the DAO, but the most important thing are the Agreements, that need a specific format to be useful and easily accessible: Agreements should only contain long-term decisions that affect the DAO.

Proposals app can create, modify agreements, and/or do anything else (transfers, DAO structure changes...). So, for example AGP-1 would be an agreement, and in each ANV people can vote on proposed changes (proposals) to it's foundational text.

Here @burrrata was thinking of using p2pmodels wiki app for a DAO that handles ANVs vs using GitHub. Essentially some token holders would have read/write access to the wikis (AGP editors) and then some token holders (ANT holders) would have the ability to vote to approve or deny wiki entries (AGPs).

Agreements

An app to publish the agreements (wet code) of a DAO and how they are reflected in the DAO structure (dry code).

The agreement management in particular would be quite useful for legal wrappers, there is a bit of a parallel effort that should be starting soon within A1 relateted to DAO bylaws and the aragon court. A1's agreements would be compatible with this vision?

We don't need a specific Agreements app at the moment, because the general use case is covered with a Documents app. In the future we can think on specific features that an Agreements app could cover, such as including dry code checks to the state of the DAO, an ACL oracle that prevents certain actions that don't comply with the previous agreements, etc.

Managing privacy issues

The easier way I can think of storing private data on IPFS is with a symmetric key (in which DAO members would share a password that can decode the invoices and other private data). A more interesting scheme could be done with https://www.nucypher.com/ and member's public keys, but it really depends on the sensitivity of the data that we want to store, how bad would be a data breach, what metadata and how important it is, etc.

Proposals

A proposals app is a documents app that wrapps a voting app (any voting app that can forward an EVM script). So we have proposals published and discussed on IPFS (Autark was working on something similar called Discussions), including or not an action (a transfer, a change in the DAO...), and when the proposal is finalized it can be voted. If we succeed, the AGP process could potentially migrate from github to a DAO with the Agora Suite. The Proposals app alone could also be used to wrap any existing Voting app providing a lot more of context to votes in any DAO.

• It would add state to pages. Pages would be draft, finalized, or accepted proposals.
• It would implement the Forwarder interface. This means that now we can grant permissions to the Proposals app, such as CREATE_PAYMENT on a Finance app, and then make a payment through it. The payment data is enclosed and stored as an EVM script, and we can add a title and a description in an IPFS file. Once the proposal is in finalized state (nobody can edit the proposal anymore), the acceptance process can begin (normally through a voting app), and once the proposal is accepted, the payment is executed.
• It would be compatible with any voting app that can execute an EVM script (one that just calls the acceptProposal() function). This means that the Proposals app can be the "new" Voting app that have most of the permissions of the organization, because it can "wrap" a Voting app, and improves the process of proposing changes to the DAO.

Proposals workflow

An intuitive workflow for this app would be that you perform an action (eg attempt to make a finance transfer) and it prompts you to create a draft proposal first, but this is not possible in Aragon because forward() does not accept parameters other than the EVM script, so we will approach this problem in two ways:

• When forwarding a transfer from the finance app, it creates an empty proposal with the evmscript, that later on is edited to incorporate a title and a description by the same author.
• When creating a proposal from the Proposals app, people can choose to include some basic actions such as transferring some money or editing an agreement, both with convenient UIs to fill the data required.

Proposals vs Agreements

Meeting minutes, invoices, etc. should not be included as DAO agreements, so we can use the Proposals app to log them (we can propose anything, they do not need to contain an EVM script), or they can be stored in another instance of the Documents app.

User stories

1. It is creating a tighter connection between wet and dry code (moist code?) in a way that is almost Ricardian
2. it is providing a mechanism for an organization to maintain a repository/history of documents related to the organizations operations, from bylaws/charters/operating agreements which ideally map to the structure of the organization, but also recording invoices and potentially other documents that an org might be required to maintain or keep on file.
3. Another important user story wrapped up in this is "staging" proposals and allowing them to be adjusted or modified before being finalized and put to a vote, which in and of itself is a huge win.

Proposals roadmap

• At the beginning we need a working documents app.
• Then we can make a documents app on steroids connected to a normal voting app, and EVM scripts could be attached to the proposals, so people could vote on descriptive proposals that move funds.
• Later on we could add compatibility with other voting apps (conviction, dot voting...), describe much better what dry code changes are being proposed with the "Blueprints" app, etc.

How would the EVM script be generated? At the beginning only payment scripts would be generated by the Proposals app. On subsequent developments, the Blueprints app could propose EVM scripts that change apps, permissions and token holders all at once.

Blueprints

About the app to design the DAO it would be great if it would be a kind of graph of dependies of each app with they permissions...maybe comparing current DAO graph and what the modified DAO graph will look like.

This is exactly what I was thinking. To visualize it in a graph, and use green, yellow, and red colors to show added, modified, and deleted elements, as in a git diff these diffs generated by the "Blueprints" app could be exposed in the "Proposals" app among with some text to contextualize, and then proposals can be validated using the normal voting app, or other apps such as the dandelion or conviction voting, depending on how the "Proposals" app is configured

Connections

An app to interconnect different DAOs' apps with permissions, simplifying complex governances.

Thanks to @lkngtn, @burrrata, @0xGabi, @rperez89, and @louisgrx for helping refine this idea though their useful questions and comments.

[0xGabi]

This is exactly what I was thinking. To visualize it in a graph, and use green, yellow, and red colors to show added, modified, and deleted elements, as in a git diff

I want this 🙌

Thanks for putting the idea together.

[john-light]

Some quick thoughts:

• I like the general idea. If we can move much of the proposal workflow off of 3rd party platforms and into the Aragon client I think that's a UX win.
• I would advocate for moving as much of this off-chain as possible. The blockchain is really only necessary in cases where either we have a strong need for data permanence (and are willing to pay for it) or we need to solve the double-spending problem. Editing proposal drafts or commenting on a proposal wouldn't fit either criteria, at least not for everyone.
• Regarding "tighter connection between wet and dry code" you may be interested in http://lexon.tech/ a human-readable programming language that can be used for smart contracts.

[sembrestels]

Thanks for your interest @john-light.

I like the general idea. If we can move much of the proposal workflow off of 3rd party platforms and into the Aragon client I think that's a UX win.

I like the idea of a suite that provides simple modules that work well together. I see Proposals as the new Voting app, an app that will use a Voting app underneath but will provide a lot more context and discussion to what people is voting. I think that it is better to keep Aragon Client thin, and move this kind of functionality to small apps that work as intended.

I would advocate for moving as much of this off-chain as possible.

Drafts, proposals, and comments will live on IPFS. We will only store hashes that are really necessary on chain (probably drafts and final proposals), and we'll try systems like IPFS pubsub and Swarm's PSS for comments, or ultimately relay on 3box discussions.

you may be interested in http://lexon.tech/

Wow that's lit! It will require a lot of research to to put into an aragon app, so letting it out of the scope for now, but it will be a source of inspiration! Thanks for sharing!

[john-light]

Drafts, proposals, and comments will live on IPFS. We will only store hashes that are really necessary on chain (probably drafts and final proposals)

Right, but this still requires a transaction on-chain. We should think of going on-chain as a last-resort mechanism, when no other solution will do. At least for keeping track of drafts and comments, I'm sure there are many solutions that don't require going on chain.

[sembrestels]

I think it has sense to write comments that change slightly the proposal and treat them as drafts, yes! I'll be exploring Autark's discussions app too to see if it fits our use case properly.