Persistent Issue: XMTP Browser Client Reuses Revoked Installation After Logout/Re-login (SDK V3.0.1)

Archives General Discussion
1

We are encountering a critical issue where an XMTP client, after its installation has been explicitly revoked by another device, fails to re-initialize correctly upon subsequent attempts to log in. Instead of creating a new installation for the same inbox, the client appears to reuse the previously revoked installation, leading to complete messaging failures.

Steps to Reproduce:

  1. Initial Setup:

  • On Chrome Browser (Installation A):

    • Log in to XMTP using wallet account 0xabc....

  • On Brave Browser (Installation B):

    • Log in to XMTP using the same wallet account 0xabc... This correctly creates a new installation for the same inboxId.
  1. Revocation:
  • From Brave Browser (Installation B): Programmatically revoke Installation A (Chrome Browser).
  1. Attempted Re-login on Revoked Device:
  • Go back to Chrome Browser (Installation A).
  • Perform a full disconnect/logout sequence: await clientA.close();
  • Attempt to log in again using the same wallet account

Observed Behavior:

  • The Chrome browser client is not prompted to sign a message for a fresh installation.
  • Instead, it appears to re-initialize and attempt to use the old, revoked installation (Installation A).
  • When attempting to send a message using this re-initialized client on Chrome, we receive the following errors, indicating a severe state mismatch:
Error: ================================= Errors Occured During Sync ===========================
2 errors publishing intents

=========================== Processed Messages Summary  =====================
Processed 15 total messages in cursor range [Some(6098354) ... Some(6098834)]
Failed to process [30] messages in cursor range [Some(6098354) ... Some(6098834)]
[2] unique errors:
12 ids errored with [openmls process message error: Message epoch differs from the group's epoch.]
18 ids errored with [openmls process message error: An error occurred during AEAD decryption.]
Succesfully processed 0 messages in range None ... None
=============================================================================
========================================================================================```

Expected Behavior:

When an XMTP installation is revoked, and the user subsequently attempts to log back in with the same account on that device, we expect the client to:

  1. Correctly identify that its previous installation is no longer valid on the XMTP network.
  2. Prompt the user to sign a message to create a brand-new installation for their existing inboxId.
  3. Allow the user to send and receive messages successfully with this newly generated, valid installation, maintaining access to their conversation history.

Environment:

  • SDK: @xmtp/browser-sdk V3.0.1

Question:

How can we correctly handle this scenario to ensure the client properly re-establishes a valid installation after a revocation event, and avoid these synchronization and decryption errors?

4 Likes