The Web RTC Solution

gistfile1.txt

First, The Problem:

Allow for users of Safari and IE to use Copay, and allow for
asynchronous transaction proposals. Do so in a manner consistent with
decentralization, i.e. with no central points of failure, i.e. where the
copayers do not have to trust anybody, including the other copayers and
including BitPay.

The Web RTC Solution:

1) The copayers are on a p2p network.

2) The copayers use Web RTC. Web RTC is the only protocol that allows
p2p from the browser. This is why we have chosen it so far. The
principle here is that everything should be in the browser if it can be,
otherwise it is in a local node server. This makes it easier to make
code interoperable between platforms. Web RTC also has natural support
for STUN and TURN servers, which allows for p2p connections to exist
more often even if the peers are behind difficult NATs. Web RTC is also
naturally encrypted and authenticated, but because it uses unreliable
self-signed certificates, we have our own encryption and authentication
on top.

3) To support Safari and IE, we move the Web RTC code into a local node
server. Only in that case do we move the Web RTC code. If it can be run
in a browser, as in Chrome and Firefox, then it is run in a browser.

4) To support asynchronous transaction proposals, we let peers relay and
store messages until all peers have them. We also support push
notifications to your phone to alert you that you need to sign
something. Your node server is what pushes to your phone.

5) For copayers who do not wish to run a node server locally, BitPay can
run it for them. We will want to write this server in such a way that it
can handle one copayer when run locally, but can also handle many
copayers efficiently when run by BitPay. BitPay does not have anybody's
private keys, but when people rely on the BitPay for their node server,
BitPay can certainly DOS attack the the users.

6) To eliminate the rendezvous central point of failure, put the
rendezvous server (and STUN and optional TURN servers) in the local node
server. When peers connect to each other, they use every other copayer's
rendezvous server. Each copayer stays registered on each other copayer's
rendezvous server. If one STUN server fails, they fail over to the next
one, and eventually onto the available TURN servers.

7) When copayers share their shared secret, it will have to include not
just their public key as it does now, but also the address of that
copayer's rendezvous server.

Please let me know if you have any questions. This solves all of the
problems: 1) Will work on Safari and IE. 2) Allows for asynchronous
transaction proposals. 3) Does so in a manner that is decentralized
(although most users will opt-in to BitPay-hosted centralized servers as
a convenience.) I can work it out in more detail before programming it
if necessary.

I am not committed to using this particular solution. If the developers
find this solution distasteful, we don't have to use Web RTC. We could
use a normal p2p connection over tcp. However, Web RTC has the
advantages that 1) It already supports STUN and TURN servers to increase
the reliability of p2p connections. 2) It works in some browser now, and
will work in all browsers in the future.

To make this work, these steps need to happen next:

1) For users of Safari and IE, allow the web app to communicate via http
to the local node server to handle the Web RTC connections (using the
Web RTC node module I have linked before). This will interoperate the
same as usual with users of Firefox and Chrome.

2) Change the network protocol to support storing and relaying messages.
When a peer receives a message, they store it first, and then try to
deliver it to all their peers. Only once every peer acknowledges
receiving the message is the message deleted.

3) Add the ability to push messages to phones from the node server.
Every message is pushed to your phone when you have this turned on. Your
phone runs just the web-client part of Copay and does not need to
maintain p2p connections. It communicates via the node server running on
your desktop/laptop.

4) To support people who do not want to run a node server on their
computer, set up node servers on BitPay as hosted solutions. We need to
be careful to design the node server so that it can scale to handle many
users at once.

Again, I'm not committed to this solution. If someone can find a
simpler, more elegant solution, I'm all for that. A centralized message
broker, however, is not a solution, because it is a central point of
failure. If you want to use STOMP, it would have to somehow be
replicated on every node. I don't know how to do that, but it may be
possible.