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.
