From 2f118217d9c2d7ec5b6795c79e9c96cff163d6e7 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Fri, 15 May 2020 13:40:16 +0530 Subject: [PATCH 01/16] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 1f2d09f..257d9f1 100644 --- a/README.md +++ b/README.md @@ -141,7 +141,7 @@ This template contains standard operations that can be used for the following: 2. uri(Uniform Resource Identifier) - identifier for AJAX resource. It is used to create URL(Uniform Resource Locator) for further operations. * Resolves: responseData from the API -#### getBalalnce +#### getBalance floBlockchainAPI.getBalance(addr) `getBalance` requests balance for specified FLO address. 1. addr - FLO address for which balance has to be retrieved From aae73da57f9e4fb3a3dca3ad8532e7a40e37be01 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 09:07:07 +0530 Subject: [PATCH 02/16] Update README.md --- README.md | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) diff --git a/README.md b/README.md index 257d9f1..cdf5123 100644 --- a/README.md +++ b/README.md @@ -414,3 +414,104 @@ Note: if securePrivKey is used, then password must be requested during customPri ##### onLoadStartUp Sample startup is defined in onLoadStartUp function + + +# Basic Concepts of RanchiMall Blockchain Cloud for developers + +## 1. Data fields stored in each of decentralised servers + +vectorClock, senderID, receiverID, pubKey, message, sign, application, type, comment + +`vectorClock`: Unique time stamp and sender FLO ID attached to every message +`senderID`: FLO ID of the sender +`receiverID`: FLO ID of the receiver +`pubKey`: Public Key of the sender +`message`: The actual user data +`sign`: Digital signature of the entire data +`application`: The name of the application sending the data +`type`: What internal type of data the application is sending +`comment`: A free field for additional data + +## 2. Concept of Vector Clock +Decentralized cloud servers attach a unique time based ID to every message sent to the cloud, and store it alongside the message fields. + +It is stored in the form EpochTime_SenderFLOID + +Vector Clock field is unique for every message stored in cloud + +It allows the clients to retrieve messages before and after a certain time, and also help us identify who sent the message easily + +### Example of Vector Clock +1580484792246_FP97cbzsgTjHn7eyBtKSVcbkSSxZ5jWYHM + +1580484792246 Epoch time is GMT: Friday, January 31, 2020 3:33:12.246 PM in common time +FP97cbzsgTjHn7eyBtKSVcbkSSxZ5jWYHM is the FLO ID of sender + +## 3. Data Types supported by the cloud + +### User Data Types +`General Data`: Message field can be in any user form. +`Object Data`: Message field can only be a JavaScript Object + +### System Data Type +`Application Data`: Application data is the base on which General Data system and Object Data system has been created. The formats for General Data and Application Data are exactly the same. Users will never need to use Application Data. So we have deprecated Application Data. + +Note: +`General Data:` Type field is mandatory +`Object Data:` Type field has been consumed to create object functionality + + +## 4. General Data + +### SEND DATA +Parameters while sending + +`Message`: Actual Message to be sent +`Type`: User defined type (anything that user wants to classify as type) + +#### Options +`receiverID` - receiver of the data +`application` - application using the data +`comment` - user comment of the data + +### REQUEST DATA + +#### request options +`receiverID` - receiver of the data +`type` - type of the data ( a free user field) +`senderIDs` - array of senderIDs +`application` - application of the data +`comment` - comment of the data +`lowerVectorClock` - VC from which the data is to be requested +`upperVectorClock` - VC till which the data is to be requested +`atVectorClock` - VC at which the data is to requested +`mostRecent` - boolean (true: request only the recent data matching the pattern) + +## 5. ObjectData + +### RESET or UPDATE operations +Parameters while resetting or updating +`Object Data` + +#### Options +`receiverID` - receiver of the data +`application` - application using the data +`comment` - comment of the data + +### REQUEST DATA + +#### request options +`receiverID` - receiver of the data +`senderIDs` - array of senderIDs +`application` - application of the data +`comment` - comment of the data +`lowerVectorClock` - VC from which the data is to be requested +`upperVectorClock` - VC till which the data is to be requested +`atVectorClock` - VC at which the data is to requested +`mostRecent` - boolean (true: request only the recent data matching the pattern) + +## 5. Application Data + +### DEPRECATED + +Application data system is a legacy data field without vector clock support in options. In our development process, General Data was created by adding vector clock support to application data at user level. So SEND and REQUEST options in Application Data are exactly the same as General data without vector clock options From 3d9c763bee78fae51fc5054f4f1d48e7e63176a5 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 09:30:31 +0530 Subject: [PATCH 03/16] Update README.md --- README.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index cdf5123..1effba0 100644 --- a/README.md +++ b/README.md @@ -422,15 +422,15 @@ Sample startup is defined in onLoadStartUp function vectorClock, senderID, receiverID, pubKey, message, sign, application, type, comment -`vectorClock`: Unique time stamp and sender FLO ID attached to every message -`senderID`: FLO ID of the sender -`receiverID`: FLO ID of the receiver -`pubKey`: Public Key of the sender -`message`: The actual user data -`sign`: Digital signature of the entire data -`application`: The name of the application sending the data -`type`: What internal type of data the application is sending -`comment`: A free field for additional data +1. `vectorClock`: Unique time stamp and sender FLO ID attached to every message +2. * `senderID`: FLO ID of the sender +3. `receiverID`: FLO ID of the receiver +4. `pubKey`: Public Key of the sender +5. `message`: The actual user data +6. `sign`: Digital signature of the entire data +7. `application`: The name of the application sending the data +8. `type`: What internal type of data the application is sending +9. `comment`: A free field for additional data ## 2. Concept of Vector Clock Decentralized cloud servers attach a unique time based ID to every message sent to the cloud, and store it alongside the message fields. From 42f493b01b9c4be511a4b833f26334364e6613f4 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 09:32:12 +0530 Subject: [PATCH 04/16] Update README.md --- README.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 1effba0..008405e 100644 --- a/README.md +++ b/README.md @@ -422,15 +422,15 @@ Sample startup is defined in onLoadStartUp function vectorClock, senderID, receiverID, pubKey, message, sign, application, type, comment -1. `vectorClock`: Unique time stamp and sender FLO ID attached to every message -2. * `senderID`: FLO ID of the sender -3. `receiverID`: FLO ID of the receiver -4. `pubKey`: Public Key of the sender -5. `message`: The actual user data -6. `sign`: Digital signature of the entire data -7. `application`: The name of the application sending the data -8. `type`: What internal type of data the application is sending -9. `comment`: A free field for additional data + * `vectorClock`: Unique time stamp and sender FLO ID attached to every message + * `senderID`: FLO ID of the sender + * `receiverID`: FLO ID of the receiver + * `pubKey`: Public Key of the sender + * `message`: The actual user data + * `sign`: Digital signature of the entire data + * `application`: The name of the application sending the data + * `type`: What internal type of data the application is sending + * `comment`: A free field for additional data ## 2. Concept of Vector Clock Decentralized cloud servers attach a unique time based ID to every message sent to the cloud, and store it alongside the message fields. From 59dfc6f449904affb9e9131b7284af21476ebbb6 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 09:35:17 +0530 Subject: [PATCH 05/16] Update README.md --- README.md | 62 +++++++++++++++++++++++++++---------------------------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/README.md b/README.md index 008405e..7f54043 100644 --- a/README.md +++ b/README.md @@ -450,15 +450,15 @@ FP97cbzsgTjHn7eyBtKSVcbkSSxZ5jWYHM is the FLO ID of sender ## 3. Data Types supported by the cloud ### User Data Types -`General Data`: Message field can be in any user form. -`Object Data`: Message field can only be a JavaScript Object + * `General Data`: Message field can be in any user form. + * `Object Data`: Message field can only be a JavaScript Object ### System Data Type -`Application Data`: Application data is the base on which General Data system and Object Data system has been created. The formats for General Data and Application Data are exactly the same. Users will never need to use Application Data. So we have deprecated Application Data. +* `Application Data`: Application data is the base on which General Data system and Object Data system has been created. The formats for General Data and Application Data are exactly the same. Users will never need to use Application Data. So we have deprecated Application Data. Note: -`General Data:` Type field is mandatory -`Object Data:` Type field has been consumed to create object functionality + * `General Data:` Type field is mandatory + * `Object Data:` Type field has been consumed to create object functionality ## 4. General Data @@ -466,49 +466,49 @@ Note: ### SEND DATA Parameters while sending -`Message`: Actual Message to be sent -`Type`: User defined type (anything that user wants to classify as type) + * `Message`: Actual Message to be sent + * `Type`: User defined type (anything that user wants to classify as type) #### Options -`receiverID` - receiver of the data -`application` - application using the data -`comment` - user comment of the data + * `receiverID` - receiver of the data + * `application` - application using the data + * `comment` - user comment of the data ### REQUEST DATA #### request options -`receiverID` - receiver of the data -`type` - type of the data ( a free user field) -`senderIDs` - array of senderIDs -`application` - application of the data -`comment` - comment of the data -`lowerVectorClock` - VC from which the data is to be requested -`upperVectorClock` - VC till which the data is to be requested -`atVectorClock` - VC at which the data is to requested -`mostRecent` - boolean (true: request only the recent data matching the pattern) + * `receiverID` - receiver of the data + * `type` - type of the data ( a free user field) + * `senderIDs` - array of senderIDs + * `application` - application of the data + * `comment` - comment of the data + * `lowerVectorClock` - VC from which the data is to be requested + * `upperVectorClock` - VC till which the data is to be requested + * `atVectorClock` - VC at which the data is to requested + * `mostRecent` - boolean (true: request only the recent data matching the pattern) ## 5. ObjectData ### RESET or UPDATE operations Parameters while resetting or updating -`Object Data` + * `Object Data` #### Options -`receiverID` - receiver of the data -`application` - application using the data -`comment` - comment of the data + * `receiverID` - receiver of the data + * `application` - application using the data + * `comment` - comment of the data ### REQUEST DATA #### request options -`receiverID` - receiver of the data -`senderIDs` - array of senderIDs -`application` - application of the data -`comment` - comment of the data -`lowerVectorClock` - VC from which the data is to be requested -`upperVectorClock` - VC till which the data is to be requested -`atVectorClock` - VC at which the data is to requested -`mostRecent` - boolean (true: request only the recent data matching the pattern) + * `receiverID` - receiver of the data + * `senderIDs` - array of senderIDs + * `application` - application of the data + * `comment` - comment of the data + * `lowerVectorClock` - VC from which the data is to be requested + * `upperVectorClock` - VC till which the data is to be requested + * `atVectorClock` - VC at which the data is to requested + * `mostRecent` - boolean (true: request only the recent data matching the pattern) ## 5. Application Data From 2099fa61ba4a2e083f228e2c8a797e78e818b5ec Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 09:37:08 +0530 Subject: [PATCH 06/16] Update README.md --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 7f54043..b93c80a 100644 --- a/README.md +++ b/README.md @@ -441,11 +441,11 @@ Vector Clock field is unique for every message stored in cloud It allows the clients to retrieve messages before and after a certain time, and also help us identify who sent the message easily -### Example of Vector Clock -1580484792246_FP97cbzsgTjHn7eyBtKSVcbkSSxZ5jWYHM +#### Example of Vector Clock +* `1580484792246_FP97cbzsgTjHn7eyBtKSVcbkSSxZ5jWYHM` -1580484792246 Epoch time is GMT: Friday, January 31, 2020 3:33:12.246 PM in common time -FP97cbzsgTjHn7eyBtKSVcbkSSxZ5jWYHM is the FLO ID of sender + - `1580484792246` Epoch time is GMT: Friday, January 31, 2020 3:33:12.246 PM in common time + - `FP97cbzsgTjHn7eyBtKSVcbkSSxZ5jWYHM` is the FLO ID of sender ## 3. Data Types supported by the cloud From 09490c560d01ab94855c46931c8f1a250d2de21c Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 10:14:11 +0530 Subject: [PATCH 07/16] Update README.md --- README.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/README.md b/README.md index b93c80a..d67e915 100644 --- a/README.md +++ b/README.md @@ -418,6 +418,33 @@ Sample startup is defined in onLoadStartUp function # Basic Concepts of RanchiMall Blockchain Cloud for developers +* RanchiMall blockchain cloud is a service to provide a set of decentralized servers that will provide data storage to users. These decentralized servers are listed in the FLO Blockchain under an authorized FLO address. This gives the assurance to the users that those data servers can be trusted. + +* The user can store his data in these servers freely. RanchiMall cloud service also provides facilities to store Javascript Objects directly. Storage in JavaScript object form makes it easier for JavaScript based applications to process the data. + +* The cloud servers provide automatic backup and restoration for each other. + +* Using the blockchain based data cloud, users will not need any database to store their data. The cloud will provide data storage, backup and restoration facilites. + +* RanchiMall Blockchain Cloud is a password less system. Every sender has to digitally sign his data with the private key associated with its FLO ID. The cloud verifies the digital signature of the sender before storing sender data. + +* Since the blockchain cloud is an ensemble of servers, we need a method to pick the right server to store the data. For this purpose, we find the a server closest to receipient of the data according to an artificial distance measure. + +* Every client of the cloud can automatically compute the correct server where the data needs to be stored, and sends the message directly to that server. + +* Every client of the cloud is the consumer of the data. It can ask the cloud for data sorted by a recipient, or by various options we provide like name of application, type of data, or by specific comments. The client can can also ask for all data after or before a certain point of time using a concept called Vector Clock. + +* The cloud attaches the exact epoch time to any message given by a sender, and using the combination of epoch time, and sender FLO ID, the vector clock is constructed. + +* The two basic forms in which users can submit data to the cloud are General Data and Object Data. General Data is freely flowing data, and Object Data is pure Javascript Object. + +* Both General Data and Object Data have been derived from Application Data which is the basic system data type in the cloud. Normal users will never need to use Application Data. But for documentation purposes, we are providing the technical details. + + - General Data = Application Data + User level Vector Clock filtering facilities + + - Object Data = Application Data + Message field modified to handle Javascript Object + User level Vector Clock filtering facilities + + ## 1. Data fields stored in each of decentralised servers vectorClock, senderID, receiverID, pubKey, message, sign, application, type, comment From 572c55909620c391717674c4652730e812f2fa95 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 10:33:04 +0530 Subject: [PATCH 08/16] Update README.md --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index d67e915..af3836c 100644 --- a/README.md +++ b/README.md @@ -444,6 +444,9 @@ Sample startup is defined in onLoadStartUp function - Object Data = Application Data + Message field modified to handle Javascript Object + User level Vector Clock filtering facilities +* Just like how blockchain provides data, RacnhiMal blcokchain cloud will also provide data to everyone who asks for it. So sensitive data should be encrypted using the receiver's public key using Crypto functions of FLO Standard Operations. + +* Consumers of data can ask for data by receiver ID, or filter it by application, type, or comment. They can aslo ask for data for a given type before and after a certain vector clock. ## 1. Data fields stored in each of decentralised servers From afc286964fb55544567ed99e830eeaef694979ea Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 10:36:45 +0530 Subject: [PATCH 09/16] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index af3836c..ad5f834 100644 --- a/README.md +++ b/README.md @@ -438,7 +438,7 @@ Sample startup is defined in onLoadStartUp function * The two basic forms in which users can submit data to the cloud are General Data and Object Data. General Data is freely flowing data, and Object Data is pure Javascript Object. -* Both General Data and Object Data have been derived from Application Data which is the basic system data type in the cloud. Normal users will never need to use Application Data. But for documentation purposes, we are providing the technical details. +* Both General Data and Object Data have been derived from Application Data which is the basic system data type in the cloud. Normal users will never need to use Application Data. But for documentation purposes, we are providing the technical details for Application Data as well. - General Data = Application Data + User level Vector Clock filtering facilities From cc20e28de3781d281fda922dd710c3c6a1a08983 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 10:39:59 +0530 Subject: [PATCH 10/16] Update README.md --- README.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index ad5f834..c6e1870 100644 --- a/README.md +++ b/README.md @@ -436,17 +436,17 @@ Sample startup is defined in onLoadStartUp function * The cloud attaches the exact epoch time to any message given by a sender, and using the combination of epoch time, and sender FLO ID, the vector clock is constructed. -* The two basic forms in which users can submit data to the cloud are General Data and Object Data. General Data is freely flowing data, and Object Data is pure Javascript Object. +* The two basic forms in which users can submit data to the cloud are `General Data` and `Object Data`. `General Data` is freely flowing data, and `Object Data` is stored directly as pure Javascript Object. -* Both General Data and Object Data have been derived from Application Data which is the basic system data type in the cloud. Normal users will never need to use Application Data. But for documentation purposes, we are providing the technical details for Application Data as well. +* Both `General Data` and `Object Data` have been derived from `Application Data` which is the basic system data type in the cloud. Normal users will never need to use Application Data. But for documentation purposes, we are providing the technical details for Application Data as well. - - General Data = Application Data + User level Vector Clock filtering facilities + - `General Data` = `Application Data` + User level Vector Clock filtering facilities - - Object Data = Application Data + Message field modified to handle Javascript Object + User level Vector Clock filtering facilities + - `Object Data` = `Application Data` + Message field modified to handle Javascript Object + User level Vector Clock filtering facilities -* Just like how blockchain provides data, RacnhiMal blcokchain cloud will also provide data to everyone who asks for it. So sensitive data should be encrypted using the receiver's public key using Crypto functions of FLO Standard Operations. +* Consistent with blockchain data principles, RanchiMall blockchain cloud will also provide data to everyone who asks for it. So sensitive data should be encrypted using the receiver's public key using Crypto functions of FLO Standard Operations. -* Consumers of data can ask for data by receiver ID, or filter it by application, type, or comment. They can aslo ask for data for a given type before and after a certain vector clock. +* Consumers of data can ask for data by receiver ID, or filter it by application, type, or comment. They can also ask for data for a given type before and after a certain vector clock. ## 1. Data fields stored in each of decentralised servers From 3a23206af9ce3f879a7780344bef8c76153f6491 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 15:35:51 +0530 Subject: [PATCH 11/16] Update README.md --- README.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/README.md b/README.md index c6e1870..8bfba54 100644 --- a/README.md +++ b/README.md @@ -545,3 +545,13 @@ Parameters while resetting or updating ### DEPRECATED Application data system is a legacy data field without vector clock support in options. In our development process, General Data was created by adding vector clock support to application data at user level. So SEND and REQUEST options in Application Data are exactly the same as General data without vector clock options + +# RanchiMall recommended approach to create FLO Distributed Apps + +1. create master admin key +2. create subAdmins +3. create blockchain cloud data formats +4. define functions of the app +5. secure the user privKey (and other sensitive data, if any) +6. create UI for the application +7. define onLoadStartUp function to act when the initial load of page is done, and when refresh of the page is required for in response to any user action From 6175ac9314ba264da433be8f4a6adb2c6585bf21 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 17:47:27 +0530 Subject: [PATCH 12/16] Update README.md --- README.md | 34 +++++++++++++++++++++++++--------- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 8bfba54..a552481 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,13 @@ # Standard_Operations - Standard operations required for FLO Crypto, Blockchain API, Supernode WS, IndexedDB +RanchiMall is releasing FLO Standard Operations in order to make it easier for everyone in community to access common functions that any developer would need in a standardized way for JavaScript based development around FLO Blockchain ecosystem. + +The methods enable developers to read and write into FLO Blockchain directly without any wallet or Chrome extension dependencies. They also enable developers to create digital signatures for any message out of any FLO ID, and functions verify them as well. In additional, standard methods are being provided for data encryption using recipient FLO ID and private key splitting using Shamir Secret Sharing algorithm. + +We are also provding access to a common data infrastructure called the FLO Blockchain Data Cloud which can provide place for host data that will be too expensive to put inside the blockchain. + +We are offering methods simplifying access to inbuilt browser database IndexedDB or IDB. + +Last but not the least, we are also providing methods for simplying common operations for FLO based Distributed Application Development. This template contains standard operations that can be used for the following: 1. FLO Globals @@ -546,12 +554,20 @@ Parameters while resetting or updating Application data system is a legacy data field without vector clock support in options. In our development process, General Data was created by adding vector clock support to application data at user level. So SEND and REQUEST options in Application Data are exactly the same as General data without vector clock options -# RanchiMall recommended approach to create FLO Distributed Apps +# Background on FLO Distributed Applications -1. create master admin key -2. create subAdmins -3. create blockchain cloud data formats -4. define functions of the app -5. secure the user privKey (and other sensitive data, if any) -6. create UI for the application -7. define onLoadStartUp function to act when the initial load of page is done, and when refresh of the page is required for in response to any user action +FLO distibuted applications use the FLO Blockchain to store core data, and FLO Blockchain Cloud for other data. The data is accessed directly by browser based clients. No other component or servers are needed typically. + +Every application has a role called the Master Admin. The clients trust anything that the Master Admin declares in the FLO Blockchain. Usually Master Admin will only declare the FLO IDs that will have operational roles in the application. These FLO IDs are called SubAdmins. The browser based clients trust actions only and only from subAdmins and no one else. That creates the trust model. First trust the Master Admin. Then find out who the master admin has authorized to act as SubAdmins in the FLO blockchain. Then trust the data and actions signed by approved SubAdmins. + +This approach decentralizes the trust process totally and extends the capacity of the blockchain to model almost any server based IT application. + +## RanchiMall recommended approach to create a FLO Distributed Application + +1. Create Master Admin FLO ID and private key +2. Role Modeling: Create SubAdmins by having Master Admin declare it in the FLO Blockchain, and decide what roles will differnent kind of SubAdmins play +3. Data Modeling: Create Blockchain cloud data formats for your application. Do it twice: One for system trusted users like SubAdmins using Object Data. And again for normal untrusted users using General Data +4. Define core business functionalities of the app, and create Javascript methods to model it +5. Secure the user Private Key (and other sensitive data, if any) +6. Create UI for the application, and create Javascript methods invoking them +7. Define initial startup routines using onLoadStartUp function to act when the initial load of page is done, and when refresh of the page is required for in response to any user action From 2265581971a10e329e57139de45a36155bf0db99 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 17:53:05 +0530 Subject: [PATCH 13/16] Update README.md --- README.md | 71 ++++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 54 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index a552481..06b1e97 100644 --- a/README.md +++ b/README.md @@ -9,6 +9,59 @@ We are offering methods simplifying access to inbuilt browser database IndexedDB Last but not the least, we are also providing methods for simplying common operations for FLO based Distributed Application Development. +# Background on FLO Distributed Applications + +FLO distibuted applications use the FLO Blockchain to store core data, and FLO Blockchain Cloud for other data. The data is accessed directly by browser based clients. No other component or servers are needed typically. + +Every application has a role called the Master Admin. The clients trust anything that the Master Admin declares in the FLO Blockchain. Usually Master Admin will only declare the FLO IDs that will have operational roles in the application. These FLO IDs are called SubAdmins. The browser based clients trust actions only and only from subAdmins and no one else. That creates the trust model. First trust the Master Admin. Then find out who the master admin has authorized to act as SubAdmins in the FLO blockchain. Then trust the data and actions signed by approved SubAdmins. + +This approach decentralizes the trust process totally and extends the capacity of the blockchain to model almost any server based IT application. + +## RanchiMall recommended approach to create a FLO Distributed Application + +1. Create Master Admin FLO ID and private key +2. Role Modeling: Create SubAdmins by having Master Admin declare it in the FLO Blockchain, and decide what roles will differnent kind of SubAdmins play +3. Data Modeling: Create Blockchain cloud data formats for your application. Do it twice: One for system trusted users like SubAdmins using Object Data. And again for normal untrusted users using General Data +4. Define core business functionalities of the app, and create Javascript methods to model it +5. Secure the user Private Key (and other sensitive data, if any) +6. Create UI for the application, and create Javascript methods invoking them +7. Define initial startup routines using onLoadStartUp function to act when the initial load of page is done, and when refresh of the page is required for in response to any user action + +## Basic Concepts of RanchiMall Blockchain Cloud for developers + +* RanchiMall blockchain cloud is a service to provide a set of decentralized servers that will provide data storage to users. These decentralized servers are listed in the FLO Blockchain under an authorized FLO address. This gives the assurance to the users that those data servers can be trusted. + +* The user can store his data in these servers freely. RanchiMall cloud service also provides facilities to store Javascript Objects directly. Storage in JavaScript object form makes it easier for JavaScript based applications to process the data. + +* The cloud servers provide automatic backup and restoration for each other. + +* Using the blockchain based data cloud, users will not need any database to store their data. The cloud will provide data storage, backup and restoration facilites. + +* RanchiMall Blockchain Cloud is a password less system. Every sender has to digitally sign his data with the private key associated with its FLO ID. The cloud verifies the digital signature of the sender before storing sender data. + +* Since the blockchain cloud is an ensemble of servers, we need a method to pick the right server to store the data. For this purpose, we find the a server closest to receipient of the data according to an artificial distance measure. + +* Every client of the cloud can automatically compute the correct server where the data needs to be stored, and sends the message directly to that server. + +* Every client of the cloud is the consumer of the data. It can ask the cloud for data sorted by a recipient, or by various options we provide like name of application, type of data, or by specific comments. The client can can also ask for all data after or before a certain point of time using a concept called Vector Clock. + +* The cloud attaches the exact epoch time to any message given by a sender, and using the combination of epoch time, and sender FLO ID, the vector clock is constructed. + +* The two basic forms in which users can submit data to the cloud are `General Data` and `Object Data`. `General Data` is freely flowing data, and `Object Data` is stored directly as pure Javascript Object. + +* Both `General Data` and `Object Data` have been derived from `Application Data` which is the basic system data type in the cloud. Normal users will never need to use Application Data. But for documentation purposes, we are providing the technical details for Application Data as well. + + - `General Data` = `Application Data` + User level Vector Clock filtering facilities + + - `Object Data` = `Application Data` + Message field modified to handle Javascript Object + User level Vector Clock filtering facilities + +* Consistent with blockchain data principles, RanchiMall blockchain cloud will also provide data to everyone who asks for it. So sensitive data should be encrypted using the receiver's public key using Crypto functions of FLO Standard Operations. + +* Consumers of data can ask for data by receiver ID, or filter it by application, type, or comment. They can also ask for data for a given type before and after a certain vector clock. + + +# Technical Details of standard operations + This template contains standard operations that can be used for the following: 1. FLO Globals 2. FLO Crypto Operations @@ -424,7 +477,7 @@ Note: if securePrivKey is used, then password must be requested during customPri Sample startup is defined in onLoadStartUp function -# Basic Concepts of RanchiMall Blockchain Cloud for developers +# Repeat of Basic Concepts of RanchiMall Blockchain Cloud for developers * RanchiMall blockchain cloud is a service to provide a set of decentralized servers that will provide data storage to users. These decentralized servers are listed in the FLO Blockchain under an authorized FLO address. This gives the assurance to the users that those data servers can be trusted. @@ -554,20 +607,4 @@ Parameters while resetting or updating Application data system is a legacy data field without vector clock support in options. In our development process, General Data was created by adding vector clock support to application data at user level. So SEND and REQUEST options in Application Data are exactly the same as General data without vector clock options -# Background on FLO Distributed Applications -FLO distibuted applications use the FLO Blockchain to store core data, and FLO Blockchain Cloud for other data. The data is accessed directly by browser based clients. No other component or servers are needed typically. - -Every application has a role called the Master Admin. The clients trust anything that the Master Admin declares in the FLO Blockchain. Usually Master Admin will only declare the FLO IDs that will have operational roles in the application. These FLO IDs are called SubAdmins. The browser based clients trust actions only and only from subAdmins and no one else. That creates the trust model. First trust the Master Admin. Then find out who the master admin has authorized to act as SubAdmins in the FLO blockchain. Then trust the data and actions signed by approved SubAdmins. - -This approach decentralizes the trust process totally and extends the capacity of the blockchain to model almost any server based IT application. - -## RanchiMall recommended approach to create a FLO Distributed Application - -1. Create Master Admin FLO ID and private key -2. Role Modeling: Create SubAdmins by having Master Admin declare it in the FLO Blockchain, and decide what roles will differnent kind of SubAdmins play -3. Data Modeling: Create Blockchain cloud data formats for your application. Do it twice: One for system trusted users like SubAdmins using Object Data. And again for normal untrusted users using General Data -4. Define core business functionalities of the app, and create Javascript methods to model it -5. Secure the user Private Key (and other sensitive data, if any) -6. Create UI for the application, and create Javascript methods invoking them -7. Define initial startup routines using onLoadStartUp function to act when the initial load of page is done, and when refresh of the page is required for in response to any user action From aa7c5c909e8c7fbf724ed58071415f563b7e4d26 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 17:55:30 +0530 Subject: [PATCH 14/16] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 06b1e97..b1cd36e 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,7 @@ Last but not the least, we are also providing methods for simplying common opera FLO distibuted applications use the FLO Blockchain to store core data, and FLO Blockchain Cloud for other data. The data is accessed directly by browser based clients. No other component or servers are needed typically. -Every application has a role called the Master Admin. The clients trust anything that the Master Admin declares in the FLO Blockchain. Usually Master Admin will only declare the FLO IDs that will have operational roles in the application. These FLO IDs are called SubAdmins. The browser based clients trust actions only and only from subAdmins and no one else. That creates the trust model. First trust the Master Admin. Then find out who the master admin has authorized to act as SubAdmins in the FLO blockchain. Then trust the data and actions signed by approved SubAdmins. +Every application has a role called the Master Admin. The clients trust anything that the Master Admin declares in the FLO Blockchain. Usually Master Admin will only declare the FLO IDs that will have operational roles in the application. These FLO IDs are called SubAdmins. The browser based clients trust actions only and only from subAdmins and no one else. That creates the trust model. First trust the Master Admin. Then find out who the master admin has authorized to act as SubAdmins in the FLO blockchain. Then trust the data and actions signed by approved SubAdmins. Since the entire chain of trust is blockchain based, it enables a blockchain driven trust model. As the blockchain data is immutable and permanent, so long as users can trust the Master Admin, blockchain will ensure that the turst is efficiently transmitted. This approach decentralizes the trust process totally and extends the capacity of the blockchain to model almost any server based IT application. From 5699e8dee47555cebb41392f7e6f8f204fc11782 Mon Sep 17 00:00:00 2001 From: tripathyr Date: Sat, 16 May 2020 18:13:42 +0530 Subject: [PATCH 15/16] Update README.md --- README.md | 51 ++++++++++++++++++++++++++++----------------------- 1 file changed, 28 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index b1cd36e..1935477 100644 --- a/README.md +++ b/README.md @@ -63,16 +63,16 @@ This approach decentralizes the trust process totally and extends the capacity o # Technical Details of standard operations This template contains standard operations that can be used for the following: -1. FLO Globals -2. FLO Crypto Operations +1. FLO Globals for system variables and data objects users must configure +2. FLO Crypto Operations 3. FLO Blockchain API Operations -4. FLO SuperNode Websocket Operations -5. Compact IndexedDB Operations -6. FLO Cloud API Operations -7. FLO Decentralized app (Dapp) module +4. Compact IndexedDB Operations +5. FLO Cloud API Operations +6. FLO Decentralized app (Dapp) Operations ## FLO Globals `floGlobals` object contains the global variables and constants required for the operations. Make sure to add this object before any other scripts. + `floGlobals` contains the following properties : 1. `blockchain` : Indicates the blockchain (`"FLO"` or `"FLO_TEST"`). 2. `apiURL` : Indicates the URL for blockchain API calls. @@ -417,22 +417,13 @@ Note: value of objectData is taken from floGlobals ## FLO Decentralised Applications (Dapps) `floDapps` module contains methods for basic Dapp. floDapps uses all of the above modules. -#### addStartUpFunction - floDapps.addStartUpFunction(fname, fn) -`addStartUpFunction` adds a startup funtion to the Dapp -1. fname - Name of the startup function -2. fn - body of the function -Note: startup funtions are called in parallel. Therefore only add custom startup funtion only if it can run in parallel with other startup functions. (default startup funtions are read supernode list and subAdmin list from blockchain API, load data from indexedDB, get login credentials) + #### setCustomPrivKeyInput floDapps.setCustomPrivKeyInput(customFn) `setCustomPrivKeyInput` adds a startup funtion to the Dapp 1. customFn - custom function to get login credentials (privateKey) -#### setAppObjectStores - floDapps.setAppObjectStores(appObs) -`setAppObjectStores` adds additionals objectstores for the app -1. appObs - additionals objects for the app #### manageSubAdmins floDapps.manageSubAdmins(adminPrivKey, addList, rmList) @@ -451,13 +442,6 @@ Note: startup funtions are called in parallel. Therefore only add custom startup 1. pwd - password for the encryption Note: if securePrivKey is used, then password must be requested during customPrivKeyInput (in setCustomPrivKeyInput). -#### objectDataMapper - floDapps.objectDataMapper(object, path, data) -`objectDataMapper` maps the object and data via path -1. object - object to be mapped -2. path - end path for the data holder -3. data - data to be pushed in map - #### getNextGeneralData floDapps.getNextGeneralData(type, vectorClock, options = {}) `getNextGeneralData` return the next generaldata @@ -476,6 +460,27 @@ Note: if securePrivKey is used, then password must be requested during customPri ##### onLoadStartUp Sample startup is defined in onLoadStartUp function +#### addStartUpFunction + floDapps.addStartUpFunction(fname, fn) +`addStartUpFunction` adds a startup funtion to the Dapp +1. fname - Name of the startup function +2. fn - body of the function +Note: startup funtions are called in parallel. Therefore only add custom startup funtion only if it can run in parallel with other startup functions. (default startup funtions are read supernode list and subAdmin list from blockchain API, load data from indexedDB, get login credentials) + +### Advanced Dapp functions usually not needed for users + +#### setAppObjectStores + floDapps.setAppObjectStores(appObs) +`setAppObjectStores` adds additionals objectstores for the app +1. appObs - additionals objects for the app + +#### objectDataMapper + floDapps.objectDataMapper(object, path, data) +`objectDataMapper` maps the object and data via path +1. object - object to be mapped +2. path - end path for the data holder +3. data - data to be pushed in map + # Repeat of Basic Concepts of RanchiMall Blockchain Cloud for developers From 57ff5ae0b9362750af65712246aa97c4fda2a76d Mon Sep 17 00:00:00 2001 From: SaketAnand Date: Sun, 17 May 2020 10:45:43 +0530 Subject: [PATCH 16/16] README.md Corrected the spelling of "retrieve" from "retrive' in floCloudAPI Section --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 1935477..7dc24b1 100644 --- a/README.md +++ b/README.md @@ -350,7 +350,7 @@ Note: If passed as Array, then ratio of the balance of the senders are preserved This module contains functions that interact with the supernode to send and retrive data in the backend. Use floClouldAPI operations to send and receive data for application. ## FLO Cloud API operations -`floCloudAPI` operations can interact with floSupernode cloud to send and retrive data for applications. floCloudAPI uses floSupernode module for backend interactions. +`floCloudAPI` operations can interact with floSupernode cloud to send and retrieve data for applications. floCloudAPI uses floSupernode module for backend interactions. #### sendApplicationData floCloudAPI.sendApplicationData(message, type, options = {})