Build an interface that integrates with all three of our FFIs for better unified testing

[codabrink]

Most of our tests test cover internal components, while ignoring the nuances introduced by our bindings on the FFI. So we may consider a feature well tested on the inside of the lib, while our end-users experience bugs introduced by our FFI. It would be nice to build a headless client that interface with all three of our foreign function interfaces that we can test against to ensure we get consistent behavior closer to the end user.

[insipx]

I'm in favor of anything that reduces code-duplication across our SDKs/ffi layers

To add to this:

I think its also worth mentioning that we can probably design a crate that combines elements of each ffi crate into one. Each FFI crate, as it is, is more or less the same. As time goes on, however, it could lead to differences in behavior in each SDK. It might be better to introduce a unified public interface to libxmtp through one crate that each ffi crate uses. Or, just one crate that generates bindings for uniffi, wasm, and node.

Consider the Client struct in each FFI:

Napi

#[napi]
pub struct Client {
  inner_client: Arc<RustXmtpClient>,
  signature_requests: Arc<Mutex<HashMap<SignatureRequestType, SignatureRequest>>>,
  pub account_address: String,
}

wasm-bindgen

#[wasm_bindgen]
pub struct Client {
  account_address: String,
  inner_client: Arc<RustXmtpClient>,
  signature_requests: Arc<Mutex<HashMap<SignatureRequestType, SignatureRequest>>>,
}

xmtpv3

#[derive(uniffi::Object)]
pub struct FfiXmtpClient {
    inner_client: Arc<RustXmtpClient>,
    #[allow(dead_code)]
    account_address: String,
}

Functionally the same, other than some minor signature-request management that's specific to wasm and node. It seems we can combine all of this with a compile-time toggle,

i.e

#[cfg_attr(feature = "xmtpv3", derive(uniffi::Object))]
#[cfg_attr(feature = "napi", napi)]
#[cfg_attr(feature = "wasm", wasm_bindgen)]
pub struct OneClientToRuleThemAll {
 /* .. */
}

To make this even easier we can design a super macro to automatically apply cfg_attr in one derive, i.e #[derive(XmtpFfi)]

This would significantly reduce surface area between all FFI crates, while also make testing unified. Platform-specific code can still be separated into files according to each feature, and that code should be fairly minor. Releases will be easier and on a more consistent timeline for all sdks, since code does not need to be updated in 3 different places.

Platform specific code that comes to mind:

• each platform has their own logging implementation bindings
• web is single-threaded
  • mostly taken care of already in xmtp_mls itself
• uniffi UDL generation, which already occurs with its own sub-command