Compatibility with Mobile SDK

Context

Before starting the integration of authenticated messaging, you need to make sure to plan the deployment of the feature depending on your use case.

If you are planning on deploying this feature on the web and on the mobile SDK, there are a few things you need to know:

• Will end-users authenticate on the app AND on the website?

• If so, will you deploy authenticated messaging at the same time on the mobile app and the website?

How is authenticated messaging implemented on the Mobile SDK?

There is a full section dedicated to Mobile SDK where you will find the information regarding authenticated messaging.

Basically, you can choose between multiple authentication options:

Anonymous	For an unidentified user browsing your app.
Simple	For a logged in user in your app. You must pass a unique string identifier so that the visitor will retrieve his conversation history across multiple devices and platforms. The identifier that you pass must be unique and non-discoverable for each different logged-in user.
Secured	Use it in conjunction with your in-house authentication system. You must pass a JWE provider callback that will be called when an authentication is required, you will then have to call your third party authentication system for a valid JWE to provide to the SDK. For a full understanding of how the secured authentication works in the iAdvize platform you can refer to this section.

Important: if you want to start using the secured mode as a second step, we strongly advise that you implement the anonymous mode as a first step. Indeed, if you choose the simple mode first, your users will loose all their conversation history the day you decide to switch to the secured mode. If however you implemented the anonymous mode, they will be able to keep it.

Implementation scenarios

Context	Actions
I want to launch on web only (no Mobile SDK used)	Follow this documentation - nothing specific to keep in mind regarding the Mobile SDK
I want to launch on web only (and I do use the Mobile SDK at the same time but I don't want the feature there)	Follow this documentation AND make sure the iAdvize hybrid flag is activated (ask an iAdvize TAM). This will allow you to use the simple mode on Mobile SDK while having the feature deployed for your website
I want to launch on Mobile SDK only (no Web used)	Follow this documentation (choose the secured option) - nothing specific to keep in mind regarding the web
I want to launch on Mobile SDK only (and I have the chat on my website but I don't want the feature to be deployed there)	Follow this documentation and choose the secured option
I want to launch on both: web and Mobile SDK at the same time.	Follow this documentation for the web part and this documentation for Mobile SDK (choose the secured option)

What is actually happening in the logout within the SDK that could restore the chat the next time the user is logging in again?

This is dependent on the type of activation that was made.

If the user was logged in anonymously, then the SDK keeps some information during the logout.

This is designed so that if an anonymous visitor starts chatting then logs into your app, the SDK calls to logout / activate (simple or secured) would keep the user's ongoing conversation / conversation history.

If the user was logged in "non-anonymously" (either with simple auth or secured auth), then the logout clears the whole user session. Please note however that if you log a user with an “already known" user id, the visitor session (history, parameters) will be pulled back. This is designed for chat history continuity across devices.

1. activate anonymous
2. starts a chat
3. logout (sdk keeps visitor info)
4. activate (simple or secured)
==> the chat history is retrieved 

1. activate (simple or secured), user-id = foo
2. starts a chat
3. logout (sdk keeps visitor info)
4. activate (simple or secured), user-id = foo
==> the chat history / gdpr conset etc... are retrieved 

1. activate (simple or secured), user-id = foo
2. starts a chat
3. logout (sdk keeps visitor info)
4. activate (simple or secured), user-id = bar
==> a new user session starts