This document contains the specifications for the Client software. The Client software is targeted to run on small IoT devices like the Raspberry Pi, and also desktop computers running a Ubuntu Linux VM in VirtualBox. In this way, the Client software can turn any computer capable of running Docker into a VPS. That device can then be rented out on the P2P VPS marketplace.
Client software is defined by the following high-level features:
- Governor
- Docker container with SSH
- Persistent Storage
- Encryption
- Deployment Packages (pre-configured scripts for setting up apps like webservers, file sharing, etc.)
- Testing
The sections below detail the specifications for each of these features:
The primary purpose of the governor software is to manage the Docker container and communicate with the P2P VPS server. This application runs on the host operating system, outside the Docker container. It plays the following roles:
- It reads the
device-config.jsonfile and registers the Client device with the P2P VPS server. - It builds the Docker container with information returned by the server after registration.
- It launches the Docker container after being built.
- It sends a heartbeat signal to the P2P VPS server every 10 minutes. The server responds with an expiration date.
- When the expiration date is reached, the governor software stops the Docker container and wipes the flash drive. It then reregisters itself with the P2P VPS server.
This workflow diagram illustrates how transactions are initiated and managed:
![]()
A Docker container is generated by the p2p-vps-client.js governor application.
The Owner initiates the creation of the Docker container by registering the device
in the Device Management Dashboard. They are given a GUID, which they
then copy to the file device-config.json. The application p2p-vps-client.js
reads this file and makes a REST API call to the server to register itself.
After a successful registration call, a reverse SSH tunnel to the Docker container is established. The server returns a computer generated username, password, and port, which is used to access the Docker container command line interface (CLI) over an SSH terminal (like putty). Th username, password, and port are passed to the Renter in the Fulfillment phase of the rental contract purchase, in the OpenBazaar application.
When the contract is terminated, the Docker container is destroyed and all persistent data wiped. A new Docker container with new login credentials is generated for the next renter, and a new listing is added to the P2P VPS OpenBazaar store.
Below is an illustration of the Client software stack:
-
The p2p-vps-client.jsgovernor application communicates with the Server and controlls the Docker container. -
client-connect.jsruns inside the Docker container and establishes the reverse SSH connection with the server. -
Renters are sandboxed inside the Docker container. They still have access to the devices' computational power and resources, but their control of the device is limited. The environment is easy to destroy and recreate.
-
Because there is a node application running both inside and outside the Docker container, and because they can both communicate with the server, secure exchanges can take place. This means things like encryption keys and passwords can be passed without ever being written to disk. This allows various forms of on-the-fly encryption, which is important as anyone with access to the physical device could access the inside of the Docker container.
Persistent storage can take many forms, but a USB flash drive will be encouraged, as SD cards have shown reliability issues. Most IoT devices, like the Raspberry Pi can boot off an SD card. Extra storage can easily be accommodated through USB flash drives or even USB external hard drives. 64GB Flash drives will be a (rough) standard due to their availability and low prices.
The flash-storage client has been designed to automatically find, format, and mount
persistent storage.
Encryption managed by the Device Owner has been explored, but found ineffective. It will be best to put the responsibility and encryption keys in the hands of the Renter. Owners will be under no obligation to provide encrypted drives. However, instructions for setting up LUKS encryption inside the renters Docker container will be provided by this project.
- This is an excellent guide that can be adapted to encrypt persistent storage in a Docker container.
A collection of scripts will be made available to renters. These are preconfigured shell scripts or some other type of package manager that allows them to quickly deploy common web services like NextCloud, a blog, a webserver, a single page application development environment, a TOR node, an OpenBazaar server, VPN software, etc. Easy scripts to deploy many of these use cases.
This project will rely on user contributions or 'corporate sponsorships' for this section. If interested, please see our Contributing README or contact us.
Unit testing is initially planning to use Mocha, but we could use any platform at this stage. We could really use help with getting a solid unit testing library in place for Client software. Contact us if you'd like to help with this effort.
