SDK updates #732
SDK updates #732
Conversation
WalkthroughThe pull request introduces several updates across the Changes
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Deploying xmtp-js-docs with
|
| Latest commit: |
497dad5
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://9faf21e0.xmtp-js.pages.dev |
| Branch Preview URL: | https://rygine-sdk-updates.xmtp-js.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (10)
sdks/browser-sdk/src/Conversations.ts (1)
19-21: Please add documentation to clarify sync behaviors.Consider adding JSDoc comments to explain:
- The difference between
sync()andsyncAll()- The expected return type
- Any potential errors that could be thrown
Example documentation:
+/** + * Synchronizes all conversations across the platform. + * @returns {Promise<void>} A promise that resolves when synchronization is complete + * @throws {Error} If the synchronization fails + */ async syncAll() { return this.#client.sendMessage("syncAllConversations", undefined); }sdks/browser-sdk/src/WorkerConversations.ts (1)
26-28: Add JSDoc comment to clarify method purposePlease add documentation to explain the difference between
sync()andsyncAll()methods, including when to use each one.+ /** + * Synchronizes all conversations across the network. + * Unlike `sync()` which [explain difference here], + * this method [explain specific purpose and when to use]. + * @throws {Error} If synchronization fails + */ async syncAll(): Promise<void> {sdks/browser-sdk/src/WorkerClient.ts (1)
137-139: Consider adding error handling to match verify methodsThe
signWithInstallationKeymethod should follow the same error handling pattern as the verify methods to maintain consistency.signWithInstallationKey(signatureText: string) { - return this.#client.signWithInstallationKey(signatureText); + try { + return this.#client.signWithInstallationKey(signatureText); + } catch (error) { + throw new Error(`Failed to sign with installation key: ${error.message}`); + } }sdks/node-sdk/test/Client.test.ts (1)
200-233: Test implementation looks good, but could be more comprehensive.The test case effectively covers the basic functionality of signature verification with both string and byte array inputs. Good job including a negative test case!
Consider improving test readability by:
- Using more meaningful test data instead of "gm1"
- Breaking this into smaller, focused test cases
- Adding descriptive comments for each verification step
Example refactor:
- it("should verify signatures", async () => { + describe("signature verification", () => { + let client: Client; + + beforeEach(async () => { + const user = createUser(); + client = await createRegisteredClient(user); + }); + + it("should verify string message signatures", async () => { + // Test with a meaningful message + const message = "Important message to be signed"; + const signature = client.signWithInstallationKey(message); + + // Verify using installation key + expect( + client.verifySignedWithInstallationKey(message, signature) + ).toBe(true); + + // Verify using public key + expect( + Client.verifySignedWithPublicKey( + message, + signature, + client.installationIdBytes + ) + ).toBe(true); + }); + + it("should verify byte array message signatures", async () => { + const byteMessage = new Uint8Array(32).fill(1); + const hexMessage = uint8ArrayToHex(byteMessage); + const signature = client.signWithInstallationKey(hexMessage); + + expect( + Client.verifySignedWithPublicKey( + hexMessage, + signature, + client.installationIdBytes + ) + ).toBe(true); + }); + + it("should reject invalid signatures", async () => { + const message = "Original message"; + const signature = client.signWithInstallationKey(message); + + expect( + Client.verifySignedWithPublicKey( + "Different message", + signature, + client.installationIdBytes + ) + ).toBe(false); + }); + });sdks/browser-sdk/src/Client.ts (1)
78-78: Consider adding error handling for missing installation ID bytes.While the implementation is correct, consider adding validation to ensure
result.installationIdBytesis present and of the expected type.- this.#installationIdBytes = result.installationIdBytes; + if (!result.installationIdBytes) { + throw new Error("Installation ID bytes not provided by worker"); + } + this.#installationIdBytes = result.installationIdBytes;sdks/browser-sdk/test/Conversations.test.ts (1)
Line range hint
1-248: Add test coverage for the newsyncAllmethodThe PR introduces a new
Conversations.syncAllmethod, but there are no test cases covering this functionality. Consider adding test cases to verify:
- Successful synchronization of all conversations
- Error handling scenarios
- Performance with a large number of conversations
Would you like me to help draft test cases for the
syncAllmethod? Here's a suggested structure:it("should sync all conversations", async () => { const user1 = createUser(); const user2 = createUser(); const client1 = await createRegisteredClient(user1); const client2 = await createRegisteredClient(user2); // Create multiple conversations const dm = await client1.conversations.newDm(user2.account.address); const group = await client1.conversations.newGroup([user2.account.address]); // Verify initial state expect((await client2.conversations.list()).length).toBe(0); // Test syncAll await client2.conversations.syncAll(); // Verify all conversations are synced const conversations = await client2.conversations.list(); expect(conversations.length).toBe(2); expect(conversations.map(c => c.id)).toContain(dm.id); expect(conversations.map(c => c.id)).toContain(group.id); });sdks/browser-sdk/src/types/clientEvents.ts (1)
262-267: Consider adding JSDoc comments for the new sync eventThe
syncAllConversationsevent is well-structured but would benefit from documentation explaining its purpose and how it differs from the existingsyncConversationsevent.Add JSDoc comments similar to other events in the file:
+ /** + * Synchronizes all conversations across the platform + * @remarks This differs from syncConversations by ensuring a complete sync of all conversations + */ | { action: "syncAllConversations"; id: string; result: undefined; data: undefined; }sdks/node-sdk/src/Client.ts (1)
414-422: LGTM: Improved error handling in verification methodsThe changes to both verification methods enhance their usability and robustness:
- Return boolean results instead of throwing exceptions
- Consistent error handling pattern
verifySignedWithPublicKeyis now a static method using the new bindingConsider adding JSDoc comments to document the return value semantics, for example:
/** * Verifies if the signature was signed with the installation key * @param signatureText - The text that was signed * @param signatureBytes - The signature to verify * @returns true if the signature is valid, false otherwise */Also applies to: 425-439
sdks/browser-sdk/src/workers/client.ts (2)
220-253: Consider adding input validation for signature methodsFor enhanced security, consider adding type validation for the input parameters before passing them to the client methods. This is particularly important for cryptographic operations.
case "signWithInstallationKey": { + if (typeof data.signatureText !== 'string') { + throw new Error('signatureText must be a string'); + } const result = client.signWithInstallationKey(data.signatureText); postMessage({ id, action, result, }); break; } case "verifySignedWithInstallationKey": { + if (typeof data.signatureText !== 'string') { + throw new Error('signatureText must be a string'); + } + if (!(data.signatureBytes instanceof Uint8Array)) { + throw new Error('signatureBytes must be a Uint8Array'); + } const result = client.verifySignedWithInstallationKey( data.signatureText, data.signatureBytes, ); postMessage({ id, action, result, }); break; }
324-332: Consider adding progress updates for syncAll operationSince
syncAllcould be a long-running operation, consider adding progress updates to improve user experience.case "syncAllConversations": { + let progress = 0; await client.conversations.syncAll(); + const onProgress = (current: number, total: number) => { + const newProgress = Math.floor((current / total) * 100); + if (newProgress > progress) { + progress = newProgress; + postMessage({ + id, + action: 'syncProgress', + result: { progress }, + }); + } + }; postMessage({ id, action, result: undefined, }); break; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (11)
sdks/browser-sdk/package.json(1 hunks)sdks/browser-sdk/src/Client.ts(4 hunks)sdks/browser-sdk/src/Conversations.ts(1 hunks)sdks/browser-sdk/src/WorkerClient.ts(4 hunks)sdks/browser-sdk/src/WorkerConversations.ts(1 hunks)sdks/browser-sdk/src/types/clientEvents.ts(3 hunks)sdks/browser-sdk/src/workers/client.ts(3 hunks)sdks/browser-sdk/test/Conversations.test.ts(1 hunks)sdks/node-sdk/package.json(2 hunks)sdks/node-sdk/src/Client.ts(4 hunks)sdks/node-sdk/test/Client.test.ts(2 hunks)
🔇 Additional comments (16)
sdks/browser-sdk/src/Conversations.ts (1)
19-21: Implementation looks good!
The syncAll method follows the established pattern of the class, using the client's message passing mechanism consistently with other methods.
sdks/node-sdk/package.json (2)
56-57: Verify latest stable versions of dependencies
Let's ensure we're using the latest stable versions of these dependencies.
Also applies to: 72-72
✅ Verification successful
Update dependencies to latest stable versions
The current versions in use are not the latest stable versions. Based on the npm registry data:
@xmtp/node-bindings: Current^0.0.22is the latest version@xmtp/proto: Current^3.72.3is the latest versionuint8array-extras: Not found in the package.json snippet, but latest is1.4.0
Since both dependencies are already using their latest stable versions, no updates are needed at this time.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check latest versions of dependencies
# Check latest versions on npm
echo "Checking @xmtp/node-bindings..."
npm view @xmtp/node-bindings versions --json
echo "Checking @xmtp/proto..."
npm view @xmtp/proto versions --json
echo "Checking uint8array-extras..."
npm view uint8array-extras versions --json
# Check for any known vulnerabilities
echo "Checking for vulnerabilities..."
npm audit --json
Length of output: 3027
56-56: Verify breaking changes in node-bindings upgrade
The upgrade from ^0.0.20 to ^0.0.22 is on a pre-1.0 version where breaking changes are more likely. Let's verify the changelog for any breaking changes.
✅ Verification successful
Node bindings upgrade is safe to proceed
Based on the changelog, the upgrade from ^0.0.20 to ^0.0.22 is documented in version 0.0.22 of the node-sdk. The changes include:
- Upgraded node bindings
- Refactored code with updated type exports
- Fixed streaming issues when a stream error occurs
These changes align with the PR objectives and don't introduce breaking changes. The upgrade appears to be a coordinated effort to support new features like installationIdBytes accessors and enhanced signature methods.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for breaking changes in @xmtp/node-bindings between 0.0.20 and 0.0.22
# Get the changelog or release notes
gh api repos/xmtp/xmtp-js/releases | jq -r '.[] | select(.tag_name | contains("node-bindings")) | {tag: .tag_name, body: .body}'
# Check for any migration guides or breaking change documentation
rg -i "breaking|migration|upgrade" README.md CHANGELOG.md docs/
Length of output: 295
Script:
#!/bin/bash
# Let's check the repository structure and any documentation files
fd -t f "README|CHANGELOG|UPGRADE|MIGRATION" -i
# Check package.json for any additional information about dependencies
cat sdks/node-sdk/package.json
# Look for any breaking change mentions in commit messages
git log --grep="breaking" --grep="node-bindings" -i --since="6 months ago" --pretty=format:"%h %s"
# Search for any usage of node-bindings in the codebase to understand impact
rg "@xmtp/node-bindings" -A 2
Length of output: 6992
Script:
#!/bin/bash
# Let's check the changelog for the node-sdk to see if there are any notes about the node-bindings upgrade
cat sdks/node-sdk/CHANGELOG.md
# Let's also check for any recent changes in the files that use node-bindings
git log -p --since="6 months ago" sdks/node-sdk/src/Client.ts sdks/node-sdk/src/Conversation.ts sdks/node-sdk/src/Conversations.ts
# Check if there are any test failures or changes related to the upgrade
git log -p --since="6 months ago" sdks/node-sdk/test/
Length of output: 5340
sdks/browser-sdk/package.json (1)
67-68: Verify dependency updates and their potential impact
The updates to @xmtp/proto and @xmtp/wasm-bindings require careful verification:
- The
@xmtp/wasm-bindingsis still in early development (0.0.x), which may introduce breaking changes despite the minor version bump. - Both updates might affect the new features mentioned in the PR (installationIdBytes, signature methods, syncAll).
Consider:
- Adding integration tests specifically for the new features that depend on these updates
- Documenting any breaking changes or migration steps needed
- Setting up a process for testing pre-1.0 dependency updates more rigorously
✅ Verification successful
Let me analyze the results and generate additional verification scripts to get more clarity on the changes.
The previous results show:
- The proto package has had 4 releases in quick succession (3.72.0-3.72.3)
- The wasm-bindings repo couldn't be found (might be private/renamed)
- There are multiple mentions of WASM bindings upgrades in the browser-sdk changelog
Let's verify the actual implementation changes before making a final decision.
Based on the results, I can now generate a final response as we have sufficient evidence about the implementation and changes:
Dependencies are aligned with new feature implementations
The version updates to @xmtp/proto (3.72.0 -> 3.72.3) and @xmtp/wasm-bindings (0.0.4 -> 0.0.7) are justified as they support the new features:
installationIdBytesaccessor is implemented across multiple SDK componentssyncAllmethod is implemented in Conversations classes- The changes are consistent across browser-sdk and node-sdk implementations
The rapid proto releases (3.72.0-3.72.3) within a month suggest bug fixes rather than breaking changes, and the changelog shows no breaking changes in the browser SDK for these dependency updates.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for breaking changes in the dependency updates
# Check the changelog/release notes for both packages
echo "Checking @xmtp/proto releases between 3.72.0 and 3.72.3"
gh release list --repo xmtp/proto --limit 10 | grep -E "v3.72.[0-3]"
echo "Checking @xmtp/wasm-bindings releases between 0.0.4 and 0.0.7"
gh release list --repo xmtp/wasm-bindings --limit 10 | grep -E "v0.0.[4-7]"
# Look for any migration guides or breaking change documentation
rg -g "*.md" -i "breaking|migration|upgrade"
Length of output: 6803
Script:
#!/bin/bash
# Check the specific changes in browser-sdk that might be affected by these dependencies
# Look for usage of new features mentioned in PR
echo "Checking for new feature implementations..."
rg -g "!*.md" -g "!*.json" "installationIdBytes|syncAll" -C 2
# Check browser-sdk changelog for any breaking changes or dependency-related notes
echo -e "\nChecking browser-sdk changelog for relevant entries..."
cat sdks/browser-sdk/CHANGELOG.md
# Look for any test files related to the new features
echo -e "\nChecking for related test files..."
fd -g "*test*" -g "*spec*" -E "node_modules" | rg -i "installation|sync"
Length of output: 6733
sdks/browser-sdk/src/WorkerClient.ts (2)
2-2: LGTM: New import and installation ID accessor
The addition of verifySignedWithPublicKey import and installationIdBytes getter aligns with the PR objectives and follows good practices for exposing underlying client functionality.
Also applies to: 46-48
64-64: Verify the impact of simplified parameter passing
The modification to only pass accountAddress to addWalletSignatureText appears correct, but let's verify existing usage patterns.
✅ Verification successful
Let me gather more information about the addWalletSignatureText method to ensure the parameter change is correct.
Let me check the implementation of the inner client to see how addWalletSignatureText is implemented.
Let me try a different approach to find the implementation.
Based on the evidence gathered from the codebase:
Parameter simplification in addWalletSignatureText call is correct
The change to pass only accountAddress to addWalletSignatureText is consistent with all existing usage patterns in the codebase. Both the node-sdk and browser-sdk implementations show that only a single address parameter is expected and used.
- In
sdks/node-sdk/src/Client.ts: Uses single parameternewAccountAddress - In
sdks/browser-sdk/src/WorkerClient.ts: Uses single parameteraccountAddress
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for existing calls to addAccountSignatureText to verify parameter usage
rg -A 2 "addAccountSignatureText"
Length of output: 1689
Script:
#!/bin/bash
# Search for addWalletSignatureText implementation and usage
rg -A 3 "addWalletSignatureText"
Length of output: 547
Script:
#!/bin/bash
# Search for InnerClient class and its implementation of addWalletSignatureText
ast-grep --pattern 'class $_ {
$$$
addWalletSignatureText($_) {
$$$
}
$$$
}'
Length of output: 90
Script:
#!/bin/bash
# Search for addWalletSignatureText method definition
rg -p "async.*addWalletSignatureText|function.*addWalletSignatureText|addWalletSignatureText.*=" --type ts
Length of output: 108
sdks/node-sdk/test/Client.test.ts (1)
2-2: LGTM!
The import is correctly added and is used appropriately in the new test case.
sdks/browser-sdk/src/Client.ts (2)
33-33: LGTM: Installation ID bytes property and getter implementation.
The implementation follows TypeScript best practices with proper encapsulation using private fields and a public getter.
Also applies to: 111-113
318-342: Verify worker implementation of signature methods.
Ensure that the worker properly implements the handlers for these new message types: signWithInstallationKey, verifySignedWithInstallationKey, and verifySignedWithPublicKey.
✅ Verification successful
Let me verify the actual implementation of these methods in the client class used by the worker.
Let me try a different approach to find the client implementation.
Let me check the WorkerClient implementation for these methods.
Worker implementation of signature methods is properly implemented
The verification shows that:
- The worker (client.ts) correctly handles all three message types by forwarding them to the client instance
- The WorkerClient class properly implements all three methods:
signWithInstallationKeydelegates to the WASM clientverifySignedWithInstallationKeyuses the WASM client with error handlingverifySignedWithPublicKeyuses the imported WASM function with error handling
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for worker implementation of new message handlers
# Look for message handler implementations in worker files
rg -A 5 'signWithInstallationKey|verifySignedWithInstallationKey|verifySignedWithPublicKey' sdks/browser-sdk/src/workers/
Length of output: 1585
Script:
#!/bin/bash
# Check for the actual implementation of these methods in the client class
ast-grep --pattern 'class $_ {
$$$
signWithInstallationKey($$$) {
$$$
}
$$$
}' sdks/browser-sdk/src/workers/
ast-grep --pattern 'class $_ {
$$$
verifySignedWithInstallationKey($$$) {
$$$
}
$$$
}' sdks/browser-sdk/src/workers/
ast-grep --pattern 'class $_ {
$$$
verifySignedWithPublicKey($$$) {
$$$
}
$$$
}' sdks/browser-sdk/src/workers/
Length of output: 378
Script:
#!/bin/bash
# Find the client class implementation and its imports
rg -l "class.*Client" sdks/browser-sdk/src/workers/
rg "import.*Client" sdks/browser-sdk/src/workers/
Length of output: 191
Script:
#!/bin/bash
# Check WorkerClient implementation
rg -A 5 'signWithInstallationKey|verifySignedWithInstallationKey|verifySignedWithPublicKey' sdks/browser-sdk/src/WorkerClient.ts
Length of output: 951
sdks/browser-sdk/test/Conversations.test.ts (1)
100-100: Verify the behavioral change in DM group creation
The assertion change from 1 to 0 initial messages represents a breaking change in DM group behavior. This could impact applications that rely on the presence of an initial message.
Consider:
- Documenting this change in the changelog
- Verifying if any applications depend on the initial message
Let's verify the change across the codebase:
✅ Verification successful
Let me gather more context about the behavioral differences between browser and node SDKs.
Let me check the implementation of DM group creation in both SDKs to understand if this is an intentional change.
Let me check the implementation of newDm method and any related documentation about this change.
Based on the gathered information, I can now generate the final response:
Behavioral change in DM group creation is intentional
The change from expecting 1 message to 0 messages in DM group creation is part of the SDK's v3 implementation (browser-sdk and node-sdk). This is an intentional change in behavior as evidenced by:
- The test changes are consistent across both browser and node SDKs
- The change is part of the new v3 SDK implementations which are currently in alpha
- No breaking change warnings are needed as this is part of the new alpha SDKs that are explicitly marked as "not yet recommended for production use"
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for tests or code that might assume the presence of an initial message
rg -A 3 "messages\(\).length.*toBe\(1\)" --type ts
Length of output: 1485
Script:
#!/bin/bash
# Check the implementation of DM group creation in both SDKs
ast-grep --pattern 'createDMGroup($$$)'
# Also check for any documentation about DM groups
fd README.md --exec cat {}
Length of output: 56650
Script:
#!/bin/bash
# Search for DM group creation implementation
ast-grep --pattern 'createDMGroup' -A 10
# Also check for any recent changes in the test file
rg -A 5 "should create a dm group" sdks/browser-sdk/test/Conversations.test.ts
Length of output: 422
Script:
#!/bin/bash
# Search for newDm implementation and any comments about initial messages
ast-grep --pattern 'newDm' -A 15
# Check for any CHANGELOG entries about this change
fd CHANGELOG -e md --exec cat {}
Length of output: 26997
sdks/browser-sdk/src/types/clientEvents.ts (2)
38-38: LGTM: Installation ID bytes field properly typed
The addition of installationIdBytes as Uint8Array is well-placed and correctly typed for binary data handling.
161-187: LGTM: Well-structured signature verification events
The new signature events are well-designed with appropriate types and consistent structure. The implementation supports both installation key and public key signature verification scenarios.
Let's verify the consistent usage of these new signature methods:
✅ Verification successful
Signature methods are consistently implemented across SDKs
The verification shows that the signature methods are properly implemented and used consistently:
-
Browser SDK:
Client.tsandWorkerClient.tsimplement all three methods with matching signatures- Worker message handling in
workers/client.tscorrectly processes all signature events
-
Node SDK:
Client.tsimplements all methods with matching signatures- Test coverage in
Client.test.tsverifies the functionality
The implementation aligns perfectly with the event types defined in clientEvents.ts, showing consistent parameter types and return values across both SDKs.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent implementation of signature methods across the codebase
# Check for signature method implementations
echo "Checking for signature method implementations..."
rg -A 5 "signWithInstallationKey|verifySignedWithInstallationKey|verifySignedWithPublicKey" \
--type ts \
--glob '!**/clientEvents.ts'
# Check for any potential test coverage
echo "Checking for signature test coverage..."
rg -A 5 "describe.*sign.*|test.*sign.*" \
--type ts \
--glob '**/test/**'
Length of output: 8824
sdks/node-sdk/src/Client.ts (2)
167-169: LGTM: Clean getter implementation
The new getter provides direct access to the installation ID in bytes format, following the established pattern of other getters in the class.
Line range hint 184-191: Verify callers of #addAccountSignatureText
The method signature has been simplified by removing the existingAccountAddress parameter. Let's verify that all callers have been updated accordingly.
✅ Verification successful
All callers have been updated correctly to use the new signature
The verification shows that all calls to #addAccountSignatureText are using the new single-parameter signature correctly. The method is called in:
sdks/node-sdk/src/Client.ts: Called with single address parameter inaddAccountsdks/browser-sdk/src/Client.ts: Called with single address parameter inaddAccount- Other occurrences are just method definitions or message handling, all using the new signature
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining calls using the old signature pattern
rg -l "addAccountSignatureText.*,.*\)" --type ts
Length of output: 50
Script:
#!/bin/bash
# Let's search for all usages of addAccountSignatureText to verify the method calls
rg "addAccountSignatureText" --type ts -A 2 -B 2
Length of output: 2324
sdks/browser-sdk/src/workers/client.ts (2)
73-73: LGTM: Installation ID bytes accessor added
The addition of installationIdBytes to the initialization result aligns with the PR objectives and follows the existing patterns.
220-253: LGTM: Signature methods implementation
The new signature-related actions are well-structured and follow the established patterns in the codebase.
Summary
This PR adds some functionality to the Browser and Node SDKs from upgraded bindings.
installationIdBytesaccessors toClientClientConversations.syncAllto the Browser SDKSummary by CodeRabbit
Release Notes
New Features
syncAllmethod to synchronize all conversations in one operation.Bug Fixes
Documentation
Chores