Mobile embedding

[tomaka]

Several people have been asking whether smoldot could be embedded in a mobile app.

I'm opening this issue as a way to take notes.

For iOS, the smoldot client code (in Rust) needs to be compiled as a static library that can then be loaded and used from Swift. For Android, it needs to be compiled as a shared object (.so) and expose JNI bindings. See https://docs.rs/jni/.

I'm not an expert in mobile development myself, so hopefully I'm getting this right.

From a practical point of view, we could imagine adding new sub-directories in /bin for Android and iOS. In order to not duplicate too much code, we would need to move a lot of the light client's code (/bin/wasm-node/rust) to /src. See #595

[athei]

One thing mentioned by @pepyakin is that it might be beneficial to reduce the the API surface of this potential libsmoldot because that reduces the amount of hassle with creating platform bindings. Thoughts about this can be found here: https://github.com/pepyakin/turbosolver-sdk

One idea is to make the C API roughly equivalent to the RPC API of a node (single entry point that acts as if a RPC message has been send). Then existing client libraries like subxt and polkadot.js can be repurposed. They just need a pluggable transport layer that allows to connect via embedded libsmoldot instead of http or websocket. Additional RPC messages can be added that are exclusive to libsmoldot like commands that allow connecting to multiple chains at the same time and adding/removing chains at runtime. Of course someone would need to write clients for java and swift to make it viable for mobile development.

[tomaka]

After https://github.com/paritytech/smoldot/pull/1688, the light client code is now parametrized over a "platform". In other words, the code no longer calls ffi::Instant::now(), but Platform::now() where Platform is a trait.

The next step is to create a new library named for example smoldot-light-base, where Client, Platform, and all related types are moved, while everything currently in the ffi module stays in the wasm-specific package.

This will make it possible in the future to create other packages on top of smoldot-light-base.

Apart from making it possible to create an Android/iOS package, one additional idea would be to create a desktop light client in order to more easily debug and benchmark the light client.

[tomaka]

After https://github.com/paritytech/smoldot/pull/1698, there is now a smoldot-light-base package in the bin directory. It contains the light client node code in a platform-agnostic way. By using it as a dependency, it should be relatively easy to create an Android or iOS version of the light node. The content of bin/wasm-node/rust can be used for inspiration.

I'm not an expert in Android/iOS so I'm not going to do this myself, but I can help and address issues on the smoldot side.

[extraymond]

Hi! Just started following this project, and looking forward to see multi-platform support. Have you looked at uniffi created by mozilla? It's a cross language binding tools that can let rust code be deployed to not only ios(swift) but android(kotlin), and other languages in a very developer friendly way.

https://github.com/mozilla/uniffi-rs

[tomaka]

Some links: https://fnordig.de/2022/01/31/rust-libraries-on-ios/ https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html

[tomaka]

Have you looked at uniffi created by mozilla? It's a cross language binding tools that can let rust code be deployed to not only ios(swift) but android(kotlin), and other languages in a very developer friendly way.

I haven't really looked at it and I don't know anything about how this works, but from my experience in general I know that this kind of abstraction is very leaky. Instead of being an Android or iOS expert, you would have to be an Android+UniFFI or iOS+UniFFI expert. Even if UniFFI made things easier, the mere fact of using it has a huge negative cost, and its benefits need to be huge in order for it to be worth it.

[extraymond]

Thanks for your response and the reasonable concern. I'll try to find some time to explore how can uniffi be used for smoldot. Is this the potential client interface for such embedding use cases? https://github.com/paritytech/smoldot/blob/main/bin/light-base/src/lib.rs

[tomaka]

Yes

[tomaka]

cc https://github.com/paritytech/smoldot/pull/2675