I’m working with Berty , an open source, non-profit project whose goal is to enable secure, privacy-preserving and censorship-resistant p2p communications.
As we get closer to the public release of our protocol and our consumer app, the concern arises of protecting the core team and the project itself from potential pressures or attempts to damage the project.
Our general idea is to gradually decentralize the project so that critical processes (such as the release process) are controlled by a large community rather than a small number of people. Obviously, being open source provides some guarantee that if the core team is incapacitated, anyone can take over the code and keep on delivering new versions. But we sense that it’s not enough, and that a further level of decentralization might better protect Berty, using a combination of decentralized tech and decentralized governance mechanisms.
One essential element of this “decentralize to protect” strategy is a decentralized infrastructure for governance and organizational processes, hence this post and our interest in Aragon. We would like to understand better how we could use Aragon to that end in the future, not only for voting on releases but also for managing groups of stakeholders, triggering code building and automating other off-chain operations, leveraging a decentralized court, or at a later stage managing a fund for bounties.
Defining conditions like “unlock release voting only after the positive audit” is not possible at the moment, but in the near future Aragon Agreements could be used to contest actions that violate the pre-agreed release sequence.
I haven’t used decentralized cloud computing platforms myself but in theory you can submit tasks to these systems using the Agent app (if they run on Ethereum, like iExec do).
To represent different roles in DAO (like CTR, CCM, …) you can create a separate token for each role and then deploy their corresponding voting apps within a single DAO.
Definitely on my radar. Actually, it’s less about the bounties (as financial rewards) and more about the accept/reject features. The issues I see:
since the Projects app works with Github issues, I’m not sure whether it’s well suited for recurrent task such as an open call for audits (that might work better with Colony and we could also set up an Aragon/Colony integration, but it’s probably too complicated for users)
we would need to whitelist the people authorized to accept work. I think that it can be done through the system/permissions app, since the “Approve work submissions” is a permission of the Projects app - but do you know if the permission could be assign to a group instead of individual addresses? I’m not sure whether there is anything like a group or OU in Aragon (this is not just about Open Enterprise of course)
2. Using Aragon Agreements for unlocking voting on new releases
I like the idea, but in this specific case it’s complicated. We would need to make sure that CTRs expect a financial reward from their activity, so that they have something to stake. It seems to me a bit of an overkill.
I think that a basic business rule would do (do not let action A occurs unless data B == ‘value’), but I suppose that a custom app would be necessary. Do you know if there’s a way to define a custom data structure attached to an Aragon org so that different custom apps can use it?
The general issue I have with Agreements in our context is that as an open source project, we want to welcome unpaid contributions from anyone. If we ask some people to provide collaterals in order to let them perform some operations, then such operations will have to be limited to paid contributors only.
Do you have any thoughts about that?
3. Integrating with other platforms via the Agent
Definitely. One of the beauties of Aragon.
4. Allocating a separate token for each role
Sounds simple and easy to put in place.
In the “core processes” doc, we made a distinction between two types of council members. We could allocate them only one type of tokens, and deal with the distinction off-chain . @burrrata also mentioned the “capped-voting-app” as a solution (I thought it was for enabling the same people to vote with 2+ tokens, but maybe it can be used to enable different people to participate to the same vote, with either one token or the other), so that’s another option investigate.
I think it’s really nice to be able to allow people to submit proposals (either to accept work, or to propose it) without having to stake or have collateral. The dream would be to be able to onboard a user who doesn’t have crypto at all and have their first interaction be with a DAO earning some crypto and never have to touch an exchange.
I think you may the conviction voting app may work well in this situation and its coming along really well (can show you the demo on rinkeby). The general idea from would be for anyone to be able to submit proposals by default, but allow those proposals to be disputed.
Additionally, since proposals are open and don’t require an upfront stake, it would be good to be able to ban users (from submitting proposals) if they abuse that privilege–this is a bit challenging because users could just create a new account, but in general the user will have some social capital at stake and it may also be reasonable to use something like BrightID to make it more difficult to simply create additional accounts to avoid the ban.
This how I’m thinking about using agreements for community moderation in the gardens template, but I think it may be useful in your situation as well.
The solutions for group permissions seem straightforward
Also, thanks for the idea of using the Forwarder. I need to dig into it to learn more about it.
Regarding the Agreement, my understanding is the reason of having a collateral is to make sure that people are incentivized to act according to the agreement, otherwise their stake is slashed. So if the DAO is paying, there’s no more incentive to be compliant to the agreement.
I think that the initial case for using Agreements that Kirill mentioned got eventually lost
The suggested process is:
the release branch is successfully audited
an authorized member of the core team triggers the vote by the Council
We don’t want to automatically trigger the vote as the result of a successful audit (more audits may be in progress or needed). Hence the manual step of having an authorized core team member starting the vote (I think there was actually some sort of similar manual step in the former AGP).
So the original need was just to have a pre-condition for this manual step (checking the state of existing audits on the submitted branch, and making sure there was at least one successful audit and no blocking one).
Now, there’s the case of a core team member going nut and spamming the council with multiple votes. But even in this case, I can’t see why Agreements should be used. The core team member would just be revoked by other members.
Talking about revocation, @burrrata mentioned to me (not in the forum) that votes are only based on percentage, whereas my document was referring to a multisig-like scheme (at least X signatures). That’s the system we were considering as well for onboarding new members, using a web of trust approach. Do you know if there’s another way to do that?