Decentralize to protect: a DAO for Berty #72
Comments
|
Thank you for introducing this topic for the community! |
|
Thank you guys for these insights: I dig this! Here are a few of my views on "The What": The What —> the scope of the proposition should we aim as well for financial independence, through some sort of crowdfunding and decentralized treasury management? A big yes! Especially in the germ. Today Berty's core development team is relying upon very few patrons' money (one? :)). Since the business model is not yet defined, the company's vision might not even choose one. What would happen if this generous patron decides to stop financing the Berty project because he receives pressures from his government? Will it be the end of the adventure? Berty's mobile application & protocol development decentralization, pass-through a decentralized funding process. It's particularly true in the debut until the developer community has not reached a critical size. How should this crowdfunding be implemented? I am sure @PhilH , will guide the team through it excellently ;) should we focus on the release process of the mobile apps rather than on the underlying protocol? My intuition tells me that the Mobile App will strive for a more significant technical and non-technical community in the debut than the core protocol. Hence, I feel that Berty is answering a massive problem here: how can people communicate with their peers in complete freedom? Therefore, if the UX meets expectations, Berty's Mobile App can swiftly gather more developers around the project developers will use daily than "another P2P protocol". Sorry for sounding foolish, but how many Open-Source P2P protocols can you find on Github? A lot. How many of them remain unknown? A lot and often decorrelated from their purpose & code quality. In the inception, what will make Berty protocol visible from other developers to use it? A widely use Mobile App that runs on it: Berty Mobile App :) at this point we focus on the release process rather than using a DAO for building the code (like for instance, granting repo permissions to devs) - is that right?
Being one of your top fans, I hope I could play with the Berty Mobile App beta soon! |
|
@Lalolo13 Thanks a lot for your comments!
Definitely interesting to see such an enthusiastic support of a crowdfunding option :)
As a reminder, Berty is a non-profit. There's no business model right now. Both the protocol and the app will be delivered and used for free. Since the tech is fully p2p, there's no real need for a server infrastructure that would be both a cost and an opportunity to create a business model. In the future, apps (other than the reference implementation of the mobile, consumer chat app) might use the protocol AND have a business model, but there's no plan to offer paying licenses to developers of such apps at this stage. Hence if crowdfunding and treasury management are to be added to the DAO, it will be either because of a public good funding approach (see Common Stack), or as the consequence of a change regarding this non-commercial policy (unlikely).
I shouldn't speak for him but I understand this is also the opinion of @moul (for slightly different reasons, but it amounts to the same result). I still have mixed feelings about this point. At the end of the day, the protocol might be immensely more valuable than a single app. But it's good to get different views, so thank you! 🙏 |
Licenses only protect freedom of the code if(!) all players play by the rules. There is no protection for involved persons to expect - contributors or users. A simple law can even override the constitution and get the parliament out of the way - a situation which we have right now in Germany, so it's in no way theoretical. To summarise: A license gives you no protection when one party plays against the rules. |
|
Hello guys ✌️ Here are my thoughts:
I think you rely only the actual team to provide the software, it's not really a good way. You still have a "post-it" on your face with
Maybe when your work implies public stuff, you can (that's a drastic idea though) develop under generated accounts without your personal data linked to it. Like creating a random GitHub account, etc.
For "good people" and "good systems" (I did write on purpose these words so no{one/thing} is targeted 🙂), its sufficient as a license will bring some complexity to attack some{one/thing}.
I think so. For now, the concept and the "big goal" of the project is inside your heads and not in communities's heads. Once the project is big or mature enough, it'd be time to switch IMO. A cool feature/idea for a long term DAO, would be to rely on servers having a copy of the repository hosted on. For example, I have a git server (Gitea), I can create a copy of it in it without having to listed as fork, so if some{one/thing} want to shutdown the project on GitHub, you could rely on it to continue develop and releases. |
We've been thinking about ways to protect Berty as a whole: not only people's communications secured by our protocol, not only the code itself, but also the very people in charge of building it. A holistic approach of security should take into account social and political vectors of attacks as well as tech security.
Here are our first thoughts. We would love to get inputs and comments from the community! Eventually, a DAO for Berty would amount to granting it with more power over the project, hence it would be good to "DAOify" Berty with your help from the onset :)
Berty’s mission is to create a 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 the Democratic Tsunami application from its servers; Uniswap blocks 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
The goal is to enable the community to operate the release of new versions of Berty's software, especially the release of versions of the end-user application. In the event of the core team being incapacitated to release, or pressured to alter the code in a way that would be detrimental to the privacy or the security of its users, the community would be able to step up and solve the situation. Eventually, the DAO-powered community may own the process, with core team(s) being seen as providers to the DAO.
Release cycle process
Notes:
Actors
Notes:
Compared to the usual way to manage and release a software product, the council is the new element here. Its purpose is to protect both the apps and the core team by owning key decisions regarding Berty's software. While a core team is made up of a small number of individuals that can be identified and targeted by hostile forces, the council can be broader and has no operational responsibilities. It acts as a decentralized group of people that can be trusted to decide what's best for the project and its users, because it can hardly collude and has no interest to do so, and it's globally spread so that it escapes local attempts of censoring or pressuring its members.
We are considering both recognized tech experts and freedom fighters as members of the council.
DAO Processes
Technical decentralization
The goal of technical decentralization is to automate to the fullest extent the decisions made by the DAO, especially regarding code releases. We need to make sure that decentralized decisions can be actually enforced and protected from censorship and tampering by a state or a large technology company.
Components
Radicle/Pando/ditCraft: decentralizing VCS
Notes:
Automation of the release process using decentralized technology seems doable, except with one critical step: mobile app store submission. It's not surprising, since app stores are themselves centralized. On Android, an app can be made available independently of Google Play, but it's not possible on iOS. We might have to live with this single point of failure for now, and ultimately rely on parallel implementations and submissions to reduce the attack surface.
What now?
This is a call for inputs from the community. If you have opinions, questions, comments, suggestions, we want to hear from you!
We would be especially grateful to collect inputs on:
The Why —> the relevance of the proposition
The What —> the scope of the proposition
The How —> methods and tools
The questions above are just examples. We are looking forward to any feedback of yours :)
The text was updated successfully, but these errors were encountered: