“What does Colony look like?”
This is a question that we get asked sometimes, and it’s tricky to answer.
Most people are used to interacting with polished interfaces that are built specifically to hide and abstract away all the complicated machinery ‘under the hood’. Good UI/UX does this exceptionally well. So well that when most people imagine what an app is, they have a user interface in mind.
A reliance on visual metaphor in software makes it quite hard to explain the concept of ‘the blockchain’ to curious newcomers. Thankfully, there are now some great creative ways to visualize a blockchain that are actually quite technically accurate. Still, there’s often very little with regards to the blockchain that you can ‘show’ so there is a large emphasis on ‘telling’.
The same difficulty happens when trying to explain Colony, and the various components of Colony, such as the Colony Network, colonyJS, and the up-coming colony dApp. Each of these components is, in some sense, a discrete project but they all are designed to fit together to create a coherent user experience. To better illustrate how it all fits together, we have an appropriate visual metaphor common in software: layers.
Layers of the Colony Stack
“The People Layer of the decentralized protocol stack” seems like fluffy marketing lingo, but it’s actually a good visual metaphor to understand how Colony fits together.
Just like the OSI model, Colony is made up of several discrete conceptual layers ‘stacked’ together.
Each layer isolates certain functions and aspects of a complete system. In the case of Colony, the system’s purpose is to enable fluid, open organizations.
User Interfaces, Integrations, Extensions, and meta-data for Colonies exist in the upper layers. These will be built by independent developers to suit the needs of their creators.
Helper tools like colonyJS allow the interactions created by dApps in the layer above to be formatted and submitted to the Etherum blockchain.
Finally, the functions inside smart contracts on the colonyNetwork handle the “consensus-relevant” information like ownership, funding, and reputation.
Using this ‘stacked’ architecture is an important design feature: It allows developers building with Colony to implement different interfaces while using the same underlying tools and smart contracts.
Changes or differences in the upper layers do not affect the operations of the lower ones, so that even if two people access Colony through two different clients, they can still participate in the same underlying network.
From Interface to Transaction
Understanding a bit about what’s going on ‘under the hood’ might help to illuminate the separate components of a complete user experience.
So let’s look at an example, using some screens from our up-coming reference client. We’ll walk through just one step in a user interaction, and show how that goes from a click inside a pretty front-end interface in the dApp layer, to a transaction submitted to the blockchain (the smart contract layer).
Below is the main page for a Colony. Here you can see most of the concepts of a colony presented visually: Domains, Skill tags, Tasks, and Reputation are all present somewhere, in a way that is (hopefully) intuitive for a user to get an overview of the colony’s recent activity.
There is one user interaction on the main page that is a bit special, because clicking it will require a transaction to be sent to the blockchain. For this reason, the “New Task” button is set apart from most other elements in the interface, and given a distinguishing color.
When a user clicks “New Task”, it’ll execute code to bring that interaction from the dApp, convert it to a transaction using colonyJS, and submit that transaction to the colonyNetwork smart contracts.
colonyJS contains a set of standard functions to interact with colonies and the Colony Network as a whole. In this case, the dApp will be using the createTask.send() method to create a new task.
When that method is called by the dApp, colonyJS will take the user’s wallet (which contains her private key) to sign the transaction, and pass it on to an endpoint adapter that communicates with the colonyNetwork contracts running on the blockchain.
Turning something like this:
const { eventData: { taskId }} = await colonyClient.createTask.send({ specificationHash, domainId: 1 });Into something like this:
var rawTx = {
nonce: '0xdb',
gasPrice: '0x060db88400',
gasLimit: '0x5208',
to: '0xf6ae4e07320d5b96019099563047ad2dc7714927',
value: '00',
data: '0xa9059cbb000000000000000000000000ed4740b26256acb73c2807638a47b965fc2dbc2300000000000000000000000000000000000000000000000000000000b2d05e00',
v: '0x1c',
r: '0x5e1d3a76fbf824220eafc8c79ad578ad2b67d01b0c2425eb1f1347e8f50882ab',
s: '0x5bd428537f05f9830e93792f90ea6a3e2d1ee84952dd96edbae9f658f831ab13'
};Once submitted, the transaction needs to be mined by the network, meaning that it has been recorded as an immutable event in the colonyNetwork smart contracts.
In the same way that a new task was created, colonyJS can query the blockchain for information with the getTask.call() method, allowing information to be brought into the interface.
Extending the Colony Protocol
Getting data from the blockchain is quick, and doesn’t require the same special steps that submitting a transaction does, so there’s no need to visually separate the ‘on-chain’ data. But there’s much more going on here than what’s ‘on-chain’.
In the task display, some of the information comes from the blockchain, but other parts might be pulled from a different source like IPFS. Colony’s dApp, in particular, will use OrbitDB for handling some of these elements, such as extra labels, chat logs, attachments, and user profile information.
An Open Network for the Future of Work
Whether it’s on the blockchain in a smart contract, stored as an asset in IPFS, or running in a user’s browser, all this software comes together to create a complete user experience. At the end of the day, that experience is the only thing that matters.
Colony’s vision is an open, decentralized network for what we believe work can become. We think that the future of work will be more than tasks and bounties.
Users will have a profile that tracks their historical contributions and reputation across skills and colonies. You’ll be able to see what someone’s worked on and what skills they’ve demonstrated. It’ll be a live, dynamic resume that represents a complete picture of all the work you care about.
Using Colony, you’ll be able to find and discover new projects that are perfect for you based on your previous activity and demonstrated skills, as well as manage what you’re working on at the moment.
We want organizations to be open, but we also want work itself to be open. That big, far reaching vision can and should influence the software that enables it, and vice versa.
Building Colony together
We’re not the only ones who will bring about the future of work, either.
Choosing to structure Colony as a ‘layered’ platform may seem hard to organize, but its a deliberate strategy: We want there to be many different ways to interact with Colony, built by independent developers from all over according to their own needs and preferences.
Colony is predicated on the idea that more can be accomplished by working together than can be done by independent parties, but doing so in a decentralized way is desirable. Enabling (and rewarding) that decentralized collaboration is our mission, and essential to a healthy ecosystem of software tools that allow for a fairer, freer future of work.
Colony is a platform for open organisations.
Follow us on Twitter, sign up for (occasional) email updates, or if you’re feeling old skool, drop us an email.
