What is the state of the FFI layer?

Hello, what’s the state of FFI layer? Is it possible to develop for Safe Network with languages other than Rust?
(title is so strange due to requirements/limitations of this forum)

1 Like

At the moment we have let FFI slip. It’s not a big one for us to update though. There is some work happening but for now, I would say for next few weeks perhaps don’t try other languages just yet. Won’t be long.


Sure thing!


Thanks, I know it’s a bummer.

1 Like

Maybe I could help somehow to push it forward? I’m experienced developer, already taking an Exercism track in Rust. So perhaps instead of waiting for things to happen, with a little guidance, I could be of use? Is it a matter of aligning FFI with current state of API (I could do it function-by-function), or is it a complete redesign of API layer (then, if somebody started the work, I could finish)? I need FFI for my project, and it’s currently on hold because of that.


Let’s see if @bochaco @joshuef @lionel.faber or @yogesh can give some pointers here and thank you very much for the offer. We will have your back and you will have our thanks :muscle:


hey @loziniak , this is our only current FFI impl into nodejs.

It’s yet to be fully updated to latest API, though @bzee has a PR in which I need to sort CI for, but that should get us there.

In terms of other languages. The ideal would be some kind of WASI build of the API i think. Which a lot of languages should offer bindings fo ralready (at least as I understand… haven’t looked at that in a whiiiile)


I don’t see any .dll / .so files in release binaries. Perhaps some refactoring would be needed to separate FFI alone?

I’d happily work on that. So, first I’ll check if it builds and next I’ll need a guidance which functions/structures would be most needed and easiest to work on first (I remember I started with is_mock_build function when doing FFI Red bindings a long time ago). I probably will develop Red bindings alongside.


@loziniak that’s the binding for NodeJS only, we used to have the FFI bindings for other languages (e.g. this is a very old tag and not part of master branch anymore: sn_api/safe-ffi/ffi at v0.15.0 · maidsafe/sn_api · GitHub) which is how we used to produce the .dll / .so files, but as @joshuef suggests we were thinking we should explore other alternatives which should make things easier like potentially WASI.


Maybe it would be nice to have an app which is some sort of RPC (json-rpc/grpc?) wrapper around sn_api to allow simple integration with other apps? There is always the CLI which could be called too.

Obviously, not as slick as native FFI integration, but it may take a while to support lots of languages natively.


Yes, good point to remind devs that CLI has the --json and --output yaml flags which can be used by other apps as the output can be easily parsed.


Imo, parsing the CLI is the best method for enabling a “poor man’s FFI” until the code is two releases stable post launch. The focus can be entirely on CLI development and making it the primary portal and one stop shop for access into Safe. This has been a winning strategy for AWS users.


Good to know all this! I plan to return to PySafe once things are stable (hopefully Riddim too!). No problem making a python interface to the CLI with some macros and cron-jobs built in so it’s useful, then redo our FFI interface once it’s ready.


Hi. I’ve decided to go for FFI anyway, perhaps with benefit for other languages. I’ve got a problem with compilation for 32-bit linux. I created an issue in qp2p repo. If someone could point me in the right direction, I’d be very grateful. Thanks!

I’m slowly getting deeper into Rust. Suggestions welcome :slight_smile:


Just automatically generated first Rust code, based on sn_api code:


Full workflow implemented. Next stop - actual connection to the network.