Skip to content

Instantly share code, notes, and snippets.

@ryanxcharles
Last active August 29, 2015 14:04
Show Gist options
  • Save ryanxcharles/df9b2ac76b359a275b46 to your computer and use it in GitHub Desktop.
Save ryanxcharles/df9b2ac76b359a275b46 to your computer and use it in GitHub Desktop.
The Principles of Copay

These are the unviolable principles of Copay.

  1. Copay is decentralized, i.e. it has no central point of failure, i.e. the users (copayers) do not have to trust anyone to be able to use the Copay app.

  2. Every pull request moves towards, not away from, this ideal. A pull request that adds central points of failure gets NACKd.

  3. Any existing central point of failure is a bug that must be fixed (i.e., relying on a single PeerJS server, or trusting messages from other Copayers).

  4. Where possible, we prefer software to be written on the web first, so that it is easily cross-platform. Not everything can be written in a web browser. Such code will be located in a local node server which both delivers the web app and does anything that cannot be done in the browser.

  5. Some users will prefer to run the web app (a copay "light node"), but not the node server. Copayers will be able to provide a hosted solution of the node server for other copayers. BitPay will also provide hosted solutions.

  6. It needs to be easy to install a Copay "full node", which includes all server elements. It should be as simple as typing "npm install copay" to have a fully operational server with default configs.

  7. Since copayers will often rely on third parties to host the node server for them, it's important that all security elements remain in the browser if it is possible for that to be the case. i.e., all keys are held in the browser, all messages are signed and verified in the browser. The web client does not trust the node server, except where it is not possible to do otherwise (e.g., it is not possible to run a bitcoin full node in a web browser, so unspent outputs must be retrieved from the node server).

@yemel
Copy link

yemel commented Jul 21, 2014

"Such code will be located in a local node server which both delivers the web app and does anything that cannot be done in the browser."

Is there any need to be a local server and not a remote one?

@yemel
Copy link

yemel commented Jul 21, 2014

"Such code will be located in a local node server which both delivers the web app and does anything that cannot be done in the browser."

There are security implications about this, the most secure way to run copay it's from a browser extension. Delivering the web app provides easy-of-use, but any other client should be able to connect and operate through the server.

@ryanxcharles
Copy link
Author

Is there any need to be a local server and not a remote one?

No, it can be remote. However, it should be easy to install locally.

There are security implications about this, the most secure way to run copay it's from a browser extension.

The security implications are minor if everything is running locally. However, yes, agreed that we should direct people to the browser extensions over the web app.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment