Safe_client_libs and use in Rust (native)

I’m evaluating SAFE for the startup I work for, and I’m pleased to see that the majority of SAFE Network is written in Rust (the only language I use these days except for “glue” langs).

I’m still trying to find my way around the codebase however… Is there a quick-list of what each repository in the Maidsafe git group is, and is for?

It looks to me like the “safe_client_libs” are written with the goal of FFI only - and to me this is a problem since I would prefer to use the libraries within Rust first and foremost - so the libraries would make much more sense being written wholly as safe idiomatic Rust, and then wrapped for the FFI part.

If I choose to write all my apps in Rust, I then have to faff about with unsafe Rust to use a Rust library when that should be unneeded.

Am I missing something here?

(initially posted here)


FFI is an important layer, but you are free to use the Rust interface of the libraries too, if you’re willing to (I’m glad that you are - hi fellow Rust fan! :slight_smile: ). In fact, it works exactly as you’ve put it: the FFI layer is just a wrapper for the underlying Rust library. You might need to deal with FFI just for IPC though, that is, to interact with the Authenticator.

We also strive to keep the Rust libs well-documented, so you can either find the docs on or generate the documentation yourself with rustdoc.

We don’t have that just yet, but @hunterlester put a nice short description for each lib here (you might want to visit this topic anyway): SAFE network architecture and programming study plan

As for SAFE Client Libs: it provides the high-level interface to the network and consists of:

  • safe_app, the library to write apps (consists almost entirely of FFI functions glueing in with SAFE Core);
  • safe_authenticator, which provides all functions that are required for SAFE Authenticator (the thing you see when you log in through e.g. SAFE Browser); and
  • safe_core, which is still kind of high-level, but this library has no notion of apps or authenticator, as it provides only very basic and fundamental network operations and structures, talking to routing. You’ll need to use this one for most operations in your Rust app. Some usage examples can be found in the repository.

I hope that helps! Please let me know if you have more questions or need clarification.


Excellent response, thank you. I’m likely to have many questions (well, I already do, but I’m still reading through the whitepapers).

Actually, is there someone I can contact for more info re: licensing and use within a commercial app, since this is why I am looking in to SAFE.

Tht study plan by @hunterlester looks extremely good. I’ve already ripped through a lot of the links myself, lots to digest and copious amounts of notes written . I’m a Comp-Sci student myself, but now working full-time since the University isn’t able to offer any papers of use to my final semester :frowning:


Hi Luke,

Welcome to the community.

Here’s an example I’ve started to utilise the Rust layer below FFI:

Looking forward to learning from your knowledge and progress.


You can just ask your question here.

In a general case: if your app is just a derivative work that uses our APIs, you are free to choose any license for it. If you’re integrating directly with SAFE Client Libs or other core libraries, you can choose one of the 2 licenses: GPLv3 or our commercial license.

1 Like

Thanks @hunterlester, this looks good, and gives me a good idea on how to start with it all.

I see you’re using neon for Node.js native compilation. How is that working for you so far? (It’s on my shortlist of possible tech to use).

Am I correct in understanding that there is an alpha test network up and running?

1 Like

Yep! Download the browser and set up an account. You’ll need the invite at that stage.

Nice! So, another question - what is the actual purpose of the browser?

  • To authenticate/login/manage?
  • Tech demo?
  • Will it be a long-term investment?

I wish I’d written a better note here: Is the network topology like a graph, or a binary tree in practice? Some of the whitepapers used the terms interchangeably.

What is the end goal? Replace the internet? I can’t tell if the goal is to provide a new method of communication between computers, or to provide a group of tech such as file storage, emails, websites, or something more general that enables these and more…

Docs say in some places the minimum block size is 1mb, and the minimum chunk count is 3… What happens if a data is under 1mb?

Okay so that was a bunch of questions. They’re breeding like rabbits (sorry).

to authenticate/login/manage? - yep - the authenticator is bundled with the browser
Tech demo? - yep - there are others too, see site
Will it be a long-term investment? - no, a new browser is being developed The current one is based on Beaker which is heading off in other directions.

What is the end goal? - a fully autonomous data network replacing the top 4 layers of the internet and requiring zero human intervention in the management and security of data.
Docs say in some places the minimum block size is 1mb, and the minimum chunk count is 3… What happens if a data is under 1mb? - it’s just encrypted without being ‘chunked’ first.


Good answers, thanks.

Regarding the browser, why is a browser being developed at all? I look at others like Chrome, Firefox, and those are very, very massive undertakings.

I see that Beaker is using Chromium for the engine. Wouldn’t it have made more sense to develop plugins for popular browsers so that users can continue to use what they are used to, rather than LYAB (Load Yet Another Browser)?

So if a new browser is in the works, then Maidsafe developing a browser would be seen as a longterm investment, yes?

1 Like

Pros and cons - see this thread


Last question: What do you define as the top 4 layers?

Top 3 may be more accurate.


In fact, in this moment, the minimum size of a chunk of immutable data is 1 KBytes and the maximum 1MB. As @JPL say Immutable data smaller than 3 KB are stored encrypted without splitting.