Simple outline for decentralized webshop marketplace
To further our plans of enabling worldwide decentralized marketplace through the FIMKrypto blockchain and Mofowallet, I opted for leveraging my limited e-commerce project experience here in public, describing a simple database schema and the outline of a basic webshop configuration. Mind you about the complete absence of novelty factor; The roots of this knowledge are around 20 years ago when I started to enter the mysterious realms of internet! So this is not gonna be the most advanced piece of pseudocode you’ve seen laying around, but the basic building blocks should still apply.
What we at FIMK already have, inherited from NXT, is the Digital Marketplace on the server level enabling listing and purchase of digital goods. But that’s too limited for our purposes, and we don’t have an user interface for it yet, so we start fresh from the ground up by designing a system from scratch. Then we can possibly increase our efficiency by picking any suitable parts from the existing Digital Marketplace crypto platform implementation.
The first part of any functional e-commerce application database is listing the items for sale. When we start thinking about a single webshop, we should have a generalized product_data table with at least the following db fields to start with:
* shop_id (for multiple shops)
A groups table is needed to categorize products into different groups for display purposes etc. It should consist of at least the following:
* index_num (group_id)
Another delivery_types table is required to specify the product delivery related terms, costs and specifics. It can be for instance like this:
* delivery_type (physical, digital)
* delivery_fee (constant, by weight)
When we set up all applicable delivery types for our particular shop we may get an example of the following alternative combinations for a single item:
* physical delivery with constant fee
* physical delivery with low weight cost
* physical delivery with medium weight cost
* physical delivery with high weight cost
* digital delivery, fee not applicable
When we have the product listing and tracking in place, we have to design the orders backend database. It could be a single table like this:
* shop_id (or FIMK account)
* buyer_id (or FIMK account)
Now that we can write and monitor orders, change their payment status and delivery status, we have pretty much a barebones webshop system in place!
Add a few extra features like coupons table:
* limited to_products
And product_comments table:
* sender_id (or FIMK account)
And feedback table:
* receiver (shop_id or FIMK account)
Add shops table to host a marketplace of multiple web shops:
Voila! A crude, unoptimized database for e-commerce application. Now tie all that to the FIMK decentralized crypto ledger, that’s easier said than done for an oldschool Mysql dude! And that’s why we have a dedicated full time (or should I say overtime) lead developer working his magic for the benefit of the whole FIMKrypto ecosystem.
When entering the cryptocurrency side armed with functional e-commerce application basics, the benefits of decentralized platform become obvious –
– Direct web shopping and payment processing capability within the FIMKrypto application (Mofowallet)
– Direct order processing with the FIMKrypto application
– Automatic decentralized, encrypted archiving
– Possibility for instant automatic delivery of digital content through the blockchain / external links
– Numerous separate markets with different properties: Public or private (encrypted, accessible only for authenticated users)
To conclude our little design exercise let me quote the lead developer for some inspirational thoughts:
Encrypted market works the exact same way as the unencrypted (through specially formatted Arbitrary messaging) with this exception: Any normal FIMK installation which doesn’t have the key can’t build up its internal database by scanning the blockchain. Only if you provide the secret key in your config file could the server (java) code decrypt the AMs that hold the instructions, from which we can build up the tables of e-commerce data (the so called model).