Vapor

Decentralized Web over Bitcoinized HTTP

vapornet@protonmail.com
Request invite

Contents

  1. Preface
  2. Introduction
  3. How is it different?
  4. Protocol
  5. Timestamp
  6. Decentralized HTTP
  7. Benefits
  8. World Wide Bitcoinized Web
    • Decentralized HTTP
    • Monetized HTTP
    • Money Programmed HTTP

0. Preface

There have been many past attempts at building a "decentralized internet". Most of them have focused on rebuilding the networking layer to facilitate decentralization of trust.

Vapor takes a different approach. Instead of rebuilding the networking stack, it focuses on decentralizing data itself, which works across any existing networking stack, most notably HTTP.

This leads to a superior user experience where all Vapor apps are simply HTTP based web apps, and no one needs to run a "P2P node" and have deep tech knowledge. To end-users, Vapor apps are indistinguishable from a normal web app because Vapor is literally HTTP.

Request an invite to get notified of the upcoming Vapor node beta release:

Request invite


1. Introduction

Vapor is an OFFCHAIN Bitcoin protocol for building a decentralized web by "Bitcoinizing" HTTP requests. In essence, it's a protocol for authenticating and wrapping HTTP requests inside Bitcoin transactions, making it possible to replicate HTTP requests across multiple interested parties in a trustless manner.

  1. WRAP: An HTTP request is wrapped in a Bitcoin transaction as an OP_RETURN output.
  2. SIGN: The wrapper Bitcoin transaction is signed by a Bitcoin wallet's private key
  3. POST: The transaction is sent to a Vapor endpoint over HTTP.
  4. AUTH: The Vapor endpoint authenticates the request by verifying the signature.
  5. ROUTE: The HTTP request is extracted from the transaction and routed to relevant API endpoints.
  6. REPLICATE: The Bitcoin transaction packet from step 3 may be replicated to multiple interested parties.

Because every API request is explicitly signed by a Bitcoin wallet and stored as a Bitcoin transaction with immutable bitcoin transaction IDs, it is possible to propagate a single HTTP request to multiple independent parties, complete with authentication information attached.

This makes it possible to build decentralized web applications that can trustlessly synchronize API requests with one another as well as natively monetize data through Bitcoin payments.


2. How is it different?

There have been many attempts at building a "decentralized web". Most of them see decentralization as a networking problem and focus a lot of their efforts on decentralizing the networking stack, as seen below:

before

Vapor takes the opposite approach. Instead of trying to reinvent the networking stack, it focuses only on decentralizing the data layer, as seen below:

after

There are many benefits to this approach:

  1. Superior User Experience: Nobody needs to run a P2P network node on their computer. Nobody needs to worry about how to bootstrap their own peer and all that nerdy stuff. Vapor is just HTTP, and you can build apps that look like regular web apps.
  2. Effective: Vapor decentralizes on the layer that matters the most: the data layer. When people talk about "decentralization", most mean taking power away from data silos and giving it to the people. And this has more to do with data ownership than how the data is routed around the Internet. Vapor solves this in a novel way that doesn't require changing the networking stack at all.
  3. Vanilla HTTP is Enough: Because Vapor does not rely on networking for decentralization, it can use ANY networking protocol. This means that data decentralization can be achieved by Vapor over plain old HTTP.
  4. Bring Your Decentralized Network Protocol: In addition to HTTP, Vapor can be plugged into any decentralized networking protocol--such as BitTorrent, DAT, IPFS, WebRTC, etc.--for even more flexibility and to leverage powerful features.

3. Protocol

Here's an overview of a Vapor request lifecycle:

flow

The protocol serializes an HTTP request and wraps it inside a Bitcoin OP_RETURN output script. This is then signed with a Bitcoin wallet's identity private key and included as another output script in the transaction. The resulting Bitcoin transaction is sent to a destination Vapor API endpoint over HTTP.

A Vapor endpoint only accepts HTTP POST requests with a raw bitcoin transaction as payload. The endpoint parses the transaction to extract out authentication information, validates the signature, and then forwards the extracted HTTP request to relevant API endpoints.

Also, each API request is timestamped and stored on the server for evidence as a Bitcoin transaction, creating an API log. This API log can be easily replicated to multiple parties in a trustless manner through various means.


4. Timestamp

Vapor supports two layers of timestamping.

4.1. Vapor Timestamp

By default, every Vapor API request is timestamped by the Vapor node with its local unix timestamp.

vaportimestamp

It's like every API logging system, except that every log item is cryptographically signed by both the user (The user wallet) and the service provider (The Vapor node).

The final "receipt transaction":

  1. is stored on the vapor node transaction storage
  2. may be stored by the user for later proof
  3. may be trustlessly replicated to other Vapor nodes


4.2. Blockchain Timestamp (Advanced)

Because all API requests are structured as Bitcoin transactions, it is very simple to send these to the blockchain. There are two ways this can happen:

blockchaintimestamp

  1. The user posts to the blockchain: Users may take the final Vapor receipt transaction, attach their UTXO input, and broadcast to the blockchain on their own.
  2. The vapor service provider posts to the blockchain: A vapor service provider may broadcast their transactions or a compressed version of the transactions to the blockchain to timestamp transactions on the blockchain.

A blockchain timestamp (Block hash/height) is less precise than Vapor timestamp (Unix timestamp) but is beneficial because the timestamp will stay on the blockchain forever.


5. Decentralized HTTP

5.1. BEFORE (HTTP)

In the existing HTTP based web paradigm, everything is stored on a private database owned by service providers.

This means it is trivial for anyone who has access to the server (employees, hackers, etc.) to tamper with the user data without any repercussion because there is no evidence of anything.


5.2. AFTER (Bitcoinized HTTP)

With Vapor every API request is double signed--first signed by the user, and then signed by the service provider (Vapor node)--and the evidence is stored both on the transaction log as well as returned to the user as receipt. The user may store the receipt transaction as evidence.

This has a couple of nice effects:

  1. Capture Authenticated HTTP Snapshots: Vapor captures every single HTTP request AND reponse as a cryptographically signed Bitcoin transaction. This is different from typical web logging systems where they're only used for analytics. With Vapor, every log event is a cryptographic proof co-signed by the user and the app.
  2. Every HTTP request has a globally unique ID: Every Bitcoinized HTTP packet has a unique Bitcoin transaction ID through SHA256 hashing. The unique ID makes it secure and easy to synchronize across multiple peers by acting as the checksum for the associated raw transaction, meaning all Bitcoinized HTTP packets are self-validatable.

Because it is difficult for service providers to tamper with user data, users have more power and control over how their own data is used. This means users don't have to rely on the goodwill of the service providers for the safety of their own data (Trustless)


5.3. "Record and Play" (DECENTRALIZED HTTP REPLICATION)

recordplay

Until now, it has been impossible to "record" and replay authenticated HTTP requests outside of a single service provider because authentication by nature has been centralized--Your identity belonged to the service provider.

By "Bitcoinizing" HTTP requests and adopting the decentralized authentication scheme using Bitcoin wallet signatures, Vapor makes it possible to record authenticated HTTP requests and replay them anywhere.

Because every HTTP request is double-signed (user signature + 1st party vapor node signature) and stored as a Bitcoin transaction which has its own unique ID (Bitcoin transaction ID), the HTTP request can be trustlessly relayed and replayed across other 3rd party Vapor nodes.

Furthermore, unlike normal HTTP requests which are ephemeral, Vapor's Bitcoinized HTTP requests are timeless. They can be recorded, persisted, and replayed at any time in the future, by anyone who is interested.

trust

The 3rd party nodes only need to check:

  1. check the source host information is correct.
  2. check the signer node public key is correct.
  3. make sure to sync from the same host.

This trustless replication results in the users being able to freely distribute their data everywhere that matters while keeping control.

NOTE: Don't be scared of the term "node". A Vapor "node" is simply a web server and there is no P2P node you have to run. Everything takes place over pure HTTP.

The more the API gets replicated in the "Vapor network", the more tamper-proof it becomes through network effect.


6. Benefits

Data decentralization is but just one problem Vapor solves. To fix the rest of the Web, we need to tackle tricky issues surrounding incentives and ownership.

6.1. Problem

What problems does a "Bitcoinized HTTP" solve for HTTP?

The HyperText Transfer Protocol (HTTP) was originally invented to deliver static documents over the Internet and wasn't designed for the complex applications we have today and lacks important features on the protocol level:

  1. Lack of Native Authentication: The lack of native authentication gave rise to the so-called "centralized client-server data silo" we are all familiar with. Because authentication is privately handled by each service provider's proprietary system, it is not easy for people to move their data around across multiple applications. Because all authentication and data manipulation is handled privately by the application provider, the users must trust the goodwill of the application provider. For example, if a hacker or an unethical employee of the service provider connects to the app database and updates someone's game items, there is no way to prove that the person originally owned those items.
  2. Lack of Native Monetization: The lack of native monetization meant there was huge friction for service providers to monetize their business unless they actually sold something over the web. This led to the web becoming largely powered by gathering eyeballs and serving them advertisements. Because the ad business model only makes sense at scale, this created a universal incentive structure where low quality bulk attention is incentivized over high quality content. This is not only toxic but also not the most efficient way to capture value, easily sidestepped by ad blockers and something that will degrade further as the public becomes more active in protecting their privacy.
  3. Single Point of Failure: Because everything is stored by a single party (The application provider) privately, if that single party gets hacked, all user data is lost. There is no easy way to replicate data across multiple parties.


6.2. Solution

Let's see how wrapping HTTP in a Bitcoin authenticated Bitcoin transaction makes everything better:

  1. Decentralized Authentication: Instead of using a centralized user database and authentication scheme on the server side, Vapor uses Bitcoin wallet's asymmetric cryptography to implement decentralized authentication on the client side, getting rid of the reliance on application providers. Since all cryptographically signed API requests can be stored by the users as well as 3rd party Vapor nodes as evidence, service providers cannot tamper with user data.
  2. Monetize through Bitcoin payment: Every API request is a Bitcoin transaction signed with a wallet identity private key. This fully preserves ownership of every API request transparently. This means there can be many ways to monetize every single API request ever made. For example, you can extend Vapor requests by attaching complex Bitcoin transaction inputs and outputs, including P2PKH (Pay to Public Key Hash) transactions, token transactions, smart contract transactions, and more.
  3. Programmable HTTP requests: Because Bitcoin scripts are programmable, you can program Vapor requests to be routed to different resources depending on how the Bitcoin script execution resolves. You cannot implement programmable routing with HTTP alone, but by wrapping HTTP requests inside a programmable Bitcoin transaction, it becomes possible to programmatically route HTTP requests at will, even based on Bitcoin micropayments. Basically, by optionally integrating with the blockchain you can enjoy the best of both worlds of HTTP and Bitcoin.
  4. Data portability: Every API request can be trustlessly replicated to multiple interested parties. Each party can validate the authenticity of each log item through simple signature verification. This has been impossible with the "legacy" web because authentication information was not transferrable (Every authenticated HTTP request is limited to the specific service provider context through mechanisms such as cookies and sessions). With Vapor, even the authentication information is transferrable because each API request is a self-contained bitcoin transaction packet which includes the self-verifiable authentication information of a public key and signature.

7. World Wide Bitcoinized Web

By supercharging HTTP with Bitcoin, we get a lot of powerful features.

7.1. Decentralized HTTP

There have been many attempts at building a "decentralized web", and all of them require running some special P2P network (for example, every request must happen on some "blockchain" system or an obscure P2P network), which makes it difficult to build mainstream production-grade applications with high performance.

Vapor does not require anyone to run some "decentralized network" on their machine at all times.

Vapor is just HTTP. Think of it as building a regular web app but swapping out the centralized authentication and logging system with a decentralized version powered by Bitcoin tech.

Any web developer can take their existing web app and "Bitcoinize" it to build a decentralized web app.

  1. No "decentralized network" setup required: There is no P2P network you need to be connected to at all times. Vapor is literally just HTTP. You can even run a Vapor app locally on your laptop.*
  2. No Bitcoin knowledge needed: Vapor is designed for regular web developers. You do not need Bitcoin or crypto knowledge to build decentralized web apps. . If you can build web apps, you can build decentralized web apps using Vapor.
  3. No Bitcoin needed: Vapor only uses Bitcoin transactions as data packets. You do not even need to own Bitcoins.

Note: you can optionally connect to the Bitcoin network for advanced features such as micropayments and immutable timestamps, but these are not not necessary to build a Vapor app.

The only requirement is a Bitcoin wallet, which will be used to sign API requests.


7.2 Monetized HTTP

Because every API request is explicitly signed by:

  1. The User Wallet
  2. The Vapor Node Wallet

It is trivial to transfer Bitcoins to both. This means the service provider can easily generate revenue through Bitcoin micropayments, and the users can also easily generate revenue from their data.

The frictionless monetization will change the incentive dynamics for the service providers and spur new creative business model innovations.


7.3. Money Programmable HTTP

Because every HTTP request is wrapped in a Bitcoin transaction, it becomes possible to encode the API routing logic in the transaction itself.

Additionally, because Bitcoin script is programmable, the API routing itself can be programmed and driven by micropayments.