Open PhilH opened 4 years ago
zxxma
commented
4 years ago Thank you for introducing this topic for the community! It would be great if the community would gradually take up the topic and come up with solutions. I'll think about it and would be happy to get involved in upcoming weeks :)
Lalolo13
commented
4 years ago 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!
PhilH
commented
4 years ago @Lalolo13 Thanks a lot for your comments!
(crowdfunding and treasury management) A big yes!
Definitely interesting to see such an enthusiastic support of a crowdfunding option :)
Since the business model is not yet defined
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).
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
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! 🙏
fte378
commented
4 years ago do you think that having Berty’s code released under an open source license is enough protect the whole project and its core contributors?
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.
DataHearth
commented
3 years ago Hello guys ✌️ Just discover your project today and it seems amazing how far you're going with the decentrelize initiative!
Here are my thoughts:
is decentralized governance a good way to protect people building and maintaining the app?
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 I'm a key stone of this project write on it. That's why I think you should more rely on the community when the project will grow enough to develop, make release, bug corrections, etc.
are there other ways to make the project and the extended team protected from social and political attacks?
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. Also, you can make things even more decentralized by splitting important tasks to more people (like 5 people to releases, 5 to develop), so shutting down the project or arming people is less meaningful than targeting the Lead dev for example.
do you think that having Berty’s code released under an open source license is enough protect the whole project and its core contributors?
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}. But if you take a "bad system", it doesn't care about it and you'll mostly rely on the above thoughts to protect the project and people behind it.
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?
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. For that, I suggest some sort of private list of servers with or without credentials where the project is stored and regularly updated.
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
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 :)