'Beyond Bitshares' Google Assistant Development update!
A few days ago, I wrote a Steem blog post about my plans to develop a Bitshares Google Assistant which was well received.
Since then, I've been working heavily on the NodeJS code component of the Google Assistant, and I'm happy to announce the majority of the core functionality is finished!
Last post I talked about MIT licensing & open sourcing of the code, now it's a reality for the NodeJS component (see: index.js).
Developed NodeJS function summary
- Welcome: The user's introduction to the bot (summary of what functionality is available).
- About: About Bitshares functionality (basic summary for now).
- Account: An overview screen informing the user of the available account functionality available within the 'Beyond Bitshares' Google Assistant.
- Account_Balances: A list of a specific Bitshares account's balances.
- Account_CallPositions: A list of a specific Bitshares account's call positions.
- Account_Info: A Bitshares account's summary.
- Asset: An overview of the available Asset information within the Google Assistant.
- Get_Asset: Get an individual Bitshares asset basic information.
- Block: An overview of the available Block information within the Google Assistant.
- block_latest: Info regarding the latest Bitshares block.
- get_block_details: Info regarding a specific Bitshares block.
- blockchain_overview: MISC Bitshares blockchain/network information.
- Committee: An overview of the available Committee information within the Google Assistant.
- committee_active: A list of active committee members.
- get_committee_member: Details regarding a specific committee member.
- Fees: A summary of current Bitshares fees. Speaks only of the important fees, displays text of all fees.
- Market: An overview of the available Market information within the Google Assistant.
- market_top_uia: Outputs a list of the top User Issued Assets.
- market_top_smartcoins: Outputs a list of the top Smartcoins.
- market_top: Outputs a list of the top volume trading pairs on the BTS DEX.
- market_24hrvolume: Displays the 24hr trading volume for a single trading pair.
- market_overbook: Displays a summarized ordererbook (both buy/sell) for a single trading pair.
- market_ticker: Displays price ticker information for a single asset on the BTS DEX.
- market_tradehistory: Displays the last 10 trades for a single trading pair on the BTS DEX.
- Witness: An overview of the available Witness information within the Google Assistant.
- witness_active: Outputs a list of active witnesses.
- witness_one: Outputs details about a single witness.
- Worker: An overview of the available Worker information within the Google Assistant.
- worker_many: Outputs a list of (active/upcoming) worker proposals.
- worker_one: Outputs information regarding a single worker proposal.
Future NodeJS functions
The following functions require input from oxarbitrage on GitHub.
- get_most_active_markets: Most actively traded markets (all asset types).
- top_proxies: Highest voted proxies.
TODO
Dialogflow
Each of the above function's "User Say's" details
Each of the above functions have a related Dialogflow intent, which requires "User Say's" data which is used to trigger the intent. Effectively, we need to provide many examples of what the user can say to activate an individual intent/function.
Within the "User Say's" section, we'll need to extract the important user input variables such as the trading pairs, asset/witness/committee names, worker proposal id, etc. This will involve development of entities and NodeJS code to catch the user's input (and handling invalid input).
Entities
Regarding the entities, I was thinking of creating a script to auto-generate an 'Assets' entity for each asset. This entity will provide many synonyms for each registered Bitshares asset, so you can call Bitshares by BTS/Bitshares/Core-Asset (etc..). With such an entity, we can partially shift input validation onto DialogFlow instead of NodeJS.
Fallbacks
Fallbacks are intents/functions which trigger when the user inputs information that Dialogflow was not expecting.
Example: Dialogflow expects you provide an asset name, you scream gibberish into the device.
Thankfully we only need to provide fallback intents when asking the user for input & currently we rarely ask for input from the user.
On the topic of a lack of fallbacks, we app.tell() (force quit) users out of the bot once they've got the info they require. On one hand, short and functional bot responses are great (when asking for the weather, you don't expect more than a simple response), and on the other hand it might be annoying having to explicity invocate (trigger) the bot when you're wanting to ask many queries in a row.
What do you think? After getting the info they desire, should we ask what they want to do next or simply end the bot session?
NodeJS
Advanced response components
For the lists of witnesses, workers and committee members, rather than using simple responses only, we could utilize List selectors to enable selecting an individual for more info.
We already make use of the basic card component throughout the NodeJS code for providing a link to Oxarbitrage's Open-Explorer as a source of additional information (Whether it's asset/witness/committee etc information).
Testing
Using the Google Test Simulator (You won't have access.. yet ;D), I'll have to verify that each of the intents (functions) are able to be triggered using appropriate "user say's" phrases, likewise once fallbacks are appropriately implemented they'll need verified as operational.
Google is very strict regarding the level of quality they expect from Google Assistants, so there can't be any unhandled exceptions/crashes & they'll be trying their hardest to discover such issues. Thankfully, given that we app.tell() users out of the bot after fulfilling their requested query, we likely won't have many complex issues.
Beta Testing?
Unfortunately, beta testing is unlikely unless heavily trusted because of a huge Google Cloud oversight by Google which enables beta testers to see (read-only) everything in the bot's Google Cloud console!
You'll get access to the bot if you either grab the code & run an instance yourself, or if you wait until the bot is listed on the official Google Assistant store.
Migration
I'm currently using Vultr (referral link) for VPS resources, however once you join Google's community program you get allocated $200/month for Google Cloud resources (and a sweet t-shirt!) so I'll probably migrate to Google Cloud.
I've found the Google Cloud to be somewhat expensive but quite impressive (I really like their VPS web console, especially the ability to download/upload directly using the web console instead of requiring winscp).
Community provided translations
Once the bot is in a production state and the dialog has been finalized, we should provide several translations (since this will be made available worldwide). I believe that once provided several translations, Google is able to infer additional translations using their own Google Translation services thus we could say provide 10 translations and end up with all languages covered.
This still needs a large amount of research, as every string occurrence will need to look up a translated string.. it'll be pretty messy unless someone's got a best practices guide for this sort of NodeJS development?
I'll likely turn to the Steemit and Bitshares community initially for this work, as I saw the massive success that the eSteem & Bitshares wallets had crowdsourcing translations through Steemit.
Submit to Google
Once the bot is in a (near enough) production state, I'll submit the bot for review by Google's testers. They're pretty thorough & take several days to approve bots. Unfortunately they don't provide feedback unless you fail spectacularly, though to be fair they're probably having to evaluate hundreds of bots each day so it's likely an impossible task to praise epic bots like this one ;D
What won't we do?
Linking 'Beyond Bitshares' to your Google account
Google provides the ability to link your Google account to the bot as a means of quick/easy account sign up.
On one hand, this would enable us to persistently remember info such as your Bitshares account name and provide updates on your gains/losses using notifications (once they're out of beta).
On the other hand, I feel this is somewhat of an intrusive step to take and would rather that the only identifier possible remains the GG_ID (Anonymous google identity), of which we don't even utilize. I respect the privacy of the Beyond Bitshares bot's potential userbase.
Summary
So it's been a busy few days, and we're quite far into the development of the bot, with Dialogflow the next area of substantial development (before considering fallback implementation) & testing.
I'll be going back to university in the next few days, so the amount of time I'll have to dedicate towards this project will likely decrease substantially, however i'll slowly keep at its development & hopefully given its open-source nature the community will help out.
What do you think of this project? Do you have any ideas for your own Google Assistant?
