-
Couldn't load subscription status.
- Fork 33
API Innovation
In the noise around Bitmark, a critical subject has been lost. The subject of Innovation.
Whilst we do not plan to innovate in the way recent alt coins have, we will innovate in two crucial areas.
The first you have probably heard of - Marking. That is a different subject discussed broadly already.
The second area is key to Bitmark's future success - the power of the API.
This semi-technical article identifies what we consider to be the major current limitation of Bitcoin, and details how Bitmark will address it.
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 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.
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
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.
In an abstract sense, wallets are essentially block explorers, displaying information on only specified addresses.
The primary functionality supported by wallets is simply the sending of transactions.
You can safely send any transaction through any node, as is already the case. Even many blockchain explorer applications already include a 'send-transaction' method.
A wallet can therefore be seen as a personal block explorer, offering a real-time view of information associated with certain public keys (addresses).
With this abstraction, we can argue that key management and the send of transactions can be extracted out. Watch only wallets showing new transactions and view the history, need only the public parts of our keys, they can rely on a network of servers to request information about each key separately, keeping the information as to who owns which keys private.
Secure key management should be in the domain of the security and cryptography expert, not the protocol specialist, or the user design and experience specialist.
Locked down software for securing keys, exposing only simple methods to sign transactions or data.
By separating each modular component, and allow each to communicate by well defined APIs, we can enable interoperability and extensibility.
Providing a scalable, extensible uniform API enables independent innovation.
Bitmark's innovation - outside of adoption via marking - is to enable everybody else to innovate on and around Bitmark and it's blockchain.
We will define the interfaces and ensure they are used, resulting in others using them innovatively to benefit you.
Our philosophy is simple - why have one bloated client competing for your use, when you can enable a world of developers to innovate for themselves, competing to improve their offerings for you.
Bitmark is built upon Bitcoin, and maintained to include Bitcoin's stable Release Channel and Quality Assurance.
We do not modify the existing APIs, we provide an additional API. Inclusive, rather than exclusive.
All of the existing things which have been built for Bitcoin already work with Bitmark, and will continue to, as will future things not yet built.
Bitmark will both simplify and extend what exists, to provide modular parts.
We realize that our own system needs to be developed to be part of other and larger systems. It is modular, required to be interoperable with other systems.
Marking, our novel adoption programme, has two functions, the most obvious being to offer utility to users. The second, less obvious function is to enable collection of a broad range of requirements - from businesses, users, and developers.
Wide spread adoption leads to a broad range of requirements. Multiple requirements have multiple solutions.
Multiple solutions allow standardization, standardization entails tolerance and the principal of least power, allowing the simplest most useful solution to come to the fore.
In this way, we will develop our API over time. Once proven and ready, and already integrated with all those applications which develop upon it, we will release it as 'stable'.
Project Bitmark will gather a broad range of requirements through widespread adoption, we will use these requirements to define and build a RESTful uniform API.
In doing so, we will enable a scalable architecture, interoperable components, and extensible design - allowing critical growth and wide spread independent innovation.
This API will fundamentally change the shape of the Application Network, and address major current limitations to scalability, innovation, and adoption.
Our innovation is to allow others to innovate, specialists to specialize, and teams to compete. This allows all participants to play to their strengths, and will produce far more useful and interesting results.