Sync Preferences

[nplasterer]

Add ability to sync preferences just like we have sync on Conversations and Group.

Right now everything with consent V3 happens with the local DB. But we also want to send and sync these consent messages from the network as well.

You can see the local work here: #1057

• Can send consent records to the network
• Can sync consent records from the network

[codabrink]

Conflict resolution

This issue focuses on the initial consent sync that will be ideally run when a new installation is created, so that there will be no local state to reconcile with the incoming payloads. However, there are a few edge cases we should still consider.

What if the installation receives multiple sync responses.

The user will have to choose the device to sync from, putting in a pin on an existing device that matches the pin in the sync request to ensure that there is a user in the loop.

What if the user consents to a conversation they had denied on their previous installation before the payload is received?

The previous installation will make a best effort to process all streamed consent updates before building the consent payload, but there is still a window where the payload is uploading where this desync can happen.

If the user approves consent to a conversation on their new installation that they had previously denied on their previous installation, two things will happen:

1. The incoming payload will not overwrite the existing record.
2. Having recognized a discrepancy between local consent state and the payload's consent state, the new installation will stream the local consent state to as an update to the sync group in an attempt to reconcile the difference to the old installation(s).

What if a new installation creates a sync request, and goes offline for a month before coming back online to process the reply payload? Won't that cause major reconciliation issues?

If the sync payload timestamp is more than 1 hour old, the payload will be considered invalid, and a new request will have to be made.

[richardhuaaa]

This is a really good balance between handling edge cases and keeping things simple.

What if the user consents to a conversation they had denied on their previous installation before the payload is received?

There are some edge cases with the described solution, but I don't think they matter much - we're talking about a single user, so concurrency should be limited in practice. I like the simplicity of the solution.

The user will have to choose the device to sync from, putting in a pin on an existing device that matches the pin in the sync request to ensure that there is a user in the loop.

Adding a user interaction on the existing device puts UX requirements on all implementing apps that they may or may not want to service. One thing that would be desirable is if all apps by default can serve sync requests, so that we minimize the possibility that a user logs in on a different app and has no means of getting their backup from their existing app (as there is an interoperability risk here). Is there a world in which libxmtp will serve backup requests silently by default, but with strong encouragement in our docs for them to implement a pin UX?

[codabrink]

Adding a user interaction on the existing device puts UX requirements on all implementing apps that they may or may not want to service. One thing that would be desirable is if all apps by default can serve sync requests, so that we minimize the possibility that a user logs in on a different app and has no means of getting their backup from their existing app (as there is an interoperability risk here). Is there a world in which libxmtp will serve backup requests silently by default, but with strong encouragement in our docs for them to implement a pin UX?

I'm okay with replying silently by default, and the new installation accepting the first valid payload it receives for now and following up with something where the user gets to choose the device to sync from down the road. The downside of auto-replying by default that it makes the pin a moot point if we make it optional, as some front-end implementers will opt to not implement the pin feature, and will automatically reply to the sync request first before the user can input any pin and a Pin UX enabled device.

The alternative I can see is simulating a local-only group conversation in the lib that prompts the user to reply with the pin provided, and deleting that group as soon as the lib sees a reply in the sync group for that request_id. We of course would want to emphasize that the user should never share their private keys in a message with anyone else, and that we'd never ask for them in the same fashion as bank login texts, etc..

[richardhuaaa]

The downside of auto-replying by default that it makes the pin a moot point if we make it optional, as some front-end implementers will opt to not implement the pin feature, and will automatically reply to the sync request first before the user can input any pin and a Pin UX enabled device.

I think it depends on if you think of the pin as a user-level feature or an app-level feature. If we look at it as an app-level feature, we see that every app is a message store with its own security/access policy. Although a given app cannot guarantee the security of other apps a user may use, it can guarantee its own security. Keep in mind that an average user will not have many apps, and more security-conscious users will choose more security-conscious apps.

[neekolas]

This all sounds reasonable to me. Agree with Rich that we do want to keep the door open for silent acknowledgement of these requests, with the PIN as an optional confirmation.