We are using a hubot connected to a Dialogflow bot to carry on a conversation with a user in a DM. So, for instance, if the bot sends two buttons – “yes” and “no”. And the user chooses “yes”, we would like to be able to write that into chat window. And then to have our bot handle any response to that “yes”. The question is…how can our bot know the context of that “yes”? So that it knows which button was clicked and which question was asked?
We understand that the bot architecture is in flux so would like any suggestions you might have to support the above in the current hubot-based DM message flow.
A possible approach: could we put some type of contextId that is included in the button json schema that could then be put into the json message such that the hubot could forward an “enriched message” with that contextId? I know this sounds hackish but looking for options.
In a past attempt at something like this… I actually created a new message type, and modified the bot framework to grab those message types. Because it was a new message type I was able to keep it from being displayed to end user, but the bot would receive it.
I’ve also wondered about bots… If official and a way to register a bot… maybe could actually subscribe to an event stream for that bot. Then message responses like this could actually just be sent to the bot over it’s event stream.
There’s a few concepts here that are related but confusing to deal with all at once.
Firstly, I’m not a fan of the idea of including conversational context in the messaging platform. That’s something the bot platform / framework should deal with. There’s different approaches and capabilities for that in each platform and it would be a nightmare to try and expose or deal with that at the messaging platform level, it’s simply not equipped for the nuances. The standard approach for buttons that respond to a question from the bot is just to submit the button text as a response to the bot (via a standard message e.g. solution I’ve been using for years), the bot should have it’s own internal logic to track states and know that the next incoming message from a particular user, in a particular room, where it asked a question, the response should be assessed in the context of that question. Some platforms are equipped for that, some aren’t. Dialogflow should be, Hubot isn’t, so relaying messages to Dialogflow via Hubot might lose that capacity. Adding another tier of dependency is not the solution, if anything, you’d want to be looking to remove Hubot from the loop by supporting a Dialogflow adapter.
There are however, plenty of cases where the button might legitimately convey something more complicated than just a text response, like triggering a callback to do something within Rocket.Chat or an external platform via API calls, etc. That should be dealt with via the rich message support schema, where a button object might have something like an action or onClick attribute. Maybe if that attribute wasn’t set, the default would be to submit the button text as a response. It could contain a Rocket.Chat method name to call, passing any other data attributes on the button as arguments to the method. Providing the method itself within Rocket.Chat would probably be best achieved through RC apps. E.g. An app would register a set of callbacks for bot button handlers, then the bot sends the payload with buttons to press and data to provide to the handlers.
The last concept @aaron.ogle suggested is similar to something @mikaelmello is working on right now with the bot manager ui and SDK updates. We’re working on a proposal to share with the forum, for an architectural solution to providing two-way event handling between the bot and server. The normal message stream the bot looks for is fine for most functions, but it relies on user creating messages for the bot to respond. We want to add utility for when the server needs to prompt the bot to do something that is not a response to a message. This was intended for managing the bot’s state or requesting data through an admin UI, but could also be extended to provide event handlers for other actions in the stream, like message payload button clicks. I think we actually have quite an exiting solution because it’s not catered to any specific feature, it’s a new fundamental component for all bots in the platform and I think people will find all kinds of uses for that we haven’t even considered yet.
Let the bot figure it out based on its knowledge of the state of the conversation
Include something like action or onClick attribute that would trigger a callback for bot button handles in RC apps.
As @aaron.ogle suggested, and you and @mikaelmello are working on, the solution to bot-initiated messages might provide a third solution, which is to have a separate stream for bot communication which might also help us solve the bot message context problem.
So in the short term, we will try to implement #1 using hubot/dialogflow. But if unsuccessful and as you suggest @tim.kinnane hubot filters out the information we need for that type of thing in dialogflow then we’ll go down a different route include perhaps switching to a botkit bot and using the new botkit adapter being developed.
Longer term, does the team envision creating a more comprehensive approach similar to the Slack interactive messages documented here? https://api.slack.com/interactive-messages
Is #2 above essentially a baby step towards full interactive message support? Note that interactive messages include a callbackId and other contextual information that allows the bot to easily understand what the user did and how to respond.
Thanks for your help in understanding the existing options and where we are headed.
Correct, but I only covered that to clarify it’s not really serving the intention you need, which seems like is basically ‘context’. The button actions would provide new utility to the CUI, but shouldn’t really be implemented to assist with the bot in dealing with state and context. That’s another concern which as I said, is handled by the bot platform, you want less abstraction, not more.
Yes maybe, but, again, just identifying that these avenues are being progressed, but with different utility in mind. I don’t think they’re all progressions of each other or even solutions to the same problem. To be specific, it’s not for bot-initialised comms either, it’s for the messaging application (RC) to make requests or send commands to the bot, not related to the messaging stream. So that could be from an admin interface or from a user doing something in the client, it’s really up to the creativity of the Rocket.Chat community. Still, I don’t think it’s a solution for tracking context.
I think adapting any one of those possible but not quite right options to fit your purpose, or even porting everything to Botkit, would still be more complicated that just making a dialogflow adapter and not using two bot frameworks on top of each other. It’s not on the RC roadmap currently, mostly because it’s not an open source platform, but all the building blocks are there and there’s more resources that would have a clue how to do it than there would be for forging some new solution hacking various unknown pieces together.
And yeah, Slack interactive message are great. But they aren’t dealing with conversational context, they’re just isolated controllers for events within the platform. They’re almost more of a UI extension than they are a bot feature. I don’t believe they’re tied into each other in any meaningful way, each component usage is basically a silo of logic attached to a single message event. This is where maybe a Rocket.Chat app could provide such features, which maybe bots would use, or maybe you wouldn’t even need a bot, just create the elements through regular application logic.
Has callback_id and type which help in identifying context. Basically when a bot sends an interactive message that contains an action it includes a callback_id to identify context. Such a thing would solve our immediate issue but I’m more generally interested to know if you think we are heading in a similar direction.
