# dBerty - decentralize to protect
*This document is a preliminary scoping exercise regarding the protection of Berty using a DAO and other decentralized technologies. Some considerations were also made regarding the use of a DAO and tokens to support the adoption of Berty protocol; however, they are not included here.
(EN) Version 1.0 Feb 27, 2020 - by PhilH*

[Berty](https://berty.tech)'s mission is to create a [protocol](https://berty.tech/docs/protocol/) and applications enabling secure p2p communication between people, including in hostile political situations.

The provision of such tools contravenes the interests and policies of entities wishing to control communication between people for any reason: fight against crime and terrorism, control or eradication of political opposition, policy of mass surveillance, monetization of personal data, etc.

Consequently, it is to be expected that some of these entities will attempt to destroy, censor or take control of the tools offered by Berty (recent examples: following the request of the Spanish government, [Github removes](https://euobserver.com/news/146540) the Democratic Tsunami application from its servers; [Uniswap blocks](https://thedefiant.substack.com/p/uniswap-website-geo-ban-cant-stop-370) access to its application to navigation from a dozen countries, probably following pressure from the US government).

As open source code, the protocol itself and the applications provide a base level of resilience, since anyone can check the code and fork it. But effective protection must extend not only to these technical objects, but to the means of producing and disseminating them, as well as to the key people who make them available to the public.

We posit that such protection would be more effective when relying on decentralization and transparency, rather than on hiding and secrecy. Decentralization is understood here both at the level of the technical infrastructure and in terms of the organizational processes ruling maintenance and release activities.

A decentralized infrastructure ensures the integrity and the availability of storage services (for example, the source code of the protocol) and computing services (for example, the build of a mobile application), by avoiding single points of failure - we use the term *technical decentralization* in the rest of this note to refer to such services.

Organizational decentralization deters attempts to attack a small team in charge of maintenance and release activities, by leveraging a much larger, open group of people, and allowing anonymity - we use the term *political decentralization* to designate such organizational mechanics.

## Political decentralization

### Release cycle process
- code submission (release candidate, not PR)
- pre-validation period (code audit)
- deliberation period
- voting process
- release
- independent verification

_Notes from Feb 12 meeting with Berty team_
- _keeping things agile: merging PRs is done by the core team or anyone who gets the permission from the core team (permissioning doesn't need to be formal)_
- _Need to distinguish between frequent routine upgrades, urgent fixes, and major upgrades_
- _Need to run the code review process in a somewhat async mode_

### Actors
- core team
- council (tech experts + freedom fighters)
- review teams
- users
- root key holders (in case of gradual decentralization)

### DAO Processes
- RC submitted by core team
- review/audit teams appointed by council
- actual release voted by council
- automated build and deployment triggered by votes
- core team/council membership controlled by web of trust + on-chain voting
## Technical decentralization
### Components
- IPFS: decentralizing data storage: source code, builds, documentation, Web site
- Pando/Radicle/ditCraft: decentralizing VCS
- ENS: decentralizing domains: berty.eth (reserved)
- Decentralized courts: delegating operational authority for routine/urgent fixes (Aragon Agreement+Court, Kleros)
- Public blockchain (Ethereum, Tezos, Bitcoin...) : decentralized authentication: signing releases, audits...
- Public blockchain II: smart contracts for voting, onboarding members, etc (DAO)
- Public blockchain III (or other distributed computing method): decentralized control over off-chain processing such as building executables (iExec, Golem)

_Notes from Feb 12 meeting with Berty team_
- _Access to Apple Store and Google Play accounts remain SPOF, as far as we can tell - any workaround?_

## Next steps
- collecting comments/inputs from SME at EthCC
- writing a more detailed brief as a result
- working session with Berty