The genesis of a fully distributed VCS
Since Microsoft bought GitHub, the concern of developers all around the world is vibrant. The purchase of this source code hosting platform for the modest sum of $ 7.5 billion has caught most of them off guard. Though the giant is trying to reassure them, we must admit that the interest of this open workspace is strongly thwarted.
Happily, history is a tricky process. While Microsoft was silently negotiating the acquisition of GitHub, we were already working on the development of a fully-distributed alternative to its platform, based on IPFS, aragonOS and the ethereum blockchain: pando.
Pando is still in its very early days but you can already have a look at its monorepo and
npm install -g @pando/cli to play with it. That’s just the beginning, though. Thanks to a generous grant from the amazing Aragon Nest program, pando will gradually emerge from the shadows in the coming months.
What is pando?
Pando is a fully distributed and immutable VCS based on top of IPFS, aragonOS and the ethereum blockchain. It is actually developed by the Ryhope Network’s team but intends to become a community-driven standard — yes: we’re working on developer’s documentation, folks! Its goal is to provide content creators, and mostly software developers, with a universal open-source versioning, cooperation and archiving layer.
Pando has been crafted with the intent to be faithful to git’s philosophy while creating a bridge towards blockchain’s and ethereum’s rationale: a common good providing one more brick towards the decentralization of societies and the empowerment of human beings. That’s why we are building pando as an open source and standalone tool. No token, no ICO: just a medium to provide the blockchain community with a way to self-organize its development and its growth — though the Ryhope Network will use an homemade token to offer an income to free and open contents: more on that later.
Why « pando » ?
In Latin, pando means « I spread out ». It also happens to be the name of the earth’s oldest and largest living organism: a forest of quaking aspens located in south-central Utah. Indeed, this forest has a weird characteristic: it has been determined to be a single living organism cloning itself since 80.000 years.
We did choose that name because we believe cloning and forking are the best way for a DAO to find its path toward sustainability: leveraging the best of a project, spreading its advantages and perfecting its gaps for the common interest of all and not for the individual interest of a few is, for many of us, the future that blockchain technologies urges us to experiment now.
The goal of pando is to provide a common workspace for the crypto-space to experiment new modes of organization and collaboration. That’s why we need pando to enforce some shared patterns while simultaneously offering the modularity one needs to experiment with various governance scheme. That’s why we designed pando upon the following principles.
Pando implements a fully distributed architecture. Each repository’s files and data are stored and replicated over IPFS while its governance scheme are enforced through a set of smart-contracts safely stored and executed on the ethereum blockchain. This architecture guarantees that contents maintained through pando are uncensorable and can survive most infrastructure breakdowns.
Pando guarantees content and governance immutability through the coupling of IPFS and the ethereum blockchain. It insures a timeless archiving of each project’s versions and thus that the contents maintained through pando are uncensorable even by their own authors. This features make pando unique in the field of VCS and, probably, not suited to all needs. This is why pando does not intend to replace existing VCS such as git, but to serve as the foundation of new collaborative experiments, next to the existing ones.
We believe that there exist no governance model suited to all needs: it all depends on the scale, the temporalities and the goals of one’s project. This is why pando has been designed to offer as much modularity as possible regarding the governance schemes or tokens-related policies it enforces. Happily, the flexibility and power of the aragonOS framework allow us to keep pando as agnostic and generic as possible when it comes to these features.
The core idea of pando is to turn every repository into an aragonOS-based DAO. Obviously, one can not store all of a repository’s contents and data onto the ethereum blockchain: because of the gas costs, this would make the use of pando way too expensive. That’s why pando heavily rely on IPFS as its storage layer.
How does that work ? Each pando’s
commit is described as a linked-data structure pointing to its parent
commits and to another linked-data structure describing the state of its current working directory tree. This
commit data structure is furthermore filled with various metadata such as the ethereum account of its author, a timestamp, etc.
Thanks to this data structure, the last
commit of a pando repository works as the root of a merkle-like Directed Acyclic Graph - DAG - describing its whole history. The structure of this graph enables anyone to traverse a project’s whole history by recursively resolving the merle links of its root
commit data structure.
This data structure enables pando to provide the security of the ethereum blockchain to the whole history graph of a repository in a very cost-effective manner. Indeed, IPFS content-addressing system relies on the hash of the data it identifies. Consequently, any change in any node of a repository’s history graph would modify the CID of this node, and thus the CIDs of all its parents up to the root
commitdata structure of this repository. As such, enforcing access control over the whole history of a pando repository simply means: enforcing access control over the on-chain stored CID of its root
commit data structure.
What does pando brings to the VCS field?
Pando’s workflow and commands have been designed to endorse git’s well known ones. Pando is not git, though. Its natively unfalsifiable and uncensorable history makes pando an unstoppable protocol whose use cases may go far beyond what git already offers.
Immutability is an important part of what pando is: every version, commit, fork, etc. of a pando-based repository are engraved in stone forever. No one can censor it, delete it nor modify it. For that reason, pando has the power to become a universal archiving system.
The whole point of pando is to enable repositories to be controlled by DAOs. For now, the
npm pando package comes only with a classical governance model: one can own push rights or not over a given repository. While this may be useful for projects which need to move pretty fast, this governance scheme is still quite centralized: it relies on the existence and the good will of a few « maintainers ». That’s why we are currently working on providing more sophisticated governance kits for pando DAOs. Happily, the aragonOS framework makes it quite straightforward.
The governance scheme we are currently working on, for instance, will be entirely decentralized. It will allow each contributor to earn authorship / authority tokens on the repository thanks to her actual contributions. Let’s make it clear: the purpose of these authorship / authority tokens is not to be sold on secondary markets. Actually, these tokens won’t even be transferrable. They will simply grant contributors the ability to decide on which contribution to merge, which authorship / authority share to grant to its author, etc. Eventually, these authorship / authority tokens will allow for a DAO-wide governance scheme based on the actual contributions of its shareholders.
We expect this governance kit to enable exclusive organizational and economic models. Let’s imagine: if a given repository gains income, it could automatically split it between all its contributors according to their respective authorship share. Actually, the Ryhope Network’s team is already working on the implementation of a custom crypto-primitive to provide a sustainable income to Open Source Software — more on that soon :) Actually, we could even go further: imagine two repositories setting a partnership to let their respective authority tokens flow from repository on to another. Or a repository setting a parameter to fix the authorship share it claims over its forks. The possibilities are endless.
What’s coming next
We still have a lot of work to do to harden pando’s codebase. The next release should come up with some refactoring, a LOT of optimization and the integration of Frame’s OS-level key manager and signing system. Most of all, we’re gonna work hard to release our contribution-based governance scheme as soon as possible.
Pando does not intend to be a tool of our own, though, but a forest growing and spreading for decades, sending nutrients and informations to its succession, growing slowly but surely. So feel free to come and check our monorepo, test pando, open issues, fork and submit pull requests.
See you soon with more news.