Set up basic webpack infrastructure for CSS modules. Move over our shared styles as well.

This issue should cover improvements that should be implemented in the CI builds:

• Run with JUNIT output when on CI to report the errors properly

Login workflow discussion

With the new dapp we won't have the original concept of identifying "users" anymore but we will identify users by their ethereum wallet address (and attach meta data like the username, id, etc).

This requires new workflows to "sign in" into our app. Signing in will be done by "unlocking" a certain wallet. The library we will be using allows for a couple of methods:

Mandatory methods (we will choose 1 as the preferred one)

• Create a new wallet from scratch (will provide the user with a new address which they can use to receive / send ether and other tokens (the colony token obviously), hence use our app. This wallet will require a password and can be exported to the following three options)
• From private key (this will create a wallet from a private key which looks like this: 0x19c95ed4d052bdfc79568d7c137fa3ec5d7ef84efe0a165847f948b230e48cdb
• From encrypted json wallet (this is a file, which can also be created by geth, which holds the private key, secured by a password. The user has to provide the file (e.g. "upload" it) and the password to unlock the wallet)
• From a mnemonic (this looks like the passphrase which users have to put in in the current beta app)

EDIT: We decided to go for the mnemonic as the preferred method, but support all the others as well

We should support all of those, but hide the ones we think are more for the "advanced" users. What do you think would be a good option for "novice" users or the ones who just want the most comfortable UX?

Then there are other possibilities:

Convenience methods (optional)

• Login with MetaMask / Mist (very comfortable of course, we don't even have to provide the UI)
• Login with uPort (as far as I understand we still have to create an own wallet for the users but we can sign with uPort somehow? I have to look into this. We will try to make this work, for sure, but for the sake of the argument of this issue let's assume we won't support this)
• Login with a hardware wallet (like TREZOR, Ledger Nano. I really would like to support this, although it might be a bit more complicated as those are HD wallet which require an additional modal)

You can see most of these options in action on https://myetherwallet.com/. Choose "Send Ether & Tokens" and you will see the unlock screen.

Then there's the question how users will actually sign the transactions (what in the beta is the wallet password dialog). Once we unlocked the wallet, how do we want the signing process to work? This is easy with hardware wallet or MetaMask / Mist / uPort, but what are the requirements for signing transactions with a custom wallet (above options). Will this just be a modal, wanting to put in your private key again? I don't really know how myetherwallet does it as I'm using a hardware wallet.

Pinging for UX suggestions, discussions: @Karol-colony @collinvine
Pinging for implementation questions, discussions: @area, @elenadimitrova, @thiagodelgado111

Please let me know what y'all think!

This includes but is not limited to:

• Brain growth on the topic
  • For brain growth on distributed systems: http://book.mixu.net/distsys/
  • Decentralized web primer: https://www.gitbook.com/book/flyingzumwalt/decentralized-web-primer/details
• Keeping the technology / projects spreadsheet up to date: https://docs.google.com/spreadsheets/d/10TAtjaMWzHDNlFGThAW-Aocpv9LjjDiW7_NGtZ-RO4o/edit#gid=231837790
• Engaging with the creators and the community of these projects (join the slack, telegram, gitter channels)
• Implement a PoC for a short term solution
  • IPFS (orbit PoC)?
  • Bigchaindb for transition phase?
• Strive for a long term solution

• Choose a library to do async in redux (just one!)
• Define error handling (reduce boilerplate)
• Define actions that connect to the colony-js client

Adds ColonyNetwork as a submodule of the dapp and sets it up and running with the provisioning script

• install react-router
• install redux !
• install redux-form
• install react-intl

This will be a particularly long running epic as this can be closes once everything (in terms of functionality) what we have in the beta will also work in the dApp.

The goal is to move all react components to the dApp eventually. Some considerations:

• Move to CSS modules on the beta repo first before copying
• Move to flow when copying over

Turn into a CLI API that can run locally as a service, packaged up (for instance) with IPFS and parity/geth.

Mirrors JoinColony/pinningService#23.

We want to put our static assets (.js, .svg, .css, etc) onto IPFS / Swarm. We need to find a good solution on how to do that.

This includes but is not limited to:

• Making a decision of whether we want to use IPFS or Swarm for that
• Finding a solution on how to split and deploy static assets (.js) to IPFS / Swarm
• How to version it
• How to do caching and cachebusting
• Eventually automate the build and deploy process

UserProfile will contains a user profile description (at least description, name & profile pic).

The UserProfile demonstration will show a few components:

• create my profile if it doesn't exists already,
• check my profile that redirects to your profile,
• profile editor that lets you edit your profile,
• profile viewer that lets you see someone else's profile.

The following is an extract from a Slack chat with James:

It would be useful to test something along these lines:

• Get an instance of ColonyNetworkClient (connected to local Ganache)
• Create a Colony, get an instance of ColonyClient (with both BYOT and creating a token via the network client)
• Set/get a Domain
• Set/get a Skill
• Go through the task lifecycle (this will require multiple wallets)
• Create a Task
• Set/get the specification (hash) for the task (involves multisig functions)
• Later: set/get the specification content and hash together, using the 'Extended Colony Protocol'
• Submit a task deliverable
• Finalize or cancel the task
• Claim the payout

What we're aiming to test:

• Are the different components for the JS client (ethers or web3 adapter, contract loader, wallet) all working together as expected?
• Can we go through a simplified task lifecycle without problems? Are the JS client and contracts fully compatible? (I think this will be especially useful going forward, when changes are made to colonyNetwork)
• Does the multisig functionality work as expected?

When we can prove all of these things are good to go, then we should be ready to open source colony-js.

Add PR template to make it easier to read and understand what does it do and which issue is it closing / contributing to.

After #73 is done, this ties everything together and sets up ganache, trufflepig and the contracts in the setup phase of jest

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

As a developer I want a script to create new components, so that I don't need to copy boilerplate code (or introduce any discrepancies).

e.g.

yarn new-component MyComponent

The above would create a MyComponent directory, with all of the necessary files and boilerplate code.

Use the wizard to create a Colony. We don't have hi-def screens yet, so this is going to be a bit rough.

Tasks involved:

• BYOT (bring your own token)
• Creation of a token
• Creation of a Colony

Integrate: colony-js-client, colony-wallet

Solution A:
Wait for orbitdb-based permission system that should let a user add "admin keys" to their store when they change devices.

Solution B:
Implement a finer permission system: with the ability to add custom rules to orbitdb "accept" operation.

We can have the user generate an orbitdb keypair (keyChild), and sign this keypair ONCE with their wallet (keyMaster).
When we generate updates with OrbitDB, we add this signature to the payload.

Our custom rule system could check the keyChild signature and accept every subsequent updates.

We don't really want to use chimp anymore (because there must be better solutions and because it's strongly tied to meteor). So we have to figure out:

• How to do acceptance / integration testing?
• Is there a good alternative to chimp (nightwatch.js)?
• Can we re use existing code?
• How do we mock ethereum data (fixtures)
• How do we do fixtures for decentralised db technologies

At the moment, the client browser communicates with each pinningService node individually. Manual tests indicate a pinningNode cannot sync the catalog database directly from another pinningNode. This is a hub-and-spoke architecture.

This issue has been resolved for integration tests, but not across machines. Debug the nodejs-nodejs OrbitDB communication issue so we have a graph architecture again.

This issue mirrors JoinColony/pinningService#20.

It looks promising: https://www.cypress.io/

The colony-js client is maintained in a different repository, though its function and completeness is a crucial prerequisite for the colonyDapp. We're tracking responsibilities in this epic.

https://github.com/JoinColony/colony-js

Add the jest framework to run the colonyBeta unit tests in this environment as well.

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Replaced the old Node.js version in your .nvmrc with the new one
• The engines config in 1 of your package.json files was updated to the new Node.js version

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

Move over the form fields in core/components/Fields to the dapp. Migrate to flow. Make sure the tests pass.

Like in colony-js we want to add prettier to auto-format our code. This time we might want to include the react related modules.

This issue will track adding a new workflow to Circle CI that will run integration tests.

This should be a separate workflow to add unrelated tests (and additional time) to the normal colonyDapp workflow

Currently a client can contact the pinningService to receive a database address. But the correct database must be uniquely identified, without knowing the database hash.

More probably the colony address will serve as the catalog _id, and that document will hold all databases necessary.

This issue tracks JoinColony/pinningService#8.

For that we need to:

• Move over wizard component
• Set up route
• move over the Fields form components
• add colony creation actionCreator
• connect the wizard to the actionCreator
  ...

Jobs Story

When registering a new account at Colony
I want to register with an existing wallet that I own
So that I don't have to create a new address to use Colony

Specs

Users should be able to register accounts with Colony using an existing wallet they already have created. We have four supported wallet types:

1. MetaMask
2. Hardware
3. Mnemonic
4. .json file

The workflow changes slightly for each wallet type, but is:

1. Click Open Colony from the homepage
2. Select wallet type from page
3. Unlock wallet
4. Fill in profile details (only for new accounts)
5. Go to profile

Note: we try to do auto detection of a wallet. See #101 for those specs.

Select Wallet

MetaMask

If the user is connected to MetaMask, we show this screen:

Clicking Go to Colony will either:

1. Direct them to their profile page if it's an existing user
2. Direct them to the page to fill out their profile details if it's a new user (#102)

If the user is not connected to MetaMask, we show this error screen:

Hardware Wallet

A user can use their hardware wallet to register with Colony. If it's connected, we show them a selection screen:

If the wallet is not connected, we show an error screen and prompt them to connect the hardware wallet and try again.

When we are waiting for the balance amounts to load, we will show this loading element:

• add search field for user to paste in wallet address
• show scrollable list of wallet addresses
• add loading element on balance amount

Mnemonic Phrase

A user is prompted to input their mnemonic phrase.

If it is not correct, we show this error screen:

JSON file

A user is prompted to upload a wallet file (.json)

Once uploaded, we allow a user to proceed by clicking Go to Colony or Remove the uploaded file.

If it’s an incorrect file type or unrecognized json file, we throw an error:

Navigation

Back button takes the user back to the previous screen

The Colony Logo in the top left takes the user back to the homepage (colony.io)

• When a client sends a database for pinning, it is added to the catalog and then pinned.
• When a node starts up, it pins all databases found in the catalog.

However, suppose pinningNode1 and pinningNode2 are both running, but only pinningNode1 is in direct contact with the client. When pinningNode1 pins a database, client database is added to the catalog, pinningNode2 will see only the catalog update.

This case may arise when JoinColony/pinningService#20 / #95 is resolved. That issue should be resolved first so this is easier to test.

Ensure that when the catalog updates, pinningNode2 pins the new database.

This issue mirrors JoinColony/pinningService#21.

Users are going to create & edit their profiles using orbitdb.
By default OrbitDB uses its own, generated, keystore.

This is limiting:
We want a user to be able to find its own profile,
We want a user to be able to edit its own profile,
We want a user to be able to change device (mobile, another browser, etc) and keep its access.

A solution is to have orbitdb relies on a user personal wallet (unique per user) instead of orbitdb's generated keystore (unique per device).

We are looking for someone to participate in a 1-hour user testing session. You'll need to join a video call and be able to share your screen as you navigate and attempt to complete some tasks on a low fidelity prototype.

We'll be looking for users to speak out loud about their experience while we observe and record the session, asking questions and prompting you to comment on certain features or interface designs.

The Wizard component from the beta is tightly coupled to react-router which is not really necessary. So we'll have to simplify it and integrate it into the dApp

When a user goes offline, their orbitdb store shall remain accessible to other users.

This is likely to be solved with our Pinning Service.

Features:

• Submit a User Profile to keep online,
• (maybe) Submit a Profile Pic (IPFS) to keep online,
• Keep online submitted stores / resources.

As a developer I want a productive and intuitive experience while working on Colony, so that I can make more improvements to Colony

For a better documentation and rapid development of our react components.

https://github.com/styleguidist/react-styleguidist

These tests should probably include:

• catalog holds database address
• pinner database holds same info as client database
• second client can request database
• second client database holds same info
• pinning node unconnected to client holds same info

Add a CI integration using circle v2: https://circleci.com/docs/2.0/hello-world/

This issue is meant to keep track of all the open TODOs which have to be tackled during the initial phase of the realDApp project. Currently this is more like a loose collection / braindump, but will be expanded into proper issues gradually.

General tasks / questions

• Create feature roadmap
• Identify projects which could help with saving metadata
• Identify projects which could help with real time (pub sub)
• Schedule calls with interesting projects
• Figure out when to bring on new people onto this project
• How to deal with colonyNetwork changes? How to align progress and goals?

Colony client API

• Refactor / rewrite colony client
• Open source it!

Web3 / contract <-> js interaction

• Find solutions for accounts
• Find solution for wallets
• How to abstract web3 and alternatives?

Frontend build / dev process

• Scaffold app with react, webpack
• add testing frameworks (jest?)
• use current libs, react router v4
• Use facebook flow from minute one
• make use of progressive web app technologies (service worker)

How to deal with static files / all of our js assets

• Static files, hosting on ipfs / swarm
• How to use ipfs / swarm properly
• take care of caching / cachebusting
• How to do versioning?

We want to find a solution how to best compile, version and deploy the contracts (including uploading the compiled contract files to IPFS / Swarm).

This includes but is not limited to:

• How to version the contracts and deploy them, maintaining a list of deployed contracts, versions and addresses on the specific networks
• Put the compiled contracts on IPFS / Swarm and version them as well
  • Maybe have a smart contract for storing contract hashes that point to IPFS?
  • Store on IPFS / swarm and use ipns / ens?
• How do we automate that?

Notes:

• Contract addresses can be hardcoded for the particular ethereum networks

To 16.x

Watch out for react-router breaking HMR