• Setup API Client
• Setup Index DB
• Integrate with SDK

wasm_bindgen expects a JsValue to be returned from any function that can throw.

Currently, we handle this by returning JsError from all of our wasm bindings. This has the effect of auto-converting from Rust std::err::Error to JsError automatically via JsError::from, and then into JsValue via JsError::into.

The implementation of JsError::from is the JS equivalent of calling new Error(...) with the string generated from calling to_string() on the Rust error, which doesn't give consumers the opportunity to differentiate between different types of errors in code.

A workaround would be to define custom JS Error subclasses and import them into Rust, or define a special JS XMTPError type with an enum field and mappings from all known errors to this enum.

More info at rustwasm/wasm-bindgen#1742 (comment)

Is your feature request related to a problem?

It would be nice to have a way to identify a conversation. I'd say "peer address" though in a world with group chat, that makes less sense. Maybe topic info?

https://github.com/xmtp/libxmtp-swift/blob/main/Sources/LibXMTP/xmtpv3.swift#L399C36-L463

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Provision installations through both SDK’s. Send messages through both.

Describe the bug

There's no way to access data about an FfiMessage such as content or sender address.

See https://github.com/xmtp/libxmtp-swift/blob/main/Sources/LibXMTP/xmtpv3.swift#L661-L676.

Expected behavior

No response

Steps to reproduce the bug

No response

Is your feature request related to a problem?

Re: cloning in #91

It seems like we should be able to pass pointers FFI layer via swift-bridge, instead of cloning.

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

This ramp-up task will get you familiar with the database, with Rust error handling, and with writing unit tests.

We are using Diesel ORM with a sqlite database. Most of the DB operations are in mod.rs for encrypted store. We are using Diesel::insert_or_ignore in a few places, for example:

Originally, the reason for this was to ignore duplicate insertion errors, so that the operation is idempotent if it is called twice and the row already exists. However, a problem with Diesel::insert_or_ignore is it will ignore all errors, including foreign key constraint violations, for example - which results in the row silently not being inserted at all. This makes debugging difficult.

Describe the solution to the problem

My rough idea is to just use the normal Diesel::insert, and then add code specifically to detect when a duplicate primary key error happens and just return Ok(), while surfacing the rest of the errors normally. This could be put in a helper method that is used everywhere insert_or_ignore was used. I also thought about using upsert, but we don't want to update any columns (e.g. state) if a row already exists. It's up to you what the best way of doing this is.

Ideally we add a unit test for this as well.

Describe the uses cases for the feature

No response

Additional details

No response

Describe the bug

Right now it's impossible to call listMessages(opts:) because the expected argument type for opts doesn't have a public intitializer: https://github.com/xmtp/libxmtp-swift/blob/main/Sources/LibXMTP/xmtpv3.swift#L608-L621

Expected behavior

No response

Steps to reproduce the bug

No response

We can generate/store the vmac keys as-is.
If there are already keys on disk, we should read those into memory as part of initialization.

Wallet signing the identity key and possibly the fallback key is left as a separate task for simplicity.

Example: https://github.com/xmtp/libxmtp/actions/runs/5166007186/jobs/9305846305

ld: error: undefined symbol: __extenddftf2
          >>> referenced by sqlite3.c
          >>>               sqlite3.o:(sqlite3_str_vappendf) in archive /target/x86_64-linux-android/release/deps/liblibsqlite3_sys-a59c0c668a489339.rlib
          >>> referenced by sqlite3.c
          >>>               sqlite3.o:(sqlite3_str_vappendf) in archive /target/x86_64-linux-android/release/deps/liblibsqlite3_sys-a59c0c668a489339.rlib
          >>> referenced by sqlite3.c
          >>>               sqlite3.o:(sqlite3_str_vappendf) in archive /target/x86_64-linux-android/release/deps/liblibsqlite3_sys-a59c0c668a489339.rlib
          >>> referenced 6 more times

This seems to happen both in CI and locally.

Related errors reports:

• tauri-apps/tauri#6047
• mozilla/rust-android-gradle#105
• termux/termux-packages#14576
• termux/termux-packages#8029

Publish fallback prekeys via prekeys API instead of in the contact bundle. This makes rotating prekeys cleaner in the future. When initiating conversations, use whatever prekey is available in the prekey topic (which automatically supports one-time prekeys when they become available in future versions).

Note we need to have validation in place for both v2-style and v3-style keys.

Depends on the implementation plan from 1A

An iOS SDK backed by V3 but still able to run V2 messages.

We need to record for each device what stage of the conversation it's in (prekey/ratchet/etc), and send the right type of message accordingly.

Describe the bug

Client registration fails in the case where getAddress contains the checksum validation information.

Expected behavior

No response

Steps to reproduce the bug

No response

React Native SDK support backed by the Android and iOS SDKs in V3

Describe the bug

The rand crate does not support the default wasm-pack wasm target. We need to verify that this is not affecting libxmtp.

https://docs.rs/getrandom/latest/getrandom/#webassembly-support

Expected behavior

No response

Steps to reproduce the bug

No response

Describe the bug

Need to exclude *.swift files from step that copies from Generated to include: https://github.com/xmtp/libxmtp/blob/main/bindings/xmtp_rust_swift/Makefile#L32

Expected behavior

No response

Steps to reproduce the bug

No response

Describe the bug

$ ./xli.sh --db a2.db3 list-conversations                                       
    Finished dev [unoptimized + debuginfo] target(s) in 0.26s
     Running `/Users/jazz/dev/libxmtp/target/debug/cli-client --db a1.db3 list-conversations`
[2023-08-16T02:09:59Z INFO  cli_client] Starting CLI Client....
[2023-08-16T02:09:59Z INFO  cli_client] List Conversations
[2023-08-16T02:09:59Z INFO  cli_client] Using persistent storage: a1.db3 
[2023-08-16T02:09:59Z WARN  xmtp::conversations] 0
[2023-08-16T02:10:00Z INFO  xmtp::conversations] Messages Downloaded:1
[2023-08-16T02:10:00Z ERROR xmtp::conversations] Error processing msg: Session(Decrypt(InvalidMAC(MacError)))
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: MessageStore(Unknown("Session: decrypt error"))', examples/cli/cli-client.rs:163:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior

Messages sent from A1 need to be replicated to A2

Steps to reproduce the bug

A1:Register
A2:Register
B1:Register
A1: Send B
A2: list-conversations -> InvalidMAC

https://signal.org/blog/sealed-sender/

Need to define the Rust interface for requesting this. Additionally, sign the fallback key (using the identity key or the wallet key?)

Is your feature request related to a problem?

No response

Describe the solution to the problem

We have a struct called SecretConversation that is used in multiple places, we should rename it to Conversation.

This should get you set up in our environment, running tests, and understanding what different crates do. Feel free to ask questions about anything as that is the fastest way to learn

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

As we productionize, it's worth taking some time to go back through and verify any randomness generation changes we had to make for WASM compatibility.

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Encapsulates:

Any infrastructure setup work that needs to happen
Any derisking work that needs to happen
All of the initialization logic that happens on startup (client.create())
Demo output:

New account flow/signatures
New account exists on the network
Private keys exist in local storage

Encapsulates:

The steps required to initiate a conversation, loosely corresponding to conversations.newConversation() and conversation.send() in the JS API
Demo output:

Dedupe by message ID. Do we need to make code changes to support consistent message ID’s? Should we write v2 messages into the v3 database? What would an eventual migration look like?

Prod builds should merge messages from both protocols, dev builds should allow us to flip back and forth between v2 and v3 views.

Describe the bug

I've only seen it when I'm developing locally, but during cargo build of for example bindings_swift it'll get stuck at: (253/255) xmtp_proto.

I wonder if buf is hanging?

Expected behavior

No response

Steps to reproduce the bug

No response

Add client-side checks to reject messages from revoked installations, as well as any API’s for querying revoked installations

Encapsulates:

• The steps required to initiate a conversation, loosely corresponding to conversations.newConversation() and conversation.send() in the JS API

Demo output:

Android SDK backed by V3 with duel support for V2

Right now swift-bridge supports returning Result<_, Enum> from sync/async functions, like so:

// Rust
#[swift_bridge::bridge]
mod ffi {
    enum NetworkError {
        Authentication{
            description: String
        },
        Unknown
    }

    extern "Rust" {
        async fn post_data(data: usize) -> Result<(), NetworkError>;
    }
}

async fn post_data(data: usize) -> Result<(), ffi::NetworkError> {
    Err(ffi::NetworkError::Authentication { description: "error".to_string() })
}

// Swift
do {
    let result = try await post_data(123)
} catch let error as NetworkError {
    switch error {
        case .Authentication(let description):
            print(description.toString())
        case .Unknown:
            print("Unknown")
    }
} catch let error {
    //..
}

I think we can improve error handling by introducing this feature.

Somewhere for us to test the changes, as well as note any breaking interface changes in the future. Ideally we use an existing app and only have to bump the SDK version.

Probably should be in React Native.

Assuming we can handle the storing/fetching in the platform-specific SDK layer and just pass the encryption key down, so no changes in Rust.

It’s beneficial to get changes to vmac in before we have older versions to support. Changes might include switching to ChaPoly, adding support for X3DH, etc.

Encapsulates:

• Any infrastructure setup work that needs to happen
• Any derisking work that needs to happen
• All of the initialization logic that happens on startup (client.create())

Demo output:

• New account flow/signatures
• New account exists on the network
• Private keys exist in local storage

Spend a small amount of time/research to make sure we’re not painting ourselves into a corner

Backend + client changes to prevent unauthorized publishes to the contact/revoked/prekey topics

Work out a plan for this and any overlap with portable inbox work. Most likely path is via building Portable Private Preferences