At Colony, we use the OKR method for setting quarterly goals and keeping our distributed team of 20 in sync and accountable. Below is our quarterly report on Q1 2019 and a look ahead at Q2 2019.
Recently we passed the important milestone of being about two weeks ™ away from being all squared away for main-net launch.
But first, a retrospective:
À tout à l’heure, Q1
Q1 was very much about refinement of our product and processes. We gave our smart contracts superpowers, created a new team, and made some big strides toward the release of our fully decentralized dapp.
Modularity FTW
From the beginning, we have known that there are many use cases for Colony, not all of which are DAOs, or even organisations in any recognizable sense. Yet, when we talk about Colony, we usually only talk about the use case detailed in the whitepaper: DAOs.
We have always intended Colony to be broadly inclusive and capable of supporting a wide variety of use cases. Our public communication has alluded to our broader mission, but we have been light on the details.
Internally, our product development processes have focused on the DAO use case. Our supposition has been that as this is the most ambitious manifestation of the Colony vision, support for other, simpler use cases would be a natural consequence of developing the more complicated thing.
If there is one thing we’ve learned through our customer discovery work, it’s that every organisation is different. They all have subtle nuances in how they want to work. It has become clear that we must be intentional and explicit in designing, building, and positioning Colony as an inclusive, coherent platform in which all types of users are treated as first class citizens. If we try to force people to adhere to a single, prescriptive organizational methodology, we will alienate them. Colony should be flexible and modular, allowing people to organize themselves in ways that make sense to them.
At the same time, there are very real practical and technical limitations about what is possible, or desirable. It is not in our interests to allow users to create colonies which won’t work well, or come at the cost of heightened security risk. Our job is to provide well thought out design choices for the most popular use cases, and sensible degrees of customisation where appropriate.
Whether you’re a musician who wants to harness the passion of your fanbase, a startup that wants to meritocratically split ownership between its founders, a thieves guild in a virtual world which needs to trustlessly manage the risk (or reward) of theft, or an Ethereum based project that wants to devolve binding on-chain governance to its token holders; Colony provides the tools you need to organize and incentivize your team, community, or contributors.
Colony should be lightweight enough for an app developer to incentivize freelance marketers to grow sales with a share of revenue, powerful enough for thousands of strangers around the world to collectively execute on an open source project, and flexible enough that the former can seamlessly evolve into the latter if that’s what makes sense.
With that in mind, two major improvements have been made to the colonyNetwork codebase. Together they create a new, more flexible, modular core upon which the future of the firm will be built.
Modular Payments
In earlier versions of the network, the only mechanism by which a colony’s funds could be transferred to a recipient address, was the method. The task is a richly featured mechanism for a colony to make payments to its members. It makes specific consideration of negotiating and compensating discrete units of work in low trust, pseudonymous contexts. Given the rich functionality contained within the task, we anticipated that clever frontend trickery would be make it possible to hide most of this workflow behind a shiny UI in simpler, or more trustful contexts.
We realized however, that in order to provide the flexibility we envisaged, it was necessary to be more intentional in our protocol design. The solution was to flip the script and build more powerful functionality out of simple modules, instead of abstracting simpler functionality from a more monolithic contract. Consequently, colonyNetwork now includes the all new slim and sylphlike payment method.
payment contains just the bare bones required to send funds from a colony to an external address. Features like the funds for a payment being escrowed, and release of the payment being subject to performance review, may be "plugged in" using smart contract extensions to create more sophisticated capabilities.
In the spirit of Reid Hoffman, we’re launching our dapp’s mainnet beta with just the bare bones payment plugged into an extension that bundles all its four required transactions into a single click. That requires a colony's members to fully trust the admins of the colony they're contributing to, but based on our customer discovery work, this minimal functionality appears to be sufficient to enable experimentation in a small subset of use cases.
Modular Permissions
The big tl;dr is that we are adding support for a number of permission classes at the domain level. Each permission class captures some related and complementary bundle of functionality. Here are the following permissions, each granted to an account for a particular domain in the Colony.
Funding 💰
- Able to move funds within arbitrary pots in the domain.
Administration 👔
- Able to manipulate payments (tasks) in their domain.
- Able to raise disputes.
Arbitration ⚖️
- Able to resolve disputes in their domain (i.e. change arbitrary state).
- Able to set the escrow period.
Architecture 🏗
- Able to create subdomains.
- Able to manage permissions in subdomains (but not the domain itself).
Root 🌳
- Modify Colony-wide parameters.
- Upgrade the Colony.
- Manage permissions in root domain.
This division was meant to strike a balance between flexibility and structure. By grouping sets of related functionality into “permission classes” we make permissions more intuitive and fun to approach. These few permission classes allow for a wide range of behaviors, using modules to provide mediating layers between users and the underlying permissions.
We envision that the contracts maintain a list of addresses that have the permission in question, and that every address in that list has the full permission; no additional restrictions exist at the protocol level. However, if that address refers to a contract, then that contract can define internal rules through which it takes those actions and thus mediate between the human and the colony.
For example, every Administrator has the ability to raise disputes, but there could be a contract that will only raise disputes on behalf of a user who supplies a stake and a reputation proof. If a permission is assigned to a “multi-sig” type contract, it would only take the actions if the majority requirements are met. If the permission is assigned to an ordinary account, the owner of the account can freely and without restriction take all the actions that require this permission.
Thus permissions may be held by contracts as well as accounts, and these contracts can implement arbitrary logic. For example, we expect to implement a RepFundingQueue.sol contract which performs reputation-weighted funding as described in the Colony Whitepaper Section 8.2. A Colony can give this account Funding permissions in the root domain and provide exactly the funding functionality described in the Whitepaper.
Alternatively, a Colony could implement a FundingMultisig.sol contract, assign a number of accounts to this multisig, and incorporate logic around periodic transfer limits. In this case, individual accounts could allocate up to X tokens per period unilaterally, and propose larger transfers conditional on some vote of the accounts.
Alternatively, a Colony could grant an individual user address full Funding permissions in a subdomain and allow this user autonomy with the funds allocated to that domain, conditional on funding being distributed via other mechanisms higher up the domain tree (perhaps using a BudgetBox).
In the case of the Administration permission, we could abstract the Payment creation behind a reputation/stake anti-spam mechanism as described in the Whitepaper. Alternatively, a Colony which preferred a concept of discrete “membership” could assign all members the Administration permission to enable them to manage payments with less friction.
The Architecture, Arbitration, and Root permissions are more powerful and we expect they will be assigned to a small number of trusted accounts, or to contracts which implement additional logic (such as a RepDispute.sol which implements the dispute functionality described in the WP Section 9). A Colony wishing to go "full rep" would assign these permissions to contracts implementing the appropriate decision-making mechanisms.
The idea here is that by dividing up permissions in this way, various roles will be able to “check and balance” each other. For example, accounts with the Administration permission can scope out and manage work, but will not be able to get anything done without support of an account with the Funding permission. Multiple permissions may be assigned to the same account. If I want to start a Colony and run things unilaterally, I can just give myself all the permissions. The Power is Yours (until you assign it to a reputation-weighted voting contract).
When you create your own colony, tell us (@DevRel) how you set up your domains/permissions!
“Look ma, no server!”
Okay, so we missed our first launch estimate. After re-grouping, drinking a few hundred strong cups of coffee/tea, we re-assessed exactly what needs to be done, and how long each issue will take.
After the last sprint meeting, the consensus from #dev is that things are now humming along with the dapp and the light is visible at the end of the tunnel.
“‘Things’? What ‘ things ‘? What have you all been doing? When can I try the dapp? WAI U NO MOON?” you might be wondering.
Here are some highlights from the dapp team:
OrbitDB gets some features
OrbitDB is our chosen solution to square a circular problem: We need to keep a store of a lot of different types of user data, and in order to qualify as being ‘fully decentralized’, that data has to exist and remain available on a distributed network.
OrbitDB allows us to have database-like records kept on IPFS, eliminating the need for any server-client architecture.
Our boy in Brazil, Thiago, has been crushing it with the colony fork of OrbitDB. So much so, that they’ve merged some of his work into their main (open source) repo. Yaaaaaay cross-team collaboration!
To learn more about OrbitDB check out their GitHub.
Wiring
Any changes made to the colonyNetwork have cascading effects upwards through the Colony stack. Any new methods or workflows need to be reflected in colonyJS, which affects how the buttons and components built into the dapp do their thing.
This work is largely referred to by the dapp team as “wiring”- it’s not particularly challenging in theory, but in practice wiring dapp components has been and will continue to be the big main push for the dapp team.
Now that all the final changes to the colonyNetwork have been merged, the total amount of wiring is finite and known, which means all it needs now is a little bit of elbow grease.
One fully decentralized dapp, comin’ right up.
User testing is a core part of our design process at Colony. It helps us make the correct product decisions and find usability issues before we even launch our product. This quarter we were able to test our user onboarding and find some crucial user experience improvements.
Now our onboarding has a heavier emphasis on creating your first colony, setting up an internal token, and funding your colony to start creating payments. We’ve also added an invite link to invite your community to start contributing to your project. We found that these improvements made it much quicker for users to set up their colony and start getting real work done.
Introducing DevRel
At Colony, we constantly work to improve and refine our organizational processes. It both helps inform what we’re building, and ensures our internal communications and project management remain lean and focused.
Q1 saw the emergence of a new domain by the name of #DevRel (or, “Developer Relations” for those of you not hip to the lingo of Silicon Valley) in the Collectively Intelligent Ltd. colony- Yes, this is a thing, and it’s pretty important to us, as well as many other startups in the Ethereum Ecosystem.
DevRel’s remit is to enable a good developer experience, and to foster and support a good developer community.
So, if you have questions about the docs, a project that you might be considering using colony to build, or just ran into an infuriating error message when trying to integrate colonyJS with your existing project, these are the people to talk to:
Auryn — @auryn_macmillan
As always, the best place for developers to hang out is build.colony.io, our Discourse instance. Come post your questions, project ideas, or feature requests!
We went to some events!
Paris (EthCC + ETHParis)
A few of the team made it out for Paris blockchain week, which was the marriage of a stimulating and engaging conference and a really cool hackathon.
@gichiba (Griffin) led a workshop (no video :/), and @kronosapiens (Daniel) gave a talk:
Oh, and if you’re into this sort of thing, there was also episode #3 of the Griff Riff — a recurring live-cast from all the Griffs in crypto: Griff Green, Austin Griffith, and me (Griffin).
RadicalXChange
Two of the Colony team members ventured outside of the blockchain space for a weekend to attend the inaugural RadicalxChange conference in Detroit, Michigan. @kronosapiens split sides and opened minds with his BudgetBox presentation, while @auryn_macmillan meandered around shaking hands and soaking up content. Both left the conference invigorated by the richness of diversity, ideas, and action plans geared towards creating a better world; faith in humanity at least partially restored.
Game on, Q2
Well, we’re ready. This is going to be the quarter for Colony.
Bug Bounty Redux
One of the more important pieces of prep for launch is the re-invigoration of our Bug Bounty Program.
The “staging” version of the colonyNetwork mainnet release will be on Rinkeby this week.
Any bugs found on this deployment will be rewarded handsomely — because any bug found within the next 2 weeks (TM) is a bug prevented from going to main-net.
The same rules still apply, but we implore you, solidity developers, spend a day attacking the Rinkeby deployment!
docs.colony.io/colonynetwork/bug-bounty-program-overview/
Dapp Testing
A handful of teams and projects is much easier to learn from than a vast sea of anonymous users.
Also, it’s exceptionally hard to get the normal user feedback tools like hotjar to run in a decentralized context.
So, we’ll be opening up Colony Contribute to the largest group of beta testers that we can reasonably learn from (read: only a hand-full of teams/projects who have promised to give us great feedback).
If you really, really want to be part of this group, send a message to Auryn. But be advised that there’s a good chance he’ll need to give you the cold shoulder; don’t take it personally.
Colony builds tools for organizing and incentivizing teams, communities, and contributors. Join the discussion on Discourse, follow us on Twitter, sign up for (occasional) email updates, or if you’re feeling old-skool, drop us an email.
Originally published at https://blog.colony.io on April 29, 2019.
