Roadmap Addendum 2022

From BiblePay Wiki
Revision as of 18:37, 5 June 2022 by Admin (talk | contribs) (Created page with "<p>Potential Roadmap Addendum for 2022 (Pending Vote) </p><p><br /> When BiblePay was founded, I had a very simple vision: Deflationary reward, facilitate money transfer, min...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Potential Roadmap Addendum for 2022 (Pending Vote)


When BiblePay was founded, I had a very simple vision: Deflationary reward, facilitate money transfer, mining on commodity PCs with no monopolies, a 10% tithe to orphan charity, cryptocurrency retirement accounts, and integration with c#.


Although we fulfilled these things (for the most part), the crypto landscape changed violently in this 4 year time period. We moved from KJV-POBH to RandomX to ensure fair mining and we gained merge-mined rewards (a plus for miners). Our deflationary emission schedule is still a hidden diamond-in-the-rough (I believe investors have not discovered us). Our 10% tithe to orphan charity is an overwhelming success with over $275K given. Portfolio Builder appears to be a useful tool for crypto based retirement accounts.


But since the coronavirus, I've seen an emergency level need for more decentralized web3 features, and this is our time to capitalize on this market. In 2020 we saw high ranking political figures get censored. Coronavirus information was censored. So Big-Tech and Big-Media held back information from the public globally. We saw the dangers of centralized social media systems (you can be unplugged, censored, banned, and ostracized if you go against the official narrative). Big-Tech also censors apps - we saw Parler get censored from the App Store. There is an information war going on, information that is suppressed on search engines and social media sites but alternatives have cropped up, such as Odysee and Rumble. Political pressure caused a takedown of certain domain names (cloudflare removed 4chan for example).


The problem statement includes:

- Provide a decentralized database storage solution (such as a cluster of database nodes) - not hosted on Big-Tech

- Provide an s3 compatible storage alternative (not hosted on big-tech or centralized cloud providers)

- Provide a Video Stream solution (not hosted on big-tech)

- Make the documents censor-resistant (except for illegal or copyright violations)

- Make the data decentralized (no single centralized entity can remove it)

- Provide decentralized delivery (no single point of failure) for HTTPS delivery (IE no single CDN)

- More solutions based on Freedom of Speech, Constitutional Rights, Freedom of Religion


I believe now is the time for BiblePay to take action and become a force for good in this area. We can be a network that helps promote freedom of speech, freedom of religion, sharing censor resistant data, cost effective storage and we can do all this in a decentralized way.


One of the scalability issues that came up on our recent conf. calls, which is an immediate roadblack, (I had to work through this because its a tough decision), because we want to maintain our minimum 10% tithe to orphan-charity no matter what we do - it is our mission statement. The challenge is we currently have this excellent rule in place where each Sanctuary (our flavor of masternodes) must sponsor one orphan each. But the problem is it presents a scalability problem for our next-gen web3 network. Basically we need to have new sanctuary nodes enter the network based on public demand for video. If for example a new client stores 1tb of video, the video pinning costs will drive up our price, but the sanctuaries would not necessarily respond (by automatically adding new nodes) because of the friction involved in sponsoring an additional orphan per node. So this part of the proposal is to move back to our original design for orphan expenses. The way that worked originally: 10% of our blockchain emissions come from our monthly superblock and we send that to our voted charity proposals. We would remove the sponsorship requirement from our sanctuaries.


Then we would ask each new sanctuary to provide a machine with a minimum of 4 cores, 395Gb hard drive (and this is a distinct machine per sanctuary) to our network, in exchange for the sanctuary reward. This would cause our network to grow based on supply/demand. The more our price is worth the more nodes we have available.

This would also bring back the "HODL" equation that many crypto enthusiasts follow that basically works like this: If a coin has an ROI of NN% per year because of current conditions, and a staking reqt of 4.5MM BBP, the free market will simply invest (or HODL) into the coin because of the ROI. I'm stipulating that this change will prime us for growth. (And over the long term, growth allows us to sponsor more orphans from the monthly superblock).


What will happen to the existing orphans? We will continue to pay for as many as we can afford out of the monthly budget. Theoretically, this change is relatively lateral because money is just being moved from one place to another.


Additional Changes:


BiblePay will develop a custom Video Player branded with the biblepay logo. It may be embedded in any web site as a nice looking control.

An example is here:

<a rel="nofollow" class="external free" href="https://social.biblepay.org/media">https://social.biblepay.org/media</a>

Take a look at the Media video. This video is hosted on two of our Sancs, using our new custom written opensource video player. This player is capable of playing a decentralized HLS stream (meaning that the packets can be picked up from more than one sharded sanctuary). Test out the skip forward and back works lightning fast and the quick start of the video on mobile devices is as fast as rumble and youtube.

This technology requires us to write new code and also requires new tech to be deployed to the sancs. Each sanctuary will be required to run biblepay plus one additional program called the BBP-BMS. This BMS is BiblePay's decentralized CDN. The CDN pulls down pieces of videos locally that belong on the sanc (this makes our biblepay network into a RAID drive). When a host requests a piece that is missing, the node is smart enough to get it in real time from another source that has an extra piece.

This BMS will automatically upgrade itself when the code changes (to make it easy to administer).


The following changes need to be made over the next quarter:

- Make the BMS smart enough to upgrade itself, smart enough to not fill up more than 90% of the host hard drive

- Make the BMS monitor its surroundings and send Sanctuary Metrics back to the rest of the network (for POSE)

- Ensure the BMS acts as a CDN for our video streaming service

- Deploy BMS into Alpha in testnet, and let the testers rigorously approve this for the next mandatory

- Promote BMS to Prod

- Modify the core wallet to change reward %s to remove the orphan requirement, honor the BMS POSE signals (IE pose ban sancs who do not meet the reqs for video streaming), test the daily and monthly superblock %s to ensure Monthly superblock emits 10% for orphan charity

- Add a decentralized upload method to add videos to the chain

- Modify the BMS to have a garbage collector. With this, old data will be deleted where hosting fees have not been paid.

- Modify the video frame to include a Tip button

- Add a process that bills the underlying key for storage costs on a certain frequency (for example possibly monthly, we bill the owner for storage)


I think this ecosystem provides a valuable service for Christians, Churches, Free Speech organizations, etc. We already have two parties interested in using this solution, one church and one prophetic org. I think it would be exciting to provide an alternative to big tech to large churches who would partner with us and serve their content on our network. Additionally we can gain the ability to provide free content (from our partners channels) to our users for viewing on social.biblepay.org.


My plan is to hold a vote on this idea on the forum first, then pending a good outcome, we insert this plan into our 2022 roadmap so that it becomes our primary use case.