-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Group Chat Syncing #731
Comments
iOS entitlements requires a encryption key on Android we can handle the key for you. The require the encryption key on React Native as well. |
Notes from Scot: Need demo sample with screenshots of what message history will look like - app a -- app b flow All theoretical otherwise. Show vs tell. UX-driven scenario. Build topic - checklist of options to support - need to see this Concepts topic - use case, talk about what the DB is doing |
Okay, based on rereading the above I think my notes from yesterday were for message history, and this is not message history. This is an update to build topics somewhere. |
To provide some context on the sync logic in the React Native SDK - I think we received early feedback that the syncing logic was confusing for developers initially trying out the first alpha release of Groups SDK in February, so we thought it might be helpful to default sync so that methods for listing group data "just work". This discussion resulted in the following pattern in the RN SDK: async listGroups(skipSync: boolean = false): Promise<Group<ContentTypes>[]> {
if (!skipSync) {
await this.syncGroups()
}
const result = await XMTPModule.listGroups(this.client)
for (const group of result) {
this.known[group.id] = true
}
return result
} In hindsight, that was probably a short-sighted decision, since all high quality group chat implementations should incorporate good decisions around when to sync groups from the network, rather than just default syncing every possible time. Since iOS and Android and libxmtp do not have any default syncing behavior, I propose we remove this from the RN SDK and instead focus on good documentation for devs on when they should be calling the various sync() methods for libxmtp and the client SDKs. |
@cameronvoell I think that makes sense. I can open an issue in the RN sdk to remove the default syncing? |
Addressed in #747 |
I think this deserves an entire section of documentation on since it diverges from what people expect in V2.
Now with Group Chat we have a managed SQL database that stores all of the messages. This means that conversations are not refetched every time only new messages fetched. Something fetched from the network is never refetch from the network giving huge performance improvements.
This means theres a notion of syncing now between local database and the network. When you call methods like listGroups it will just return whats in your local database if you want to get any new groups you will need to call conversations.sync and then listGroups.
If you create a group your self it will get added to your local database and a sync is not required.
This local database gets created on client create unless one exists then it will use the existing one. You can delete the local database by calling
client.deleteLocalDatabase()
An encryption key is required to use the local database. This should be stored in the secure enclave and provided anytime a client is created.
The text was updated successfully, but these errors were encountered: