System Architecture

The front end of a service system is amenable to decentralization. For example, MyEtherWallet, an open-source front-end product, can be put fully under your own control. Your wallet is yours. However, the back end has traditionally been enclosed and controlled by a service provider (their code may be open-source, but their data is not). The GDPR emerges to protect users’ data rights — it is a great legal movement, but not technically enough: You are given the option to export your data, but where do you go from there?

Our proposal is to abstract a data end out of the traditional back end, which is managed by individual users through neutral, open-access blockchain technologies. An independent data end gives control back to the users, breaks the data barrier between companies so that they can compete more fairly and effectively, and enables more innovations based on open data (BTW, see our new open AI data license, as drafted by Heather Meeker).

For a decentralized Git service, we structure the system as below.

Architecture of Drepo

Let’s examine Gogs, an open-source Git service (similar to GitLab Community Edition but more lightweight), for example, to see how it is fit into the decentralized ecosystem. A traditional service provider may deploy Gogs and store users’ data in a MySQL database managed by its administrator. Permissions of users to access and manipulate their data are granted by the Gogs server, instead of the other way around. If the Gogs server is shutdown or does anything evil, users can hardly protect themselves because their rights can be revoked at any time (unless they file a lawsuit).

We decentralize Gogs and map out the relationships in the right way. Users should rely on a permanent trustworthy public facility, such as the Ethereum blockchain, to manage their data. The management rules are coded in a predefined smart contract, which executes unstoppably in a tamper- and censorship-proof manner. The smart contract is an open agreement among all parties. Users always have the absolute, cryptographically-guaranteed right to authorize any changes to the data they own or manage, according to the smart contract.

Companies still play a major role in offering most of the traditional front-end and back-end services. Particularly, most user data only have their hash values recorded in the blockchain since the storage there is highly expensive. The data is retrievable by hash values and physically stored as files in IPFS, backed up by the service providers or the users’ personal computers. The data files are stored in an open format using JSON, but the content can be end-to-end encrypted for a private project. At the front end, a service provider has to restore the data to MySQL for Gogs, which acts as a working cache for the data end. From the users’ perspective, Gogs operates almost the same way as it did before, yet when data changes occur or accumulate to a certain amount, the corresponding data owners or managers can check a human-readable summary and sign off the changes they agree to. In the event that a service provider perishes or is guilty of misdeeds, users never lose the control of their data. They just reject or correct any anomalies and switch to another service provider (possibly themselves).

Furthermore, the smart contract can be defined in a general enough form so that the users can choose between Gogs or GitLab or even GitHub to present and manage their data. The smart contract only models and controls the core ownership and authorization logic, while data files are convertible to different platforms. We now support Gogs and hope to support GitLab in future.