BlockPay Engine --- To hell with HTTP, DNS and App Store approval!

Now that the UN has taken over the Internet, I fully expect to see China-style firewalls popping up and extreme censorship globally. We have already seen some App Stores denying crypto-apps and now ISP's are to start blocking "unapproved" crypto. So, a couple months ago, we started a rather large upgrade for all of our apps and modules. Our meshnet friends are working on making the ISP's obsolete, and we are finishing the infrastructure to allow crypto apps to grow and prosper. Decentralization is more than just the nodes, it is the software itself.

#1

We have completed our Proof Of Concept (POC) on using IPFS in BlockPay and our findings are as follows:

If we want to use IPNS, then the IPFS daemon of the source computer should always remain ON. Otherwise it shows “Error: Can't resolve the name.” The process of resolving IPNS is very slow on both PC and android with the daemon as well as the http gateway. Fetching large files (>1MB) from IPFS takes too much time (youtu.be/PiMcZW1sux0) if you force the user to wait. So, we will move this fetching process into the background and give the user the UI so he/she never has to wait for a sync.

Conclusion regarding our IPFS tests are as follows:

A] public_nodes.json (let IPFS keep track of where our global nodes are):

• We created a json file containing the nodes array on IPFS and successfully used that file in our test app.

B] File which handles the 0.5% network fee:

• We created a json file containing a fees array on IPFS and successfully used that file in our test app.

C] File which handles the coin logos, coin name, details about the coin, etc.

• We created a folder on IPFS and put all the coin logos in png format. We also created a json file containing all the coins' info and a separate file that contains all the altcoins' info. This way we managed to remove dependency from our server to fetch the Smartcoins list and from the Bridge server to fetch the current altcoins list.

Now for example, if we need to change the name of any coin, its logo or other static data, then we just need to update 1 file on IPFS and it will be done automatically behind the scenes in all BlockPay distributions.

D] File which handles all connections with coin Bridges:

• We can only keep the urls of gateways/bridges in an IPFS file. And still it might not work as not all gateway/bridges will have the same api calls. Until we have our own Bridge someday, we will skip this feature for now.

E] Regarding changing the BlockPay layout and color themes through IPFS files:

• We found that although it is possible to render the layout on runtime from IPFS files, it takes too much time to render via IPFS directly each time, as well as a lot of effort for developing an xml parser. So, these BlockPay screens (home screen, qr code screen, thank you screen, transactions screen, settings screen, etc) will be stored on IPFS as Templates, but we will sync them locally for fast access. Updates to these local files can come on a schedule if the merchant chooses to allow updates.

Instead of storing the entire layout on IPFS, we created a json file that stores static attributes like background color, font color and font size, the messages on the qr code screen, etc. Then we used that file to change the attributes of the layout in our app dynamically from the sync'd local copy. aka: "Sync on Schedule"

F] Regarding changing the text messages:

• If we change the text on runtime from IPFS files then it will change the text in all languages. However, we cannot pull all of the language files from IPFS each time, as android requires them to be present at compile time. So this file will have to sync locally as well, instead of asking IPFS for the file every time BlockPay is loaded. So we will make the language files also Sync on Schedule.

G] Regarding storing Merchant data (logo, company name, tax rate, address, url, etc):

• Storing this data on IPFS was not really necessary since this kind of data is not really "permanent", as the merchant may want to update it from time to time, so we have another solution designed for this...

====================================

BlockPay enables any merchant to accept one or more digital currencies at Zero Cost.

====================================

#2

The new BlockPay "Engine" is now being designed.

"Why?"

When we first developed BlockPay, we had no idea so many merchants around the world would contact us and want BlockPay integrated with their existing systems (like vending machines, electric auto charging stations, proprietary Point Of Sale systems, major eCommerce websites, Hotel and Grocery chains, etc). What we quickly realized was that upgrades and new feature integrations for all of those custom systems would be a major pain in the butt. If for example Dash were to change the logo for their coin, we would have to go back and edit countless integrations at every one of those businesses and firmware installs. Relying on Gravatar to serve up the merchant's profile and logo to thousands of customer eReceipts is not future-proofed either. What if a third-party API were to go down? All of these things and a lot more do not allow a piece of software to scale properly, and the risk of one thing going down could take down an entire grocery chain. This is a huge liability. BlockPay cannot rely on third-parties, period.

Sooo, we are decentralizing BlockPay even more now...

https://ipfs.pics/ipfs/QmbBNdRb2LShS7K1WuNbYc7YkdLUNusoVUqDNQfqXV7bdZ

IPFS

All BlockPay static components will be hosted from one of our IPFS full-nodes (we have 2 currently, and will add a third full-node in Brazil next month). Static data that rarely changes (coin details, coin logos, merchant logos, template files, language files, public nodes, Bridge data, etc) will be hosted on IPFS and pulled from the nodes upon BlockPay install, or in the background via a local "Sync on Schedule" update.

Bitshares blockchain

The Bitshares blockchain will host basic text for each BlockPay merchant that changes occasionally, such as the merchant address, tax rate, website address, phone number, eReceipt thank you message, BlockPay settings-screen choices, etc. These values will be stored on the blockchain in a single memo field. Here is an example where someone used the blockchain to store text and make it available to the public (like we can do on an eReceipt): cryptofresh.com/u/announce - The text that we will store in the memo field however will be compressed and base58 encoded so that very few bytes will be consumed. The great thing about storing this minimal json data in a memo field for the merchant, is it makes their current info available to all of their customers in the eReceipts. That data will also pre-populate the BlockPay settings screen for the merchant should they ever have to uninstall and reinstall BlockPay in the future, or install BlockPay on additional devices.

This new "1-Step Setup" makes BlockPay even easier than before!

Local files

Upon install or scheduled update, BlockPay can easily grab the latest data from IPFS and the blockchain in the background, and update/sync its local copy. Even the files for the app itself will be served from IPFS/IPNS so that when App Stores start blocking crypto apps (which they already are), BlockPay will still be online and available, no matter what. Also, as we have seen, reliance on a third-party can kill an App, so by taking the time to finish this new Engine for BlockPay, it will make BlockPay (and our Smartcoins Wallet as well) even faster, super-scalable, more decentralized and unstoppable. This new BlockPay Engine should be ready for download by Christmas.

Note: If you are already running BlockPay (Integrated, or "S" versions) you will receive this free upgrade automatically. Your BlockPay Ambassador can show you this as well.

Please Upvote & Share: Decentralization is Freedom :)

.