Personal Preferences

[nplasterer]

Move this to V3

[nplasterer]

Personal Preferences are stored in our V3 database

1. Same as conversation history ie you need to sync from another device that has the personal preferences.
   You also need to sync all changes from that point forward. You need to relay that change from that point forward. A persistant identity group chat. Label it as group metadata for those that sync later.

Potentially breaking: Mutable metadata on the sync group? The way we do sync groups currently is not compatible with this. Which might require us to support external joins. State snapshot as part of the message history sync.

2. ~~ The same as V2 ~~
   Anytime a user signs in on a new device we ask them for a wallet signature. We give them the same payload to sign every time. Derive an encryption key from those bytes. A secret key that everyone of your devices can get. As long as they have access to your wallet. Wallet apis dont give us anything else but the ability to sign. Smart wallets don't have signatures over time and you might not have access to all wallets on each device.
   UX burden to request another signature from a user
   Deriving a encryption key from signature bytes is not standard

3. Make the user transport a secret between devices.
   They set a passcode or we give them a passcode. They have to remember this passcode on each login. When the sign in on a new device it pulls that file. A lot of UX burden. Authenticating double inside a app.

4. Threshhold cryptography or Shamir secret sharing
   You can have multiple backends each backend holds a piece of the secret. But not enough to get the full secret. Requires the backends to collide together. We would need to re implement the algorithm. We would need to store the keys.

[nplasterer]

Edge case
If you loose your device create a new account entirely.

This is only a PPPP issue since conversations will still get messages and would show up eventually.
We could let a split brain happen and they would merge eventually. Once you sign in and sync your consent the broadcast that to the new group. Whenever you log into another device with an inconstant state it can broadcast. Consent state is written in group metadate in one group just for consent.

We store the consent state and do a join table for them.
We have a group that is only your self and it consists of all of your installation. There needs to be mechanism to catch up a device that is behind. You can tell the device is behind because it sent a message history request that nobody responded to. Still requires a device online to catch up the new device.
We don't wipe we let you continue without the existing consent state.
If you don't sync everything will be in pending. When you come online from an old device then it will fix everything. Conflict resolution.

In order to get your history you need to have your other device.
Let the converse app do backups for you to the iCloud/GoogleCloud.

Work to be done

• A database of personal preference records stored in V3 with a join table on groups
• Back up and restore of the full state when the snapshot was requested. Upload a file to a server and have the other device download the file
• Broadcasting updates find the most recent sync group find the most recent sync group and send a message on that group communicating that action
• Local state machine of reading those updates and updating your local state
• Catching up the state if no device was around to restore the full state in the beginning (e.g. user was at work when setting up the new device, and their old device is at home - the old device can send the full state when it eventually does come online) -> requires conflict resolution
• Duel sending of V2 and V3 consent for a period of time
• Migration to port V2 consent into V3 database

[nplasterer]

• Addendum XIP https://community.xmtp.org/t/xip-42-universal-allow-and-block-preferences/544
• A new table for personal preference records in the local db
• Use sync group for sending preference snapshot (confirm server is not needed)
  • Broadcasting updates find the most recent sync group find the most recent sync group and send a message on that group communicating that action
  • Local state machine of reading those updates and updating your local state
• Duel sending of V2 and V3 consent for a period of time
  • Migration to port V2 consent into V3 database