NB: Here is the first high-level description of Berty DAO Core Processes for managing the release process. Since it's an initial take and there's not much community response yet, I made a single issue to cover the whole meta-process. In the future, we might split it in different issues, one for each set of operations.
1. Product Development
Collaborative development of Berty software is done with whichever tools and organizational processes the team deems appropriate.
Since the project is open source, anyone can access the code and submit a pull request. Members of the core team are in charge of merging pull requests or granting the permission to do so to others.
Some core team members, shown in a darker color in the figure, have the additional privilege of to act on behalf of the core team and interact as such with the broader community through the DAO. We call them Core Team Representatives (CTR) here.
2. Auditing Release Candidate
The release cycle requires at least one successful code audit to be successfully performed in order to be initiated.
CTR submits a version of the software to the DAO and calls for an audit.
Audit teams are invited to review the code and perform the audit. Their reports are shared either publicly or with the core team only, depending on ad hoc arrangements.
A limited number of selected ‘official’ auditors are entitled to submit their report as part of the release process.
NB: Since audit findings may block or slow down the release process, it is necessary to ensure that fake or spammy reports are discouraged or prevented. We suggest doing it by whilte-listing auditors. We may also consider a more permissionless approach if funds are available to reward the audit work. We could then require auditors to stake funds in order to have their report taken into account. A fake report would result in the slashing of the auditor’s funds, with a possible recourse through a decentralized court.
There are three possible statuses associated to an official audit report: “GO”, “GO with warnings”, “NO GO”. When an auditor provides a new version of their report for the same release candidate, the latest status overrides the previous one.
The release cycle cannot move forward as long as there is an active “NO GO” status assigned to the release candidate. In order to move on, either the auditor needs to overrides the status with a “GO” or a “GO with warnings”, or the audit team that issued a “NO GO” has to be deactivated.
The release cycle cannot move forward unless at least one report issued a “GO” or “GO with warnings” status.
Results of official audits are public. Auditors' public keys and audit statuses are associated with the cryptographic id of the release. Audit detailed reports are made permanently available on a decentralized storage infrastructure.
3. Voting Release
Once a release candidate has been positively audited, any CTR can submit its code and the associated audit reports to the Council for final review and approval.
We expect that most of the conversations related to an upcoming release happen off-chain and over the time, rather than in a voting period. The vote should be seen as a final ratification event whose purpose is to create transparency and trust within the community.
There are two colleges of voters in the Council: activists (“freedom fighters”) and technologists (“experts in cryptography, communication and privacy tech”). We suggest the following parameters for the vote:
Minimum of 50% turnout in both colleges
Approval threshold of 50% in both colleges
Voting period: one week
The suggested turnout requirement is demanding. Indeed, we believe that the credibility of the political decentralization process relies on a significant involvement of the Council members. If we fail to hit the threshold, we recommend making changes to the Council membership rather than lowering the bar or opting for a “pass by default” policy.
The vote is not secret. Voters’ public keys and ballot values are associated with the cryptographic id of the release.
4. Build & Deploy
Once a release candidate is approved (i.e. submitted by a CTR, positively reviewed by an official auditor, not negatively reviewed by an official auditor, and approved by the Council), any CTR can trigger the final step leading to the availability of the release.
Building and delivering the release should be done in a way that is as automated and as secure as possible.
The history of events that led to the release should be embedded in the final delivery, both in clear in the source code, and as a cryptographic audit trail. Builds should be produced using decentralized computing systems, such as iExec or DFINITY. Both the source code and app binaries should be made available on a public, censorship-resistant, decentralized infrastructure.
Since publishing mobile apps on centralized app stores requires to trust the person in charge of submitting the app through the store administration console, we suggest to entrust the operation to CTRs only, and have them adding their public key in the audit log so that the release can be linked to the submitter identity and can be publicly verified.
5. Granting and revoking DAO memberships
Council Members (CCM)
During the inception stage, CTRs can elect new Council members (CCM), both activists (CCM/A) and technologists (CCM/T)
Once the Council reaches its quorum (we suggest 5 CCM/T and 5 CCM/A), CTRs are no longer voting new Council members, although they can still veto new memberships
Anyone is welcome to submit a proposal for being admitted as Council members
CCM candidates must be sponsored by at least one CCM (or CTR during the inception stage) in order to open the member admission process
Becoming a new member requires 3 endorsements by existing members of the same college (or CTRs during the inception stage)
The admission period lasts at least 48 hours after the initial sponsorship; during this period, new members can be vetoed by at least two other CCMs or CTRs
CCMs can be revoked by a vote triggered by any CCM or CTR
Revocation of a CCM is voted by CCMs only (except during the inception stage, when CTRs can also vote) requires 10% turnout and 50% majority
An individual can be both a CTR and a CCM, although combining both roles should be avoided when the Council gets big enough, as it defeats the very purpose of decentralization, which is to protect the development team
Any CCM can exit membership at any time; reinstating a member requires to go through the whole process again, as for a brand new member
When a CCM doesn’t participate to two subsequent votes on new releases, he/she can be revoked by at least two CCMs or CTRs (without requiring a vote)
Core Team Representatives (CTR)
The initial CTRs are founders and initial key contributors of the Berty project: Manfred Touron, XX, YY
During the inception stage, CTRs can add new CTRs
During the inception stage, candidates must be endorsed by at least two CTRs in order to become CTRs
Past the inception stage, candidates must be sponsored by one CTR or one CCM/T, and then endorsed by at least two other CTRs or CCM/T in order to become CTRs
CTRs can be revoked by three CTRs or CCM/T
Revoked CTRs can appeal to a decentralized court which will have the final say
Official Auditors
Auditors can be granted the ‘official’ status by at least two CTRs or CCM/T
Revocation of auditors can be initiated on the basis of a set of predefined grounds
Official auditors can be revoked by at least two CTRs or CCM/T, but any CTR or CCM/T can veto this decision
If a revocation is vetoed, the auditor or any CTR or CCM can appeal to a decentralized court which will have the final say
NB: Here is the first high-level description of Berty DAO Core Processes for managing the release process. Since it's an initial take and there's not much community response yet, I made a single issue to cover the whole meta-process. In the future, we might split it in different issues, one for each set of operations.
1. Product Development
Collaborative development of Berty software is done with whichever tools and organizational processes the team deems appropriate.
Since the project is open source, anyone can access the code and submit a pull request. Members of the core team are in charge of merging pull requests or granting the permission to do so to others.
Some core team members, shown in a darker color in the figure, have the additional privilege of to act on behalf of the core team and interact as such with the broader community through the DAO. We call them Core Team Representatives (CTR) here.
2. Auditing Release Candidate
The release cycle requires at least one successful code audit to be successfully performed in order to be initiated.
CTR submits a version of the software to the DAO and calls for an audit.
Audit teams are invited to review the code and perform the audit. Their reports are shared either publicly or with the core team only, depending on ad hoc arrangements.
A limited number of selected ‘official’ auditors are entitled to submit their report as part of the release process.
NB: Since audit findings may block or slow down the release process, it is necessary to ensure that fake or spammy reports are discouraged or prevented. We suggest doing it by whilte-listing auditors. We may also consider a more permissionless approach if funds are available to reward the audit work. We could then require auditors to stake funds in order to have their report taken into account. A fake report would result in the slashing of the auditor’s funds, with a possible recourse through a decentralized court.
There are three possible statuses associated to an official audit report: “GO”, “GO with warnings”, “NO GO”. When an auditor provides a new version of their report for the same release candidate, the latest status overrides the previous one.
The release cycle cannot move forward as long as there is an active “NO GO” status assigned to the release candidate. In order to move on, either the auditor needs to overrides the status with a “GO” or a “GO with warnings”, or the audit team that issued a “NO GO” has to be deactivated.
The release cycle cannot move forward unless at least one report issued a “GO” or “GO with warnings” status.
Results of official audits are public. Auditors' public keys and audit statuses are associated with the cryptographic id of the release. Audit detailed reports are made permanently available on a decentralized storage infrastructure.
3. Voting Release
Once a release candidate has been positively audited, any CTR can submit its code and the associated audit reports to the Council for final review and approval.
We expect that most of the conversations related to an upcoming release happen off-chain and over the time, rather than in a voting period. The vote should be seen as a final ratification event whose purpose is to create transparency and trust within the community.
There are two colleges of voters in the Council: activists (“freedom fighters”) and technologists (“experts in cryptography, communication and privacy tech”). We suggest the following parameters for the vote:
The suggested turnout requirement is demanding. Indeed, we believe that the credibility of the political decentralization process relies on a significant involvement of the Council members. If we fail to hit the threshold, we recommend making changes to the Council membership rather than lowering the bar or opting for a “pass by default” policy.
The vote is not secret. Voters’ public keys and ballot values are associated with the cryptographic id of the release.
4. Build & Deploy
Once a release candidate is approved (i.e. submitted by a CTR, positively reviewed by an official auditor, not negatively reviewed by an official auditor, and approved by the Council), any CTR can trigger the final step leading to the availability of the release.
Building and delivering the release should be done in a way that is as automated and as secure as possible.
The history of events that led to the release should be embedded in the final delivery, both in clear in the source code, and as a cryptographic audit trail. Builds should be produced using decentralized computing systems, such as iExec or DFINITY. Both the source code and app binaries should be made available on a public, censorship-resistant, decentralized infrastructure.
Since publishing mobile apps on centralized app stores requires to trust the person in charge of submitting the app through the store administration console, we suggest to entrust the operation to CTRs only, and have them adding their public key in the audit log so that the release can be linked to the submitter identity and can be publicly verified.
5. Granting and revoking DAO memberships
Council Members (CCM)
Core Team Representatives (CTR)
Official Auditors