Impervious API: Overview

A New p2p, Censorship and Surveillance Resistant Internet Standard

Impervious API: Overview

A New p2p, Censorship and Surveillance Resistant Internet Standard

7.9.21

As we approach the general release of the Impervious API and Hack for Freedom, on August 4th, 2021, we thought it would be helpful to discuss in greater detail the Impervious API and some of its immediate applications. The ultimate goal of Impervious is to enable a new p2p, censorship and surveillance resistant internet standard.

Impervious API is a programmatic layer that sits on top of the Bitcoin Lightning Network, i.e. "Layer 3." Developers can leverage the Impervious API to easily build cryptographically secure, streaming p2p data transmission into their applications and services.

The benefits of creating resilient, cryptographically secure, p2p data transmissions channels - via Impervious - are manifold. Circumventing digital intermediaries and establishing p2p data transmissions is a panacea for consumer privacy, data security, censorship resistance, and countering surveillance.

Applications that can be built on the Impervious.ai API are essentially boundless, but include p2p streaming video, podcasts, micropayment-based services, broadcasting events, news reporting, and VoIP-based communications. Moreover, existing services and applications can bolster user privacy and security by default streaming data p2p wherever possible, thereby minimizing data retention and control by centralized third party services.

For both the general API release and Hackathon, we'll share easy to follow developer documentation, demonstrate clear code examples for each of the RESTful/gRPC endpoints and provide explainers on how to read the websocket stream. Example applications and diagrams will also be provided.

Section 1: Impervious API - High Level Overview

  • Both Alice and Bob have Impervious nodes (IMPNODE) up and running.
  • Alice wants to send the coordinates of the secret meetup place to Bob.
  • Alice sends the latitude/longitude coordinates in a message containing Bob's node name.
  • A second later, Bob sees the message and responds with an acknowledgement.

In this example, the Impervious nodes were able to pass a message to each other over a protected network. This network provides confidentiality, integrity and anonymity services to the Impervious nodes. Along with the messages a single Satoshi was passed; a Satoshi is 1/100 millionth of a Bitcoin.

Section 2: Impervious API - More Detailed Overview

Both Alice and Bob have Impervious nodes up and running.

  • These nodes command and control their own local Lightning Node Daemon (LND).
  • Both LND nodes have channels open and filled with inbound/outbound capacity to other Lightning nodes.

Alice wants to send the coordinates of the secret meetup place to Bob.

  • The Impervious API has a RESTful/gRPC interface for Alice and Bob to write VERY simple code in order to send a message.

Alice sends the latitude/longitude coordinates in a message containing Bob's node name.

  • The message is passed to the API, and the Lightning Network routes to Bob.

A second later, Bob sees the message and responds with an acknowledgement.

  • Bob has simple code to monitor the output of his Impervious node and then perform actions. In this case, Bob simply has messages appear on his terminal.

Section 3: Impervious API - Granular Overview

Both Alice and Bob are have Impervious nodes up and running.

  • These nodes command and control their own local Lightning Node Daemon (LND).
  • Both LND nodes have channels open and filled with inbound/outbound capacity other Lightning nodes.
  • Both Alice and Bob's nodes need to make sure there is Lightning route available to each other. They need to have channels which connect to nodes which eventually connect Alice and Bob.
  • Alice and Bob have performed an Impervious federation action, which authorizes a far end node to communicate with a local node. The Impervious federation sets up a key exchange for message signing.
  • Federation is performed before any other messages are passed, and then refreshed at t/2 before the time-live-expires.

Alice wants to send the coordinates of the secret meetup place to Bob.

  • The Impervious API has a RESTful/gRPC interface for Alice and Bob to write VERY simple code in order to send a message.

Alice constructs her message into a standard JSON body:

{"message": {"lat":"27.9881 N"},{"lon":"86.9250 E"}}

Alice sends the latitude/longitude coordinates in a message containing Bob's node name.

  • The message is passed to the API, and the API routes to Bob.
  • The API RESTful endpoint on Alice's IMPNODE is a standard HTTP POST at: alice_impnode/message/ with the POST body containing the message, Bob's IMPNODE:pubkey, and Alice's IMPNODEID, for messages back to her.

A second later, Bob sees the message and responds with an acknowledgement.

  • Bob has simple code to monitor the output of his Impervious node and then perform actions. In this case, Bob simply has messages appear on his terminal.
  • Bob's code monitors the asynchronous receive websocket stream for protocol messages with the "message" tag. Once detected, Bob's code parses the received JSON and then prints the coordinates to his screen.

Most of Impervious's API calls are similar to the above scenario, send data in, get data out. RESTful into a local node, is transported into a websockets output on a far node - and vice verse. Developers will be empowered to build their own protocols and rich applications across the Impervious API from node to node. Want to setup a complicated end to end key exchange over a friendly API? Done. Want to ask a far end node its health and status. Done. Want to programmatically send a far end user an authentication token? Done. Want to send a payment to a node on a repeating timer? Done. How about secure vaulting of API keys/passwords/tokens in a remote node? Done. Want to <insert imagination> to magically appear somewhere else in the world? Done.

Not all API's are node to node, we also have local node command and control API's! Want to see a full status of your node? Done. Want to stop/start a channel? Done. Want to do any typical LND command? Done. Want to receive alerts if your node is running out of channel liquidity? Done.

Section 4: Why have an API?

  • Want to earn fees for specific content?
  • Want to forget about transport, complicated encryption and simply send an unstoppable message across the world?
  • Want to do more with your Lightning Node, other than setting up a channel with your friends?
  • Want to easily build applications for your customers who wish to use the power of Lightning?

Things one can build with our API:

A Lightning metered VPN...this is a HOT TOPIC right now! We'll explain how we built ours in another blog post, and show you how to build your own. You can compete with us, we challenge you to build cool stuff!

  • A sandbox VPN to test will be made available for Hackathon entrants. The sandbox VPN will have a web page for one to view and test against.
  • Content paywalls. Want this awesome picture of my cat eating a marshmallow? That'll be 25 sats!
  • A decentralized command and control system for your network of machines.
  • An easy API to implement Satoshi's back for purchases.
  • Streaming payments for video/audio streams.
  • Decentralized authentication system, passing LSAT/JWT tokens around.
  • Micro hosted websites directly inside of Lightning.
  • Remote API calls. The ability to call a third party API call using a far away Impervious Node with authentication tokens vaulted in a far node.
  • Hidden services, similar to Tor Hidden Services but with built in payment system (i.e. incentivized Tor).
  • Incentive based systems. Do this or that, then get Satoshis back!

Thanks for reading the Impervious API overview! We strive to help developers maximize their creativity when building amazing products and services for the new p2p, cryptographically secure, streaming internet.

P.S. - Don't forget to sign up for the Impervious Hack for Freedom 2021 - Hackathon - (Click Here)!