-
Notifications
You must be signed in to change notification settings - Fork 2
Druid & The Protocol
Druid is the official implementation of the Ellcrys protocol written in Go programming language. The client allows anyone to run an Ellcrys full node, create addresses, accounts, transactions, CPU mining, start a RPC service for remote invocation of functions and many more.
In this section, I will summarize the aim and concepts of the Ellcrys protocol. Some of the concept outlined will be explained further in their own full pages.
Ellcrys aims to decentralize the ownership of software products and businesses which will enable communities start, contribute and co-own software products like web applications, mobile apps, smart contracts and revenue generating enterprises. Developers, designers and other shareholders will be able to collaborate in a trustless manner; Managing product features, membership, donations, revenue and service procurement. We hope to give people the ability to build things together while maintaining equality and eliminating mistrust.
Most people I have talked to about decentralized internet organizations and how they should work think of smart contracts working together to create a self-executing, automated system for managing an organization and all its activities. Essentially, these people see centralized execution of programs as a problem and think their elimination will provide the much needed transparency.
However, we at Ellcrys believe that the better approach is to decentralize organization ownership and management, creating organizations that are open and have flattened hierarchy. A system that is democratic in the way decisions are taken and these decisions enforced by the protocol. Teams that simply want to decentralize ownership and management without necessarily building smart contract applications may use the protocol. Teams with the need to show openness and transparency and still build simple web applications will find Ellcrys ideal.
Today, we see projects struggling to be 100% decentralized. Thriving to move from a efficient centralized technologies to decentralized, immature, buggy equivalents in name of "trustless-ness". Alternatives that will ultimately make the lives of users difficult pending till a time when blockchain scientist come up with improvements. The only justification for 100% decentralization is when the product is at risk of censorship. This is not the case for many new projects today. Instead of forcing users to commit to bad experience, we think it is best to make code open, governance/ownership decentralized and execution can be centralized or decentralized only when the component in question is at risk of censorship or tamper.
Shared owners of a project receive rewards based on their contributions. They are able to earn rewards for their efforts. These rewards can be:
- Project tokens that maybe be exchanged for other cryptocurrencies or fiat.
- Ellies
- Ephemeral equity that slowly dilutes over time
- Reputation
To enable decentralized contribution and ownership possible, we must first define what resource can be co-owned and subjected to decentralized governance. As a primarily developer platform, that resource is a git repository. Developers are accustomed to using git for collaboration, so it makes sense to stick with tools and concepts that are already familiar. The git tool is already designed for decentralized collaboration allowing developers to share source codes and collaboration without any middle-man. Developers can send git objects to themselves using emails, flash drives etc.
However, this approach is not user-friendly and that is why platforms like Github exists. They make collaboration seamless providing cloud hosting for repositories while providing access management, continuous integration and other services.
To achieve a system that allows people truly own part of a shared entity (e.g software or business), no central party can be allowed to preside over this entity. If people were to use Github, they risk being censored in the future no matter how unlikely that may be. This is the main reason why we decided against building on top of Github and instead work to create a decentralized hosting protocol.