Hosting Services

From BiblePay Wiki
Revision as of 22:55, 13 September 2021 by Admin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

BiblePay provides an alternative to big-tech empowering your firm to create turnkey decentralized blockchain solutions using scalable, resilient, powerful core technology that is inexpensive and easy to code against.

We currently provide:

  • File Hosting for large and small files (mp4's, mp3's, pdf's, images, javascript, etc) with a free CDN.
  • Sidechain data storage (Using NoSQL compatible database key-value pair for your inserts, updates and deletes), allowing us to host your metadata
  • Transactional e-mail notifications for only 1bbp per e-mail (NOTE: The sender from address will be from the domain)
  • BBP cryptocurrency value transfer directly from your program to a recipient
  • E-Commerce turnkey solution (add a storefront directly on your ASP.NET server without running a full node)
  • C# blockchain business integration (from c#, query your balance, send funds, fund service provider transactions, update sidechain data, host videos), ability to create a blockchain intranet for your organization
  • The biblepay.dll provides an integrated API for your application that allows direct access to our sidechain

Real world Examples

The following real world examples require you to load your c# development environment and make a reference to the biblepay.dll.

  • Reference the biblepay.dll from your project
  • Add your biblepay private key to your applications appname.conf file (this allows biblepay to charge you for transactions automatically)

Host a 100 Megabyte mp4 video with BiblePay from C#

  • Call Sidechain.UploadFileTypeBlob with the path.
  • Our system will return the URL to you, and with this you can permanently use it to host an mp4 video.
  • Our system will charge you approx. 100 BBP per video.

Display 10 public building addresses using BiblePay as a database from C#

  • Call our Sidechain.InsertIntoDSQL with the JSON representation of the building (10 times) corresponding to 10 inserts.
  • Our system honors the schema GetHash() function on your JSON record (meaning that the Hash is configurable). This hash provides you with the ID of the record.
  • We charge approx. 1 BBP per insert.
  • You may retrieve the data anytime for your front end system with Sidechain.RetrieveDataTable, by passing the sidechain table name. You may filter the data using a filter snippet (for example "id='12345'") and you may order the data by a field (ascending or descending).

Deliver New Prayer notification to 10 congregation participants from C#

  • Call our Sidechain.SendMail function with your HTML e-mail body, and recipient.
  • We charge you 1BBP.
  • We send the e-mail, with a result code to your program.

Transfer BBP from user to user inside your program - for example a TIP

  • Let us assume user 1 wants to tip user 2.
  • Call the Wallet.BuySomething function from your program, while the Sender is performing the action (this is so that the Sender can sign the coins.

If you attempt to spend from a wallet that is offline, the transaction will fail because it cannot be signed).

However, your SERVER MAY send BBP to a recipient at any time, from the SERVER wallet. An example of this is our CreateFundingTransaction function.

  • The browsing user will receive a pop-up invoice. They may approve or reject this invoice.
  • If they approve, the coins are signed and immediately sent to the recipient.

Intranet BlockChain Integration for an Organization

  • A company senior manager wants a blockchain presence, for a proof of concept.
  • An in-house developer installs the biblepay.dll in his development environment.
  • The desired requirement is to store 5 building records in the sidechain, for PRIVATE access only.
  • The developer creates a new sidechain table using the BiblePay Entity class, by extending Entity with "XYZ.Building".

The developer adds a few custom building fields.

  • The intranet ASP.NET solution has a new GUI to store a building in the sidechain.
  • On insert, the intranet solution writes to XYZ.Building, and note, BiblePay automatically signs each insert with the XYZ server key (making the records PRIVATE), IE, not accessible from anyone else on the internet - except the server for XYZ.
  • An XYZ browsing user queries for one of these buildings.
  • The BiblePay sidechain compares the XYZ server signature with each record stored in the XYZ.Building sidechain.
  • Since the signature address matches the signer, the data is returned to the intranet application.
  • The user can instantly see the 10 buildings, as if the data came from a normal database.
  • The senior manager is impressed with the RAD development time and a turnkey blockchain solution.
  • The same intranet code may send BBP cryptocurrency between intranet users or into and out of the organization, without running a BiblePay full node.
  • The fees incurred for this demo are approximately 10 BBP (1 bbp per building insert).


How do I make a database record private vs. public

To make a record public, you may store it in either an existing BIBLEPAY schema (such as Video1 which stores mp4 videos), or you may store it in our IBBPObject.Document and it will be public. Public means that if a competing organization starts hosting an instance of BiblePay DLL, and decides to query every record on our sidechain, their query will return possibly sensitive data (it would give them access to all public records). To be specific, let us assume you insert the metadata of 'Star Trek.mp4' into Video1 from your instance of biblepay.dll running in China. User #2 from Texas running another biblepay.dll queries the Video1 table, and because our sidechain is federated and atomic, they will clearly see the public Star Trek record and its contents.

Moving on to make a record PRIVATE, you may use our database to store all of your private data by following this method.

You may extend the BiblePay Entity schema in your program by simply inheriting it and extending it (an example is provided in our source). For example, let us assume you want a Cars table and your company is XYZ. You will add an "XYZ.Cars" table. When you insert sidechain data into this new sidechain, we automatically recognize it is a non-biblepay schema and we make it private. The data is signed using your server key.

Upon retrieval, users who query non biblepay schemas will NOT receive any data, UNLESS that querying server produces the same private key that signed it and a signature match occurs. If a foreign user tries to query XYZ.Cars their server key will fail to retrieve any data. Your data is private when created with a private schema. Of course, if you query your own data from the Server that created it (or one of your farm servers that contains your private key), the results will query successfully.

Tell me about the resilience of your database servers?

Our database server is a proprietary, extended version of a decentralized, sharded, multi-server, multi-region database with inherent atomicity, scalability, fault tolerance and disaster recovery. The server is big-tech agnostic (not tied to one provider), and is currently running in multiple cities. Our sidechain hosted data is stored on over 5,000 hard drives on a decentralized network. Our metadata is sharded and federated for performance and collaboration. We support high performance asynchronous inserts. One way that we maintain high performance is we dedicate one sidechain per data-table, meaning that our server can handle parallel inserts from multiple customers at the same time without blocking.

In the event of a disaster [of data loss], we will have the ability to recover. Fault tolerance will be implemented on Jan 31st, 2022 (it is in process).

Customers may request a data-dump of their data, in the event they want to leave BiblePay. However note that if your data is stored in a private way we cannot dump it without your private Key.

Another warning about data-privacy: If you lose your server private key, you will lose the ability to EDIT any public record created with that key, and you will lose access to all of your private records. No one from BiblePay can recover your key, it must be backed up on your end.

How is security maintained in a federated environment?

Each insert is signed with two keys. First the server signs the metadata record, secondly the User performing the action signs it also. The Server key determines the data access (either retrieved or not retrieved), and the User key determines EDIT/DELETE ability for the GUI. Let us take a real world example: John Doe comments on a prayer on a server in Texas run by Admin#1, and John Doe creates an account on an unchained instance in China run by Admin #2 and then comments a second comment on the same prayer in China on the China server.

Both Texas and China users will see both comments, and will see the *SAME* prayer. However, when John Doe tries to DELETE or EDIT a comment on the Chinese server, the permissions will prevent John from doing this because that Chinese server does not have EDIT permission to the data in the US. In the same fashion, the Texas server cannot edit Chinese data.

However, if Admin 1 and Admin 2 are running separate servers across the world using the same private key, and John Doe imports his Seed Phrases into server #2, he may EDIT his own comment on either server. This proves that the data is FEDERATED, yet permissions are maintained. And due to Atomicity, new federated data is INSTANTLY available from city to city, in an orderly fashion.

Every new data record is hashed and inherently mined, for atomicity.

What Role do the Sanctuaries play in this solution?

Our sanctuaries facilitate instant-send transactions (BBP from program to recipient or recipient to recipient), provide us with microtransaction batch flushing, integrate our UTXO contract, provide UTXO address balance data to our sidechain, and act as a decentralized API for our advanced features.

How is the User Wallet stored?

To facilitate instantsend, social media, tipping, invoices and A/R, we have created a proprietary integrated software wallet inside our biblepay.dll. This means that when you HOST an instance of the BiblePay Unchained web site, you automatically provide a pop-up wallet in the top left corner for a user.

The user may either import an existing key from seed words or generate a new one.

The data is stored RSA encrypted on *their* hard drive. When the program wants to spend money from the user wallet, under no circumstance will we ever be able to open the user wallet unless they approve of the transaction. When biblepay.dll wants to spend, a message is sent to the Wallet of the User, with an INVOICE. The user may always approve or deny the invoice. If they approve, the wallet signs the transaction and sends the TX to the biblepay.dll (through a sanctuary) for funding.

What is the User Primary Key, Public Key, and Private Key?

In contrast to how traditional centralized websites work, where a user is assigned a uniqueidentifier and stored as a database record, and that user ID is their *primary key*, biblepay handles this somewhat differently.

We consider the Wallet Public Key to be the users Primary Key. Therefore if User A has an address of '123', his primary key is always 123 until he loses his wallet. If he stores his nickname, our system stores the user record under '123', and all corresponding data with the user record with '123'.

Therefore, if user 123 upvoted 20 videos and wrote 20 comments, then loses his wallet (by erasing his computer and losing the RSA encrypted private key), next time he logs into BIBLEPAY UNCHAINED, he will be a guest, and will be locked out of his own channel. His comments will never be editable by him or deletable. However he may restore his account access by pasting the Seed Words used to regenerate the wallet.

Note that in this scenario, users do not log in with "Usernames", or "Email addresses". They log in by clicking on their biblepay wallet icon, and the Public Key of the wallet *is their primary key*.

For PR campaigns, and notifications, we may want to ask the users to store their e-mail address on their User Record (again, stored by their Wallet Public Key). Our social media site owner may send an e-mail notification out using this list of users.