Difference between revisions of "Christian Spaces Functional Design"

From BiblePay Wiki
Jump to: navigation, search
(Created page with " <h1>WARNING: DO NOT RELEASE - INCOMPLETE. </h1> Created: July 23rd, 2019 Updated: August 20th, 2019 Author: Rob Andrews This is the functional design document for C...")
(No difference)

Revision as of 20:45, 20 August 2019


Created: July 23rd, 2019 Updated: August 20th, 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. Some of the modules are still classified as TOP SECRET and will be designated with TS names, while others are available for public dissemination.

Why are some pieces still labeled Top Secret? Because in the fast paced cryptosphere, a race exists to be the first community to design and successfully implement a decentralized feature. Two of these Top Secret features are highly sensitive because they are novel (and no one has successfully implemented them yet, or it may be the case they have not designed them yet). Either way, they will be made public at the very earliest - when the working proof of concept is designed and deployed, and BiblePay feels that we can safely implement the feature in the future. This would give us enough of a head start to announce our intention to build it in.

Note that all of the new features coming to BiblePay adhere to our two new standards: STABLEPROD (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 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 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 release our first Top Secret deliverable. We release the ability to demo end-to-end organization encryption. We release examples of c# integration phase 1.

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 'web.biblepay.org/CS/' 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 https://web.biblepay.org/CS/rapture1.mpeg, 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.

Top Secret Feature 1

We have a feature that is slated to be announced before Christmas 2019. This feature will work in tandem with the BWS and should add a distinct and novel contribution to the entire crypto community in a decentralized way. This feature is more aligned with the 2019 deliverables above.

Top Secret Feature 2

We have a future feature, in our future 2020 deliverables closely related to our C# integration project. It is more aligned with Corporate Integration, but cannot be discussed in this early phase (until the proof of concept is released in 2020).

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

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. A complicated example is if your org has two objects: manufacturing and IT, you may create : Organization - Jupiter Permission1 - Manufacturing Permission2 - IT User1 - John User2 - Jane Johns permissions: Jupiter R, Manufacturing RWAD, IT none Janes permissions: Jupiter R, IT RWAD, Manufactuaring None

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

Let us work through an example where John Doe and Mary Jane are hired by Jupiter, and each work in different departments, having distinct access, and at one point John is fired, but access should remain for Boar (the owner of the organization, and Mary's boss).

First Boar creates an Org keypair (create organization Jupiter). He records the public and private key. Then Boar creates two departments: IT and Marketing. He assigns John to IT with RWAD, and Mary to Marketing with RWAD. The non encrypted permission tree looks like this for John: Org-D660(Jupiter)->Dept-A123(IT)->Permission->RWAD(R/W/A/D).

Day 1:

To encrypt contents, we coalesce the Organization Key + Read Key + BMS Key, to arrive at a key that can be read by anyone with a READ permission in Jupiter.

John would like to upload one JSON record with 4 fields for IT in public schema (Contact Record: XYZ Inc, 1001 Main St, Houston TX).

Each field is encrypted with AES256 using the key described above.

During a READ operation by Boar (the owner of Jupiter), we will need the Org Key plus the Read Key plus the BMS key.

Boar will ask to read record #1, contact info for XYZ.

During the read operation, the BMS system will request the Read key for the BMS permission cache for BOAR and retrieve it.

BMS will only provide its system key if Boar is still employed at Jupiter.

If so, the Boar Org key + Read key + BMS key will coalesce to a key that can view the contact record.

However, note these very important distinctions: The Organization key is not stored in the BMS or in the chain; it is stored on Boars hard drive, and on Mary and Johns drive. TODO: We will discuss how to share the org key among org users.

So in all cases where encrypted org data is being read, even the BMS itself cannot decrypt the data (only members with Org keys may decrypt the data).

Next, let us examine the case of firing John.

As of today, John can read the Contact record for XYZ but Mary cannot (due to permissions).

This afternoon John is fired by Boar.

The moment this happens, after Boar revokes Org permissions (and user permissions) from John, the following occurs:

John still has a copy of the Org key on his hard drive. When he attempts to view the contact record, the BMS will not provide a Read Key OR a BMS key (due to permissions missing, and also due to him being fired as a user).

Therefore, the decryption will NOT be successful, because all 3 parts are required for each column to decrypt.

Additionally, a sanctuary owner who has access to the Org permissions schema for Jupiter will ALSO not be able to brute force a read of the contact record (Why?).

Because the sanctuary owner will not have the Org key on their hard drive.

Next example: Let us examine what happens if John was not fired but instead if he was moved to the Marketing department.

The moment the IT permissions are revoked, the contact record can no longer be viewed by John as now he has : BMS Key + Org key (but he is missing the READ key for the Contact record in IT).

Therefore in this case, the technology stopping him from decrypting the columns will be the Sanctuary itself (Sanc will read the record, sanc will find John has no READ permission, sanc will not provide a BMS decryption key for the read phase).

.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.