Feature request: Example App Demonstrating active "load history from other installation" flow

[cameronvoell]

Is your feature request related to a problem?

In XMTP, when a user with an existing InboxID uses their signing keys to log on to a new device, the initially have zero conversations and zero message history.

Currently there is a "passive flow" where actions taken on the users other device, as well as actions taken by participants in that users groups may slowly re-add Conversation and Message state to the new device. For example:

• A) When another participant from a group with our user syncs that group, they may check if any other group participants have new installation keys added to their inbox, and if so, add that new installation to the group. See sync() => maybe_update_installations() If that happens, our new device will receive a welcome message and be added to the group (without message history). But they will be able to participate in the group going forward.
• B) If the other participant in the group is our other installation key associated with the same Inbox_id, and they sync all their groups, they should theoretically add our new device to all existing groups, and at that point our new device would have access to all conversations their InboxID is a part of.
• C) For loading message history the new device can request a history sync <insert link to libxmtp code here>. But for the history sync to be successful, the following actions need to happen on the user's other active device:
  • Step 1 - <to be filled in with link to libxmtp code>
  • Step 2 - <to be filled in with link to libxmtp code>

One problem with the flow above is that A) it's confusing for users and integrators to not understand why they are missing conversations and messages, and B) it opens the door for new installations to make duplicate DMs. We have a "stitching" solution for recombining duplicate DMs, but it would still be preferable for that to be an edge case instead of the default for users starting out on a new installation.

Describe the solution to the problem

In order to address this problem, we would like to demonstrate in the iOS example app an "active flow" that a new installation could take upon logging in on a new installation that would allow them to take explicit action to sync all existing conversations and messages, if they have another device available. An example active flow for restoring all conversations and messages on a new device is as follows:

1. After a client create action occurs, check how many installations the logged in user has via inboxState functions. If the user has multiple installations and no conversations, prompt the user asking if they have access to another device logged on to their account that they can use for restoring conversations and messages.
2. If the user says no, show a nice message explaining that in order to protect their privacy they cant get conversations and message history without an existing device, but they will receive new messages in their old groups.
3. If the user does have access to another device, the goal is to walk them through the steps B) and C) from the passive flow above, using their two devices.

Describe the uses cases for the feature

No response

Additional details

No response

[cameronvoell]

@codabrink when you get a chance, could you help fill in section C in the description above. Idea is to have enough detail to identify what if any new functions we may need to add to bindings in order to create a more active version of this flow.