Multi transport is the feature of RedBot to handle the communication with the same user using different transports, for example handling a conversation with the same user through Facebook and/or SMS with a custom business logic.

A possible scenario is, for example, an alert service that try send a message to a user using Facebook and, if there’s no answer from him, use a secondary transport like SMS.

In RedBot the chatId is the universal identifier for a user using a specific trasport. For example the chatId of the Twilio tranport is the user’s phone number while in Telegram is a numerical ID assigned by the Telegram’s server. The userId is the unique identifier of the user in RedBot and it’s related to the chatId in a one-to-many relation: a user can have one or more chatId (a different one for each transport).

The multi transport feature is optional, it’s possible to use RedBot without having to deal with the concept of userId. In order to enable this feature a resolver must be defined in the [[Extend node|Extend-node]] which is basically a piece of code that answer the question “which is that chatId for a trasport of a defined user?”.

Once enabled the multi-transport feature, it will possible - start a conversation with just the userId (without specifing a transport and a chatId) - use the [[Node rules|Node-rules]] to test if a particular transport is available or is predefined for that user - send any message from any receiver (or [[Conversation node|Conversation-node]]) to any sender, no matter of the transport (if the resolver is able to find the right chatId for a userId)

The resolver is basically an asynchronous function that takes two parameters (the userId and the tranport) and returns a chatId

node.chat.onGetChatIdFromUserId(function(userId, transport) {  return MyDatabaseConnector.Users.findWhere({ userId, transport })    .then(result => result.chatId);});

The resolver could be anything and it’s asynchronous: a call to a MongoDB instance or an HTTP call. In the example above it must exists a row in the database with the tuple userId/transport/chatId, if the chatId is null or the resolver returns an error, the Sender node throws an error.