Re: Potential work items (was: Re: Getting stuff done at W3C)

On 13 September 2016 at 19:53, Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 09/13/2016 12:29 PM, Doug Schepers wrote:
> > This conversation is interesting, but it's out of the scope of the
> > Blockchain CG.
>
> I'll stop talking about W3C process and focus on why I sent the mail to
> the group in the first place:
>
> Having been through this multiple times as W3C, I've found this
> checklist helpful in organizing work in Community Groups:
>
> http://manu.sporny.org/2016/rebalancing/#checklist
>
> These are the potential work items I see:
>
> 1. Chainpoint
>

+1


> 2. Linked Data Signatures (secp256k1 support)
>

+1


> 3. Interoperable Data Model / Block Format
>

+1


> 4. Basic Blockchain REST API
>

+1

Please note that bitcoin has a built in REST API.  And there are also 3rd
party offereings.

Additionally, some high level notes on this from a project I'm working on:

# Bitcoin Network Application Architecture

Bitcoin's P2P software network, which controls the blockchain, is fit for
one purpose - keeping the network secure. However, looking at the network
application architecture paints a very different picture. The current
network components consist of:

* Fat clunky locked down clients with huge block chains (Bitcoin-QT).
* Lighter Daemons with huge block chains which offer no public
functionality to anybody (bitcoind).
* Thin Fast clients (electrum, multibit, hive, ...) attached to
non-interoperable alternative servers (electrum server, bitcoinj, ...)
* Multiple web clients and mobile applications attached to custom or
alternative server software or block explorer APIs.
* Black-box trust based custom services, which expose data and some
functionality in a more usable fashion (BitPay, Coinbase, Blockchain.info,
all Payment APIs, etcetera)

More succinctly, there exists:

* P2P Network of private nodes exposing no data publicly
* Incompatible public data sharing servers
* Incompatible public data consuming clients

## The issue: fast clients do not have trusted data suppliers

The problem is that data consuming clients cannot use the P2P network of
nodes as data providers. The P2P network software does not expose a usable
public API -it secures the block chain, but does not provide access to it.

There is no client-server network.

## Creating a public network of nodes

A decentralized network already exists; the P2P Network.

The application architecture is already mature, Fielding's REST and
Berners-Lee's World Wide Web are ubiquitously supported and proven.

The solution, simply put, is to have Private P2P nodes expose a Public API
in the role of server, using well-defined media types (REST) and protocol
(HTTPs).

Rather than custom non-interoperable requiring trust providers, a multitude
of inter-operable clients and services could then be created, each using
the public P2P network of nodes as servers / data providers.

So, what does our network look like now?

* P2P Network of blockchain-securing nodes, exposing data publicly via web
services (API)
* Compatible public data consuming clients and services

## Implementation Hiding

A benefit of utilizing RESTful Interface is the way in which the specifics
of the code are hidden within the implementation itself. What happens
behind the interface is of no concern to anybody using it. This allows
further innovation, decoupling clients from the daemon, as any service
provider can implement an equivalent, more streamlined, or extended API -
whilst remaining interoperable. See nginx and apache, a wide range of
browsers, and millions of systems utilizing HTTP as an example.

The flow of functionality is defined by well-defined data using media
types. If using generic extensible types, additional data, and thus
additional functionality, can seamlessly be rolled out without requiring
protocol upgrades. Clients only show and utilize whichever data they
understand.



>
> Step #1 of the checklist is to clearly identify and articulate a problem
> statement around those 4 items (if folks agree that doing so is
> compelling). Before we do that... does this list resonate with folks? Is
> it missing something? Is there something on there that we shouldn't
> focus on?
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Rebalancing How the Web is Built
> http://manu.sporny.org/2016/rebalancing/
>
>