Introduction

In the blog article in October last year protocol v.2.0 was introduced. We invite you to read it before continuing this article. In it, we wrote:

The initial release aims at being a scaffold on which we’ll incrementally add features. v2.0 includes:

An implementation of the storage layer based on Ethereum

A basic implementation of the data access with no encryption. Encryption will come later.

Implementation of the logic layer

A gateway with the essential feature for apps to use the protocol

Detection of Bitcoin payments

v2.0 will be publicly released once completed and successfully integrated with an app. We estimate the release to happen during Q1 2019.

And today we are here to announce the release of Request Protocol — version 2 alpha.

What “alpha” means

v2.0 will be released in 3 stages:

Alpha: internal testing . This very early version is intended for internal tests and feedback collection. The code and the packages are publicly available but we do not recommend starting integration as the documentation is incomplete, and bugs are very likely to be present at this stage. But you can play with it if you’re adventurous!

. This very early version is intended for internal tests and feedback collection. The code and the packages are publicly available but we do not recommend starting integration as the documentation is incomplete, and bugs are very likely to be present at this stage. But you can play with it if you’re adventurous! Beta: for external testing . During this phase, we’ll be looking for feedback from external app developers, while continuing to improve the documentation and polishing the product

. During this phase, we’ll be looking for feedback from external app developers, while continuing to improve the documentation and polishing the product Release: mainnet release, when the product has reached a production level quality

What is done

This is what is done as of 2.0-alpha. Links to GitHub and npm can be found in the section below.

Detection of bitcoin payments, which means BTC requests can be made

Implementation of the Storage layer, based on Ethereum and IPFS. Requests are saved on IPFS, and the IPFS hashes are recorded on an Ethereum smart contract

Basic implementation of transaction creation and indexing. Data Access has been split in Data Access (indexing) and Transaction (transaction creation and encryption)

Implementation of the Logic layer that handles basic Request logic

Implementation of the Request Node. Request Gateway has been renamed to Request Node, which is more descriptive of what it is

A javascript library to interact with nodes

Content Data, the standards for the data of the Request Protocol

Architecture

This is what it all looks like today:

Items in light green are done in v2.0-alpha. Items in dark green are items for post 2.0.

Storage : Store the data about requests on IPFS and Ethereum

Store the data about requests on IPFS and Ethereum Data Access : Indexes transactions and will eventually batch them

Indexes transactions and will eventually batch them Transaction : Create transactions and will eventually handle the encryption

Create transactions and will eventually handle the encryption Request Logic : Business logic: properties and actions of requests

Business logic: properties and actions of requests Advanced Logic : Hosts the extensions to the protocol

Hosts the extensions to the protocol Content Data : Hosts the standards for the data of the Request Protocol

Hosts the standards for the data of the Request Protocol ETH/ BTC /Fiat Payment: Detection of payments

Detection of payments Smart Requests: Smart requests, in addition to documenting transactions, have control over them. It enables extensions such as continuous payments, cross-currency, escrow, ICO

Smart requests, in addition to documenting transactions, have control over them. It enables extensions such as continuous payments, cross-currency, escrow, ICO Request Node : Web server that accepts transactions and saves them in IPFS and Ethereum. They aim at making easy to use the Request Storage.

Web server that accepts transactions and saves them in IPFS and Ethereum. They aim at making easy to use the Request Storage. Request Client js : A web and node.js library to connect to Request Nodes, meant to simplify the use of the protocol. It is a replacement for @requestnetwork/request-network.js

A web and node.js library to connect to Request Nodes, meant to simplify the use of the protocol. It is a replacement for @requestnetwork/request-network.js Request Portal: Request Portals exist on top of Request Nodes and libraries. They provide an even easier usage of the protocol in exchange for a fee. It is not necessary to go through the portals to use the Request protocol

Where to find v2.0-alpha

Request Node:

Library:

Smart contract on rinkeby:

What happens to v1

The v1 smart contracts stay on Ethereum and are usable, the v1 library stays on npm and will be minimally maintained. The v1 library repository has moved to requestNetwork-v1-archive.

We’ll be slowly deprecating v1 and helping users to migrate to v2.0 during the beta version.

Want to start using it?

At this point, the documentation needed to integrate easily is not ready, so we do not recommend you start using it now. However, if you want to play with Request Protocol v2.0:

Check out Request Node and deploy a node in local

Check out request-client.js and especially test/index.html and start using v2.0!

If you need help, come find us on the Request Hub.

What is next

The main points of focus after having released v2.0-alpha are: