- Fixed bug: database upgrade not working correctly when upgrading existing db.
- Added upgradeDB as a standalone function. (also called by initDB if upgrade is required)
- Added getDBversion: resolves the version of the db
- Improved openDB: rejects if the db is not found
floCloudAPI v2.0.2a
- deleteApplicationData accepts options instead of application (to match other functions).
- Added editApplicationData
- sendGeneralData not longer stores data in IDB.
- fixed bug: Infinite callback loop in requestGeneralData and requestObjectData
floDapps v2.0.1
- added mid startup support
- added deleteUserData and deleteAppData
- replaced reactor startup logger with setCustomStartupLogger
- spliting IDB into 3 parts:
1. floDapps - common DB for all apps across all users
2. userDB - common DB for all apps for specific user floID
3. appDB - app DB across all users
- contacts, pubKeys can be stored by users in userDB
- users can send direct message across all apps using floDapps.sendMessage
- syncData can be used to sync user data between devices
STD_OP
floGlobals
- combined vectorClock (for objectData) and generalVC (for generalData) into lastVC.
init
- Bug fixed: floData of 16 character dropped by floSight.
floCrypto
- Improved getFloIDfromPubkeyHex to getFloID: return floID from either pubKey or privKey.
- verifyPrivKey, validateAddr return false if arguments are empty.
floSupernode
- Removed floSupernode module.
- Kbucket submodule moved to floCloudAPI
Kbucket (subModule)
- Improved KBucket module
- Kbucket cyclic array (SNCO) is formed (w.r.t. distance) when kBucket is launched
- nextNode, prevNode are determined by SNCO
compactIDB
- Improved searchData (accepts option parameter instead of patternEval)
.options (lowerKey, upperKey, atKey, patternEval, lastOnly)
floCloudAPI
- Improved data signature during sending.
.current format ( ["receiverID", "time", "application", "type", "message", "comment"])
- Adding live request:
.requesting data now accepts option callback
.when callback option is passed, the request becomes live request
.ie, cloud automatically forwards new data received by the requested floID
.callback function is called with new data is received
.callback supported functions: requestApplicationData, requestGeneralData, requestObjectData
- Adding feature to delete from cloud.
.data received can now be deleted from cloud
.signature is required for verification (thus requires privKey logged in)
.can only delete own data (received only)
floDapps
- merged manageSubAdmins and setApplicationSettings into manageAppConfig(adminPrivKey, addList, rmList, settings)
- Improved getNextGeneralData
.getNextGeneralData can now sub-categorize comment (even when generalData is request for all comment)
.getNextGeneralData now keeps a track pointer of previously called. [vectorClock (ie, second parameter) must be null, default is null]
- floBlockchainAPI.readData's option pattern ll now test for JSON key matching the pattern
- startUp fn readAppConfigFromAPI checks if the content is a object or not to prevent errors
- generalData now also stores sign and pubKey.
- renamed startup fn readSubAdminListFromAPI to readAppConfigFromAPI.
- readAppConfigFromAPI also loads settings from the IDB to floGlobals.
- floDapps now reads 'settings' from blockchain
- improved manageSubAdmins: doesnot send tx if addList and rmList are empty (i.e, no changes)
- setApplicationSettings: used to set settings for the application.
Note: existing settings are overwritten (ie, not appended) if same key is used.
- sendGeneralData now supports a new option (encrypt): Encrypts the message before sending.
Note: option value can be boolean true or pubKey of a floID. Passing true will encrypt the data using the default encryptionKey (default 'encryptionKey' must be set in settings).
- getNextGeneralData now supports a new option (decrypt): Decrypts the message if possible.
Note: option value can be true, privateKey or array of privateKeys.
If boolean true is passed, decrypts using myPrivKey (loggedIn privateKey).
If privateKey (string) is passed, decrypts using the given privateKey.
If array of privateKeys are passed, decrypts the message using the suitable key from the given array. (for example, say messages A, B, C are encrypted for keys X, Y, Z respectively, passing [X, Z] will decrypt messages A and C.