
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).
The following functions require input from oxarbitrage on GitHub.
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).
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 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?
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).
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.
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.
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).
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.
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
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.
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?