This second milestone was quite busy.
We had the chance to introduce Pando in various meetups during ETHBerlin. The feedback was awesome. But more on that soon.
Regarding the dev side we re-organized our roadmap: we focused on re-architecturing the Pando's core smart contracts and postponed the CLI optimization to milestone 3 - the good news being: this optimization is on its way as the Pando CLI can now stage the whole react monorepo in a matter of seconds :)
It took us a lot of time to figure out what was the best architecture for the Pando app in order to
After six or seven refactorings we finally came up with an architecture we were satisfied with :)
Pando, as an aragonOS application, comes with three smart contracts: a PandoGenesis contract, a PandoLineage contract and a PandoAPI contract. All of these contract rely on a shared Pando library defining Pando's data structures and helpers to handle these datastructures.
This library defines shared data structures and a couple of helpers to handle them. The main data structures are the following.
Individuations are Pando's equivalent of git's commits. However, individuations are not commits. Why? Because commits reflect both the local state and the shared / public state a of repository. When one commit reflects changes they made to a local repository they can easily synchronize it through the git push command. In Pando, every individuation needs to be approved by an underlying DAO. This means that any individuation can be rejected and that there is no immediate identity between the local state and the shared / public state of a repository.
Lineages refers to the emission of non-transferrable token acknowledging one's belonging to the lineage tree of a repository. Lineage tokens can thus be granted to contributors for the individuation they submit, but also to dependencies, inspirations, etc.
The PandoGenesis contract handles the individuations - i.e. commits - of a repository. It keeps tracks of these individuations, maps them through their unique Individuation ID, and enforce fast-forward consistency.
The PandoLineage contract handles the issuing of Native Lineage Tokens to acknowledge the belongings of contributors and dependencies to a repository's lineage tree.
The PandoAPI contracts acts as an interface for all external interactions with the repository - and thus with the Genesis and Lineage contracts. Its purpose is to enforce the consistency of the Pando protocol state-machine.
Users do not directly individuate a repository. They create Requests For Individuation which must be sorted - accepted or reject - by the DAO.
Requests For Individuation can come bundled with Requests For Lineage. These Requests For Lineage can origin directly from the user to ask for a reward in return for their contribution, or be automatically filled by a package manager if the Request For Individuation introduces new Pando hosted / Pando addressable dependencies.
These Requests For Lineage must also be individually sorted - accepted or rejected - by the DAO. The difference is that accepted Requests For Lineages must also be valuated by the DAO: which amount of Native Lineage Token is going to be issued for this lineage's destination in case the related Request For Individuation is eventually merged.
The Pando protocol state machine makes sure the relationships between all of these requests are consistent: if a Request For Lineage is rejected by the DAO, its related Request For Individuation is automatically cancelled ; if a Request For Individuation is rejected by the DAO, its related Requests For Lineage are automatically cancelled ; a Request For Individuation can't be merged before all its Requests For Lineage are accepted; if a Request For Individuation is merged, its related Requests For Lineage are automatically issued; etc.
The PandoAPI contract makes no assumption about the governance model enforced by the DAO. Its goal is only to make sure that the core logic of the Pando protocol is enforced - and cannot be circumvented. It’s up to the community to write governance kits - mostly: enhanced voting apps - on top this API contract. Governance thus works as an additional layer on top of the PandoAPI.
Governance kits are voting apps built on top of the PandoAPI. These kits must implement the PandoKit abstract contract to comply with a minimum interface - and thus provide a minimum degree of interoperability between governance kits for the CLI. The second milestone release of Pando comes with two built-in governance kits.
Enforce a maintainer-based governance à-la GitHub.
Enforce a Native Lineage Token-backed democratic governance to sort and valuate requests.
This architecture makes the whole Pando contract ecosystem as clear as possible:
The next steps will be:
By the way: we are looking for a frontend dev. The detailled announcement is here: https://github.com/ryhope/documentation/blob/master/jobs/frontend-dev.md. Feel free to share on your channels and networks!
See you soon folks!