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]

Basic Functionality

• 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 - Private Preferences DB #946
• Expose functions in the bindings to add consent records and get consent records including convenience methods for getting consent on group chats
• Dual sending of V2 and V3 consent for a period of time
  • When loading the consent list write all those records to the V3 database if they don't already exist
  • Set a list instead of iterating https://github.com/xmtp/xmtp-android/pull/297/files#r1759609079
  • Add ability to create pure v3 client for testing https://github.com/xmtp/xmtp-android/pull/298/files
  • Also do on iOS
  • Also do on RN
• Syncing with the network
• Streaming consent

Interoperability

• Update the sync to handle receiving a request to get this message sent.
• Proto for this new message type so that when received we know what to do with it.
  • process_external_message new type
• Add the code to receive this message and update the local database with it.
  • Serialize and Deserialize from the database file so we can send it in a message

[nplasterer]

Client 1
Sending the request to send the consentMessage (sends a new consent message type proto to the sync group) -- should happen anytime a new installation is created by default but can be disabled.
Receiving the consentMessage (via a stream versus via sync NEED TO VALIDATE)
Deserializing the consentMessage

Client 2
Receiving the request to send the consentMessage (in the sync group)
Serializing and sending the consentMessage (sends to the sync group)

There should only be 1 sync group. Look for the sync group if we can't find it create it.
Manually post the current state of the group sync. Embed it into a message. 1mb is the max size of a message. Compress the string. 600,000 wallets. Set an option to not have implicit consent. Allowing people to be able to download a file that's encrypted. Also add a button to export and import. Deletes backup every week. No history url because it's just a message.