MaidSafe Dev Update - February 16, 2017

Some clarity from dev forum

Which is fine but as you suggest the question of how a non-js app will talk to the network is now not obvious. Rationale for using node.js perhaps just naturally follows from its being good for network environments but I’m guessing at the missing link atm…

Can non-js applications interact with node-js in a trivial way??..
This is the closest I’ve come to seeing a route through the uncertainty… GitHub - request/request: 🏊🏾 Simplified HTTP request client. but I don’t know enough if that is a complete answer.


Would be good if those are simple libraries, made available to any external call… but is that not the same as having a REST API?

Nice update.

Quick question: the video presentation says the entire system is programmed in Rust and Javascript. People who have never heard of SAFE will look at the latter and immediately highly question the security of the system, since JS has a reputation for not being secure. What full response from an expert would completely quell worries anyone has regarding that? (I only ask because I showed a technical-someone SAFE and he noticed the javascript aspect and wondered why.)

1 Like

warning: some half-knowledge ahead :wink: <<< the safe_client_libs do have

pub unsafe extern “C” fn

functions in it → those are accessible through a rust-built-in C API

so C code can use this API … Rust Once, Run Everywhere | Rust Blog

and e.g. python can do it too via its C-API modules ( cffi / cdll )
(if you are a better python programmer than i am and can define the inputs in the correct way that would make one more line for a real python-program authentication there:
what can be seen on that screenshot is a modified authentication function with pre-defined app/vendor name and version … but really called from python)

…and since those C-APIs are used to boost your programs … using that api is probably faster than using an api written in pure python Oo …

pretty much - yes - but getting those running was more than 2 lines of code for me (but i’m not a good programmer and absolutely not experienced …)


Me too… but I got them working because rest is a widely understood concept and I can patch together examples and polish those together. Now I’m looking at a blob of safe_client_libs and back at square one for what that might want as input. I guess it’s a hurdle that only needs jumping once; so, if anyone does that in rust, it would be useful to see that.

yeah - someone needs to take the library and put together a wrapper around it … so that the necessary variables for the functions get transformed into the correct C-Types and pushed to the library → &the output back into python variables

… that will be one module … you then can use like

 `   import safeConnector`

     myConnection = safeConnector.connection()
     if myconnection.isAuthenticated():

…but first someone needs to writhe that module ^^


This is full of nice stuff to chew:-) the examples are not much commented but some are quite simple and showcase well what happens.

Good news is I can definately drop developing rsafe and jump directly to make use of these official libs:-)

While rust certainly lacks stable G ui , it has quite some nice command line ready crates , that can be amazingly useful within Safe when you think about it…

1 Like

Yes, I’d seen that but looking for a simple option to GET url from application not browser and couldn’t immediately see it there.

Unless I’m terribly mistaking now, it’s been made clear in several previous dev updates etc that the new FFI bindings in safe client libs can be ported to any language. They are just doing a node.js versjon right now.

So correct me if I’m wrong, but an API like the node.js one can be made for pretty much any language?


What is clear to some, not clear to all. I guess I’m just one keen for statements of the bleeding obvious, rather than tech level speak. So, I’m poweruser that just breached the hurdle that was REST API for the first time… and I suspect perhaps there are a large number of others in a similar position - can do http; css; javascript etc but hesitate when faced off against an API or anything that sounds stranger than that. Keen then to see those hurdles flattened…


Thanks Maidsafe devs for another great update.

I’m sorry I didn’t participate in Test 12b, I found it really difficult this time around to get this running on Ubuntu :sweat_smile:

I’m a little ashamed to even say that i can’t even compile the browser now.

But I’m superhappy that there are some very capable community members who can keep this network moving.

So the rockstars are heading for Asia, please record this rock concert :stuck_out_tongue:

I’m gonna take a look at @lightyear rock concert, like right now :stuck_out_tongue:


Sounds like a great idea.

Let’s have a list of volunteers and/or suggestions about who would be good and I’ll see what can be done. I’ve been a bit less immersed lately, partly due to other things happening, and partly because it’s getting over my head on the nitty-gritty level.

So you guys who’ve been participating and have stuff to offer, let me know. We can do a medley.

EDIT: Send me PMs on this stuff, it’ll be easier.


I think I found quite some insight here :

Specially the part starting with “Added to that, the refactor of SAFE Authenticator…”. This is the train that I missed !

Did I say how even more exciting the whole thing becomes now ?


Yes, I don’t want to nit-pick, given the assurance received above but just to point out the difference levels of comms that find traction…

but then such qualifier as “We will be integrating it with safe_client_libs to expose the SAFE API to Node.js developers.” in the paragraph that followed shortly after:

Suggested to me less than generic interface… where REST is generic… anything can call a request and get a response.

Anyhow, understanding now that Node.js developers is apparently everyone, even those who struggle to install npm correctly. :smiley:

It’s possibly not clear how this picture is. There is a structure like this

3-> [node][python][java]... Almost any language
2-> FFI Layer (essentially a "c" interface)
1-> Rust (safe_client libs)


1-> rust apps can use the rust layer directly.
2-> FFI (foreign function interface) really only exposes a “c” interface which allows “native” libraries for a lot of languages to “import” into other programming languages
3-> Libraries already prepared and packaged for other languages. We only have node at this time, but nothing stopping us having java python lua etc. (except time)

Our goal here is to do similar with this as other projects do and as we are trying to do with our “demo” apps or example code snippets (we struggle with the demo app name a lot) and have community maintained native bindings. I suspect we may end up as maidsafe having node/python/java libraries and have these built and deployed via our CI scripts. It’s a debate in house though (rightly) as to how much we take devs off launch to do this right now.

Hope this helps a bit anyway.


But what about the FFI licensing? I thought Safe’s FFI could only be used by open-source apps or by apps who pay royalties to the Maidsafe org. Otherwise, apps should use the Launcher.

Can I use the FFI binding in a closed-source, without paying any royalties, app?

1 Like

Yes, these will be lgpl, so Ok there as long as you do not alter the code in them.


21 posts were merged into an existing topic: Maidsafe’s Asia Trip (February 2017)

Really glad to see the team gets the appreciation it deserves from so many new people!


This might sound a bit crazy, but could I use the SAFE Client FFI bindings in a closed-source rust library with it’s own FFI bindings which are used in a closed-source SAFE app written in node?
Would this avoid a licensing issue compared to importing the SAFE Client libraries directly into a closed-source rust library with it’s own FFI bindings which are used in a closed-source SAFE app written in node?

1 Like

The FFI bindings are not bsd/mit licensed, so you can do as you wish there chap :slight_smile: Good luck with everything, I hope you enjoy and give feedback to make these libraries as useful as possible for everyone.