Christian Spaces Functional Design

From BiblePay Wiki
Jump to: navigation, search

Created: July 23rd, 2019
Updated: September 12th, 2019
Author: Rob Andrews

This is the functional design document for Christian Spaces. This document encompasses the requirements, design, and technical implementation from a high level required to build new modules for BiblePay.

Note that all of the new features coming to BiblePay adhere to our two new standards: Stability - (this means these features will run in their own process, and not risk taking down BiblePay), and SCBL (Soft consensus business logic prevents forking the consensus of the chain).

Christian Spaces is the name of the core wallet feature that allows a user to navigate the BiblePay decentralized web (, create websites, testimonies, and upload/download content within their own CPK sphere, or vote on/download content in any area.

BMS (BiblePay Middleware System) is the acronym used in our IT department for the Product from an IT perspective. BMS is Sanctuary middleware. It contains: BWS (BiblePay decentralized Web Server), RDNS (BiblePay Reverse DNS), BUG (BiblePay Upgrader), DSQL (BiblePay Decentralized SQL Server), Christian Objects (JSON representations of objects that propagate over the BWS through DSQL), Views (Representations of BiblePay Tables), DR (Disaster Recovery Mitigation), TDRL (GDPR compliance and MPIAA/RIAA - a takedown request list), BMSA (BiblePay Middleware Server Angel), UAL (User-App-Layer, a private namespace in javascript for key signing and web purchases), and TT (Christian Treasure Trove).

Christian Spaces from a 50,000 feet view

    Christian Spaces will allow the user to perform these new functions:
  • Navigate the BiblePay decentralized Web, using real human readable SEO URLs
  • Browse Christian Lists of things like Videos, Gospel Music - Hosted on our Sanctuaries
  • Vote on these objects - this affects the future view/sort of the page for everyone else
  • Purchase things with real BBP on web pages we host in a decentralized way (using a custom BBP address per user)
  • Corporations will extend BBP for their own private white label use in c#
  • We will invite c# devs to Extend BBP
  • The ability to upload Christian Content into our Decentralized Web
  • The ability to create a Christian Treasure Trove - Saving data at risk of being scrubbed from the web
  • The ability for an organization to encrypt sensitive data, and allowing only the org viewers to see the data in decrypted form
  • The ability for us to store our expense/income data for audits and disaster recovery in a decentralized way
  • The ability to lease files - providing a revenue stream for BiblePay, cementing us as a utility

What can I expect this year?

In 2019, we expect to release two phases of Christian Spaces.

Phase 1 - October 2019

In Phase 1, we anticipate asking the users to search and save data at risk of being scrubbed from the web. We will release version 1.0 of the DSQL, BIPFS, BWS, BUG into TestNet in beta testing mode. The users will be able to begin using the features and entering bug reports in TestNet.

We will release the ability to navigate the decentralized web (to limited destinations), view lists of Christian objects. Perform voting on these objects and viewing the updated lists and voting results. Uploading Christian content (videos/music). Decentralized DNS 1.0 will be released. C# middleware, auto-upgrades, BIPFS (BiblePay IPFS 1.0) will be released. A basic version of file leasing, paid purchases will be released.

Phase 2 - December 2019

In Phase 2, we will release DSQL, BWS, BIPFS to prod. At this point we anticipate using our Rapture lists, Gospel Lists, and our Decentralized Prayer Requests Blog in production.

Phase 3 - June 2020

In Phase 3, we plan on revealing our corporate integration features, and our secondary plan for BiblePay Revenue.

Christian Objects from a 25,000 feet view

Christian Object Lists

HTML5 data lists containing Christian Objects - Gospel Links, Rapture Videos, Healing Videos, Tutorials for Healing/Deliverance, User Videos, User gospel audio files, Christian Audio content

Christian Object Voting

The ability to right click and vote on any Christian Object (Supports multiple choice polls), and viewing poll results will support both Polls by Christian Weight or Distinct count.

User Reputation Scores

User Reputation Scores Phase 1: In the beginning, this score will start as your average weekly GSC reward amount converted to a weight and this weight will affect Christian Object voting results.

User Reputation Scores Phase 2: Create a discussion thread for ideas on a score that is based on user behavior (Zeal, teamwork, participation, etc).

Christian Data Treasure Trove

Hosting of Christian Secrets, including secret Vatican files, Preserving Christianity, Preserving Christian Videos and Data, Preserving Christian Articles, Preserving files that are risk of being scrubbed by the AntiChrist, Preserving files that are useful in the Great Tribulation. The idea is to locate any sensitive data that you believe is edifying for Christians (or scan it if you have it at home) and upload it to our Treasure Trove. We will host it on our Sanctuaries for the world to find on our WWW portal.

Decentralized Web Server (BWS)

We will expose our Christian spaces to the entire WWW (with SEO results) so that it can be searched by google. We will host these files on our sanctuaries using our own decentralized BiblePay web server. This will also allow users to browse any individual Christian Space, testimony, and our Christian object lists.

We will implement a web server on each sanctuary, and expose the decentralized web at the address '' where CS is the Christian Space being searched. Any user can create a new Christian space and upload content. Content will be leased however with a certain BBP charge per month for the data (otherwise it will be purged).

Decentralized RDNS (Reverse DNS)

We will have our own decentralized Reverse DNS server that will automatically resolve file hashes back to names, overcoming a major limitation in crypto. What this means is if you upload "Rapture1.mpeg" to BiblePay (with metadata tags), this will be hashed to file hash "abcde1". However, in your Christian space on the web, if a user searches for, the file will be served with its original name (meaning our users can create real web sites) and SEO will work.

BiblePay BIPFS (BiblePay - Interplanetary File System)

We will write our own version of IPFS to meet additional requirements, enhancing IPFS to perform additional functions.

First, I want to clarify IPFS is great and the core project devs are great, and the initial implementation is great.

Our Additional requirements: Integrate the code into our c# process, so that we can maintain the changes. Extend IPFS to allow reverse DNS resolution per IPFS hash. (This means that the server will not need to make a high-latency call to a DNS server to reverse the hash to the name.) Allow deep nested hierarchical names to be based on our Christian Spaces naming convention (this allows a normal web-site hierarchical structure, for referential nested filenames. For example, if the site is written as "cs/bbp/scripts/js1.js" it will still resolve to the correct hash, and serve the correct nested file.

Enhance IPFS to be resilient enough to find missing files and re-replicate, or re-replicate missing files, while constantly checking for missing files.

Create a robust interface between BiblePay and BIPFS to allow enforcement of charges per hosted file, and purging of unpaid files.

Create a robust log of charges per signed key, allowing a true leased file system to be exposed and hosted.

Create a Christian Object accessible by CS# devs to expose both json, file pointers, name resolution and charges and tx info to the original upload so we can provide a professional solution for leased files on our platform.

Enhance BIPFS to respond to DCMA MPIAA and RIAA takedown requests and GDPR requirements.

We can also expose these to our corporate integration side.

User Security Abstraction Layer

Part of the design consideration to make this project successful is the ability to protect local user information, but also allow innovation for the new cutting edge features.

The UAL will have a private namespace, and will allow the user to store a certain amount of BBP privately (for web purchases) using a 4 digit pin. We will make a very clear announcement on how to transfer BBP to the private purse and how to access it. This will allow web purchases. We will also support end to end column level encryption in UAL.

One example of this is if the user has a JSON object inside their own organization and they want to protect it for their org eyes only, they will be able to set an attribute. This attribute will encrypt each column as it is uploaded (from the UAL). Each org member will be able to view the column only on their own screen (as javascript will decrypt the AES256 columns in real time in the UAL in the private namespace).

Automatic Sanctuary Code Upgrades (BUG - BiblePay Upgrader)

The BMS (BiblePay middleware system) code that hosts our decentralized web server and BIPFS server will be compiled in a cross platform compiler (with c# source code) that runs in Mac, Windows Or Linux, and the code will be available in Github. However one distinct feature we will offer over other c# integrations is auto-upgrading code. By default, the sanctuary will upgrade its own DLLs and middleware, and restart when the mandatory version increases. This means the administrator will not need to do any work. However we will offer a key to shut this feature off if the admin wishes to upgrade their code manually. We will also automatically monitor for duplicate copies and ensure one single copy is running in memory.

Org permissions and Data Encryption (Coming in 2020)

A user may create an organization keypair. They may create additional keypairs under the Org with a permission name. Each permission name also has 4 attributes: RWAD.

In this way, a user with appropriate org permissions may edit the ability for other users to access their data.

When Jane tries to read columns for Manufacturing, her screen will not successfully 'show the values' as they will not even decrypt.

However John can not only View the columns, but he may also Edit, Write and Delete objects and columns inside Manufacturing for Jupiter.

Note that users outside of Jupiter (including owners of BiblePay, owners of Sancs, or Anyone other than Jupiter) will never be able to view Jupiter columns as the AES256 encryption applies to all of us. If you lose your key, no one at biblepay can ever recover the data.

C# Integration

This long awaited feature will allow BiblePay to expand by tapping into the vast corporate availability of C# devs. Our c# devs will have the ability to create HTML5 middleware. This middleware consists of programs in custom namespaces responding to web calls. For example, if we wanted to create a BiblePay feature requiring customized UI wizards, we could have our developer create C# methods that expose these UI features.

The primary change with c# integration is we expose our entire RPC library to c#, allowing corporations to white label our wallet and create proof of concepts internally that allow them to write custom reports, spend BiblePay programatically and monitor transactions programatically. This is useful for corporate integrations.

Christian Spaces from a one-foot view (Technical Design Requirements)

This section is for our devs. We will modify this area as we add each requirement and each milestone and target deliverable date.

BIPFS Sidechain

The sidechain consists of a block sync module, a block forwarder, a JSON interpreter, a data encryptor/decryptor, a hasher. Each JSON post is hashed and organized by its timestamp in daily folders. Security is maintained by relying on signed block posts by people with positive BIPFS balances. Each JSON post results in a debit to the BIPFS balance. Unsigned or illegal posts will never be propagated. The sanctuaries will share a list of other BIPFS nodes (this is accomplished by the Core wallet daily Stratis export).

Daily CPK Export

The daily export will dump all CPKs, CPK weights, BIPFS nodes into flat files for consumption by BIPFS.

BWS decentralized web server: We overloaded Kestrel in .netcore in c# to be our web server. Our server has been extended to allow reverse hash resolution (IE customized reverse DNS resolution). We also support 404 pages and middleware callbacks.

BiblePay Core RPC commands

The wallet will be modified to allow single, multiple, or folder uploads into BIPFS. When the upload occurs, the wallet will sign the CPK and the upload will succeed if the CPK has a BIPFS credit balance.

BMS RPC commands

The core wallet will be modified to pass through BMS commands through the RPC and to the BMS, and allow BMS's reply to pass through the RPC.

Web purchase or Web Tipping

We will expose methods in the UAL (user abstraction layer) in javascript that will access the private web wallet designated (single address keypair). This method will allow the user to sign over BBP as a web tip or a web purchase. When the buy button is clicked, we will verify the users pin confirming they accept the purchase. If they continue, we will sign the transaction with the private key (this key will be explained in great detail). Then the sanctuary will broadcast the transaction resulting in a payment to the merchant or user.

Constant keypair authentication

To allow the most user friendly experience, while browsing the Biblepay web, you will not sign in with credentials. As each page is processed your browser will sign your CPK, allowing the BMS to know your CPK weight and CPK nickname. This will allow you to vote on objects or buy objects without logging in. This will also allow our end-to-end encryption to work for organizations. If you access the BMS from outside the core wallet (IE from an anonymous browser), the protected features (such as encryption, voting, or session protected) will not work. However, many pages (such as Christian content, testimonies) will still be available to the outside world (for edification, SEO and PR).

Organization end-to-end encryption (2020)

We are working on end to end encryption. This design, from a high level works by transmitting bytes that have been encrypted on two levels. The first level of encryption prevents eavesdropping at the sanctuary level. Meaning that those hosting Sanctuary BMS's cannot decrypt the organization data. The second level is done at the organization level. Meaning those who have revoked organization permissions will no longer be able to decrypt data for their org.

This decryption is done on the data itself, but not on the schema. Meaning that man in the middle attacks are not possible.

.Netcore debugging

This solution will be cross platform in c#. We will recommend VS2019 (Microsoft) as the IDE. We will configure the solution to compile cross platform into Mac, Windows and Linux. To debug, we will debug on Windows. To deploy, we will write a customized deployment wizard and built in the code for it so it is auto upgraded by the Sanctuaries. The Sanctuaries will occasionally check for a newer version. If one is found they will call out to BMSUpgrade.dll, load it, the BMSUpgrade will kill the BMS process, then upgrade the DLLs from its own web repository, then launch a new copy of BMS and exit.

Technical Explanation Videos

In this section, I will be releasing short explanation videos of each concept. This will give everyone an idea about what the concept's purpose is and how we are planning to design and implement the feature. This also shows where BiblePay is going in the future.

Technical Explainer Videos
BMS Intro
About Scalability, Latency, and demo uploading an entire sample web site
About Schemas
Freshening DSQL Files, Reverse DNS
About DSQL Views
About Auto Upgrade (BUG - BiblePay Upgrader System)
About Ansi 92 SQL Queries
About Christian Objects
An example of a large video upload
About DSQL Transaction Fees and BIPFS Fees
About Web Authentication
About Disaster Recovery
Cross Platform Compatibility
BiblePay Upgrader