Can I set rasa-webchat live chat with the website host username as sender_id?

I want to integrate a live chat into an existing website that users can navigate with or without logging-in.

Optimally I want to manage two different scenarios:

  1. user could chat with the assistant through the live chat, even if not (yet) logged for general info, etc.

  2. But the basic requirement is that user must log in the website with his credentials (username/password) and afterward he can chat with the assistant backend as a logged-in user with a single user_id (say the username == his email). In that way the assistant can profile/personalize answers.

Reading the RASA connectors guide: https://rasa.com/docs/rasa/user-guide/connectors/your-own-website/ I understand that I can configure RASA to accept socketio channel and a good candidate for the websocket live chat integrations seems the project: GitHub - botfront/rasa-webchat: A feature-rich chat widget for Rasa and Botfront

My question is about how to possibly simply configure the sender_id equal to the username with rasa-webchat.

The integration seems seamless in case of an “impersonal” chat , and as I well understood, in this case the sender_id is set with a random value. That’s ok for the case (1)

But how can I manage the case (2)? Reading GitHub - botfront/rasa-webchat: A feature-rich chat widget for Rasa and Botfront, seems to me that te solution is to build a custom connector to manage customData={{sender_id: 'aUserName'}}. really? :frowning:

I wish that when user is logged in, his username is used as sender_id could be used utomatically in the WebChat.default.initjavascript request.

Any idea?

Thanks
giorgio

A solution: Can I set rasa-webchat live chat with the website host username as sender_id? · Issue #233 · botfront/rasa-webchat · GitHub

I see two ways to do this:

  • implement your own custom channel
  • send the username as first message e.g. (/my_init_intent{"username": "xy"} and then store it as a s slot within the conversation.

Thanks @Tobias_Wochinger

yes, the second mode (send and explicit intent setting a slot) confirm previous answer and seems to me a nice way to allow user to conversate with the bot, in two different roles:

  • as anonymous user (not “yet” logged user)
  • as logged user (after /my_init_intent{"username": "xy"})

“yet” because by example the livechat could be always available (for generic chat/FAQ/impersonal topics) but the chat could react to specific domains based on the specific username profile.

The drawback of this solution is that rasa webchat component sender_id is useless to identify user. That not necessarily bad, but also …


The first solution you suggests, could help in te scenario where RASA bot has many channels (connectors). In this case I probably need to manage an unique user_id (== sender_id) map explicitly.

By example, say we need to have 3 channels in parallel:

  • a live chat channel,
  • Telegram instant messaging channel,
  • an e-mail channel too.

Suppose also the bot has to push notifications to user (say on the Telegram/e-mail).

In this case I guess I have to manage a user_id gateway, that’s a dictionary mapping unique sender_id to the id of each channel. By example:

unique sender_id = 'Giorgio Robino'

Telegram sender_id = '123456789'
E-mail sender_id = 'giorgio.robino@blablabla.it'
Rasa Webchat sender_id = '67werwer67wdafdsudf78725'

see also: Unique user_id for many channels in parallel: how to?

isn’t it?

Mhm, then I think it’s indeed the best if you have some component in your infrastructure which keeps these mappings :thinking:

1 Like