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 2018 and a look ahead at Q1 2019.

Touché, Q4

These updates are written to provide a clear and honest reflection of the work that we do. Our update post has taken longer to write (it’s well into February) because this time ‘round, we’ve got a lot to reflect on.

Let’s start with the big, obvious thing: If you saw us at DevCon in Prague this year, you might have heard us say something along the lines of *“we’re working hard with a target to release before the end of the year.*

We didn’t hit that goal. So it goes*.

It's ok to fail, but only if we learn something from it. And we’ve learned quite a few things from missing our aggressive release target.

*For avoidance of doubt: Colony has not pulled a Metroid Prime 4 -- we’re not starting again from scratch or anything like that; bulding a dapp that is decentralized, distributed, and trustless end-to-end is just harder than we initially expected. The devops groundhog saw her shadow, and it’ll be at least 6 more weeks of development.

Learning #1: The off-chain world is more important than we previously estimated.

Dapps are hard. Really hard. One of the big challenges we took on with our dApp is “full” decentralization. That means no compromises. Everything in our stack, from UI components down to smart contracts must, in principle, function without relying on any component or service that’s hosted, owned, or otherwise ‘centralized’.

Not a lot of people realize what a big deal this is.

With smart contracts, in some senses we get decentralization for free. All the ‘consensus-relevant’ stuff runs on the EVM, which is as secure and decentralized as the blockchain it lives inside. Creating a secure, efficient system of smart contracts is certainly not a trivial task, but it’s only part of the whole.

There is an entire world of work to be done off the chain in the form of basic interfaces for blockchain interaction and integrations -- Robust and secure smart contracts are necessary for the success of any Ethereum project, but they are not sufficient.

Ultimately, whatever benefits a smart contract brings a user will be mediated by that user’s ability to access and manipulate the smart contracts. Dapps are meant to bridge a smart contract and a human, but right now that divide is still large.

The Ethereum developer community has been at it for a while, and there are so many brilliant efforts toward what is largely a unified goal: Mainstream adoption and acceptance by real users. But there’s still a lot of work to be done to close that gap.

UX/UI, a distributed user database, multi-signature transaction workflows -- there are a number of very fundamental interactions *off-chain* that are largely un-charted territory. If a user’s data is out there on the decentralized web (IPFS), how do we make sure it remains available and secure for that user? How do we onboard new users that might not have any Ether or be “hip to the blockchain”?

These are some of the major hurdles that we confronted last quarter, and it resulted in a lot of careful and deliberate designing, on both back and front ends. Because, as we said, this is all un-charted territory. No one has built a dapp to this standard before, and these things take time.

Learning #2: Secure the Network

Our network team might be mad at me for seemingly representing the dapp work as more important than the smart contracts. Quite the contrary!

We strive to set the bar for robust testing and best-practices when it comes to our deepest layer. The colonyNetwork contracts comprise over 6000 lines of well-tested solidity (395 tests, to be exact, with over 90% code coverage)

Shameles plug:
If you’re a solidity developer looking to hack on some advanced contracts, we are still accepting submissions! Secure the Network and make some $DAI in the process
</shamelessplug>

Last quarter we launched our Bug Bounty Program, and have to-date paid out $3600 in bounties to open-source contributors who submitted valid issues.

There were bugs alright, and we are continuing to optimize and improve the Colony Network with your help.

Learning #3: Research is important

Although it’s crucial sometimes to focus exclusively on the here and now challenges, we put a high value on theory and more forward-looking work. While we have made steady progress on the dapp, one of our big accomplishments last quarter was the creation of a new crypto-economic primitive! Eat your heart out, TCRs and Bonding Curves.

In London this winter, a few members of the Colony research team convened for a ‘research sprint’ to discuss possible mechanisms for perpetual self-improvement of the Meta-Colony.

What resulted from that week was pretty nifty pattern we call BudgetBox

https://blog.colony.io/introducing-budgetbox/

TL;DR -- BudgetBox is a proposed mechanism for allocating a budget in a decentralized context. Instead of creating a ranking or other arbitrary method of deciding “this much money goes to this recipient”, budgetbox builds a budget directly from a large set of pairwise preferences (“I think this initiative is better than that one”).

We’ve gotten a lot of good feedback on the paper, and we welcome anyone who wants to discuss or experiment with our solidity implementation to reach out to [email protected] .

En Guarde, Q1

As we have said many times: dapps are hard. This quarter, we’re working on overcoming a few major challenges that need to be solved before the colony reference client meets our exceptionally high standards.

UX and onboarding

One major piece of work we’ve been fixated on is user onboarding and UX.

We want interacting with our smart contracts to be simple. Dead. Simple. That’s a huge ask considering that users will need to perform multiple transactions on-chain as they interact with Colony. So we came up with a concept we call the ‘gas station’ for grouped and multisig transactions.

The Colony gas station is a way of displaying all the need-to-know information about your dapp interactions that are bound for the blockchain in a human-readable context, and more importantly making the multi-signature transaction workflow smooth and simple. Rather than popping up and asking you to sign and broadcast transactions as they happen, the gas station saves all your interactions as unbroadcasted ‘pending’ transactions, ready to be signed and committed to the public record.

All transactions ready to be signed and sent to the blockchain are grouped together by category, so that they can be sent at once or queued for later. Instead of seeing a contract address, you’ll get a descriptive title of what you’re doing, how much the transaction will cost, and whether or not that transaction requires another’s signature to be finalized.

TL;DR: Colony’s gas station makes using Ethereum multi-sig transactions easier to understand, and reasonable for normal people.

The gas station concept screen

ENS support

Colony is made for people (although robots are welcome, too). People have a hard time remembering phone numbers, let alone long strings of hexidecimal.

Well good news, everyone! Through the magic of ENS sub-domains, your Colony will, at launch, be able to claim a nice, friendly human-readable name *without* needing to go through all that commit/reveal hubbub associated with top-level domains.

When you create a colony with the dapp, you will have the option to register `mycoolcolony.joincolony.eth` -- and it’ll just work. If you don’t want the .joincolony.eth TLD, you can also configure your own ENS domain to work with a newly created colony.

Pinion and OrbitDB

Every dapp needs to have some kinda database, because there’s a lot of important stuff that can’t be put on-chain. For example, profile pictures, comments associated with tasks, and other meta-data such as that is necessary for a good user experience, but totally impractical (and expensive) to put on chain. That would be crazy. Most dapps today are a kind of centralized/decentralized hybrid, where this meta-data is hosted on a server, but the *real* important “decentralized” center is, of course, on Ethereum.

That’s not good enough for us. Colony needs to be **truly decentralized**, meaning that even that meta-data should not depend on a central server or data store. It’s gotta live on a distributed network like IPFS. In the case of the Colony dapp, that system is built on top of (or forked from, to be more accurate) the OrbitDB project. This allows us to keep more complex data associated with a single Ethereum account on IPFS, as a structured database instead of an isolated file.

IPFS, however, by virtue of being a decentralized and distributed system, has some of its own quirks, which we needed to solve. For example, when some meta-data is put up on IPFS, it’ll only stay on a particular node for a finite time if it’s not requested by someone else on the network. When a user uploads a profile picture to the dapp, we want that picture to be *always* available, no matter how long the user waits.

Pinion solves this problem, by providing a ‘pinning service’, and making sure that at least one node on IPFS is up an serving the data that needs to be available, effectively ‘pinning’ it to the network, available for all users at all times. We'll be open-sourcing pinion when we feel it's polished enough for the prime-time.

Multi-signature transactions

You may have read Elena’s parameterized transaction reviews article, which was a deep dive into the solidity implementation of Colony’s multi-sig pattern.

The complete end-to-end lifecycle of a multi-sig transaction involves a lot of off-chain helper machinery, which brings the signed transaction from one user to another. The multi-sig transaction workflow touches almost every aspect of the Colony stack.

There’s a lot going on here -- too much to fit into this post, but expect a full-blown technical post that dives into an end-to-end multisig transaction, and how it plays out, both on-chain and from the perspective of a user.

Integrate Colony into your App

Developer experience matters. One thing we’ve worked on already is making integrations with Colony as simple as possible for dapp developers and projects that want to use Colony for their governance layer.

The ColonyJS docs have been massively improved, and now detail exactly how to bring in all Colony methods to your application for simple integration.

We’ve added a new payments function to the colonyNetwork contracts. This is to enable a Colony to make payments without requiring the signature of the person getting paid. This might be useful for cases in which you want to create incentives or rewards that happen after the work has taken place.

Finally, the colonyStarter has also been revamped and improved. If you’re wondering how to integrate colony into a JS or react-based front end, you can see tons of examples within the colony-starter-basic and colony-starter-react packages. Just yarn and go!


Meet us in person!

ETHCC / ETHParis -- Our own Daniel Kronovet will be giving a talk on budgetbox at EthCC, and more than a few team members will be attending both ETHCC and ETHParis. Magnifique!

RadicalxChange -- And right after Paris, a few (or maybe just one) Coloneer will be headed to Detroit to present BudgetBox.

Colony makes it easy for people all over the world to build organisations together, online.

Join the conversation on Discord, follow us on Twitter, sign up for (occasional and awesome) email updates, or if you’re feeling old-skool, drop us an email.