DappRegistry

[jacogr]

We really don't want developers to interact with and have to understand the underlying contract to register their own apps for network access (i.e. global). This dapp provides the bare basics, registration, deletion & updates with no extra frills.

https://youtu.be/3KtGkYkai90

TODO -

1. Hook up to the builtins page & make available as an dapp (will be done once https://github.com/ethcore/parity/issues/3308 is in - rework the visible, hidden & external display.) Currently dapp only available via direct URL access

2. Update Wiki for dapp registration to reflect process (i.e. simplify, make the current error-prone descriptions simpler)

3. Not 100% happy with the DappStore, class became a bit too big for quick navigation.

Closes https://github.com/ethcore/parity/issues/2126

[coveralls]

Coverage increased (+0.007%) to 86.022% when pulling 6659836 on jg-dapp-registry into 604be3e on master.

[coveralls]

Changes Unknown when pulling 0fe83ee on jg-dapp-registry into ** on master**.

[ngotchac]

Looks really nice! A few points though:

1. Are we sure we want to use sha3(`${this._startTime}_${Date.now()}`) for the new dApp Id ? Could use the selected owner into account, and check if the id is available. If not, retry.
2. Can't we use any URL for the dApp content ? I might want to upload my code somewhere else than on Github, and use Github hint to store only the URL of the manifest and the zip.

[jacogr]

The id can be anything, as long as it is unique. (We do however need to extend it a little bit shortly - people registering probably, like we do, want to use the same id on test & live. The only way to do that currently is to use the contract itself for the second network and manually specifying the id.)

As for the content - Parity currently (via contentHash) only supports content on GHH, so it is currently the only methods we support. Have played with chevdor with IPFS content for manifests & images. (Using the GHH hintURL functionality.) However the UI for the .zip itself is not going to move away from serving content via Parity - it has the MITM checking for content against hash built-in, so the content is only available via username/repo + commithash. (Have not tried registering a .zip via hintUrl and trying to access it, would probably be the easiest and may already be supported. As it stands the dapp doesn't really care, as long as the content is a hash and verifyable via the Parity download mechanisms, it is allowable.)

[jacogr]

Merging, need it for the contract & dapp deploys on ropsten (as to not doing everything again manually for the 3rd time around).