xmtp / xmtp-dot-org

xmtp.org, powered by Docusaurus
https://xmtp.org
MIT License
10 stars 22 forks source link

Group Chat Syncing #731

Open nplasterer opened 1 month ago

nplasterer commented 1 month ago

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.

nplasterer commented 1 month ago

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.

nplasterer commented 1 month ago

https://github.com/xmtp-labs/xmtp-inbox-mobile https://github.com/xmtp/xmtp-ios/tree/main/XMTPiOSExample https://github.com/xmtp/xmtp-android/tree/main/example

jhaaaa commented 1 month ago

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

scotboyd commented 1 month ago

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.

nplasterer commented 1 month ago

https://github.com/xmtp/libxmtp/blob/main/xmtp_mls/README.md

cameronvoell commented 1 month ago

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.

nplasterer commented 1 month ago

@cameronvoell I think that makes sense. I can open an issue in the RN sdk to remove the default syncing?

scotboyd commented 1 month ago

Addressed in https://github.com/xmtp/xmtp-dot-org/pull/747