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?