MaidSafe Dev Update :safe: 3rd November 2015

ah if only we knew that before we started :wink: we do like a challenge lol but yeh while the issues in routing / crust kind of blocked network related testing/progress during the sprint these issues were very much unexpected and are seemingly complex too since guys in those libraries are still working through them right now.

We havent yet chalked the network objective to the next sprint as there are currently a few things making this week quite hectic. To name a few, routing handover with ben leaving at the end of the week and getting andrew into the routing library with Brian. CRUST RFC that andrew has been working on which touches on quite an extent of the crust library for updates. This RFC itself again reduces code complexity a lot while also hopefully getting the library more rust language friendly. While both of these are ongoing this week, guys in the networking libraries are also working on the above mentioned bugs in CRUST and routing. Now if they end up getting resolved in the next few days, you guys will surely be the first to hear about it and we will accordingly try and get the vault library tied in to get the rust-5 deliverable out. If not, then with the handover complete, we’ll be prioritising on getting the networking layer solid to get the previously planned deliverable out before adding more intersecting features as you can expect.

By Drive, if you mean NFS (which isnt just the VFS portion), then yep and also the DNS crates. Launcher RFC lists the actions it currently supports from any app communicating with it.

Can answer these two together. Yes when new features are added in the core modules, the launcher API will also be extended to allow access to those features from apps communicating via the launcher. This will be with new RFC’s for discussion and implementation phases. As for documentation and guides/usage samples itself, you can expect that start making their way outside RFCs too, such as from the launcher repo documentation / dev site and so on…

We had the firefox addon compiled today from all three desktop platforms with the latest master branch of safe_ffi. Maybe worth a try again to see if you’re still having issues Mark. @ustulation / @Krishna_Kumar should be able to help you out if you’re still having issues.

Think this might be soon actually. As mentioned in the update, you can expect a RFC from spandan which should propose the spec to get the launcher to support anonymous data access via the launcher. This should then remove the dependency the browser addons have on the safe_ffi module and bring them to a similar footing to standard desktop apps.

Yep and none :smile: launcher pretty much disconnects the network workings/dependencies from app devs, so essentially when the mock network is replaced with the real network version, only thing that’d change is the launcher binary that which is run on the users machine. App code talking to the launcher will be identical but now with the new version data sent to the launcher by the app instead of getting stored locally in the machine will be sent to the network and retrieved from the network accordingly.


What if I don’t want to run “web” app but rather software app, would it be possible to work on software apps on top of safe? I am not a big fan of javascript.

dns_example is not really a “web” app. It’s a standard desktop app that uses Javascript as it’s programming language similar to many of the apps listed on

However, you’re not confined to any programming language to build apps with. nfs_example here is a rust app which also communicates with the launcher similar to the dns_example but ofc from a different language.

As long as the IPC with launcher is established as detailed in the launcher RFC, you’d be sorted to choose whichever language you prefer for the app let it be python/java/c#/c++/… We’ll be adding more examples ourselves too to the safe_examples repo.


nfs_example is exactly what I am looking for. Thanks!

Edited: I feel like I’m dumb but what is electron? I don’t understand what they are trying to achieve?


@Viv does the CLI create an actual “/user/SAFEDrive/” folder? Because I’m not seeing one being created on OS X 10.11.1

1 Like

Electron is a framework built on nodejs, formerly known as atom. Electron framework facilitates desktop applications to be built using nodejs. Electron makes it really easy to cross compile to all 3 (OSX, windows and linux) platforms too.


Nah all paths referred to in the Launcher IPC for JSON data are paths on the network. VFS apps can then choose to mount those network folders as local folders via libraries like FUSE.


But there’s no way to do this yet, or am I wrong!?

And thanks for responding (and @krishna to me directly) to all my questions. All very helpful :smile:

@smacz, and anyone else - are you interested in working towards understanding what Structured Data can do and creating some kind of testbed to play with it? It looks like we have the option of another go at safe_firefox_addon plus extending safe_ffi (tricky but would mean we have a compiler-free/in browser testbed, and something easy to build on for web apps like SAFEpress) or jumping on the JSON API as it emerges (with the option of pestering @ustulation as a bonus :smile:).

It would be good to work with others interested in these areas so let me know if you want to be involved, or just know what I am up to.


You’re right(partially :smile:) as in there isn’t an app yet that does this and expose a VFS, however such an app should be possible to code with whats currently exposed from the launcher JSON API. It’s now just a race if the client guys end up creating such an app with the launcher API to expose a VFS drive or someone from the community beats them to it :wink:

I’d definitely suggest pursuing this route, as it’d help everyone more in the long-term. With the FFI dependency soon to be removed from browser addons, extending the FFI layer might not be of much use to scale. Also the benefit of pestering @ustulation / @Krishna_Kumar is a definite bonus :smiley: On a serious note though, Spandan’s RFC to get the anonymous access to data via launcher should be getting published to the RFC repo very soon which should trigger a bunch of questions/scope discussions. So I’ll definitely suggest participating in that to make sure you guys are getting your required features catered for with that RFC. If needed we can also setup a mumble chat with the client guys while that RFC is getting discussed to ensure required features are getting catered for.


Leaving like leaving or leaving like “I’m off to the Bahamas”?

1 Like

Like “I’m off to Berlin”. He’s going to try to start a SAFE community there.


Great update, thanks!

Which Ben is it that’s is off to Berlin and are they NO LONGER doing dev work for MAID?

1 Like

@BenMS and @benjaminbollen. The latter is his “private” handle, the former his MaidSafe one.

1 Like

Thanks. He is no longer a dev at maid?

1 Like

Im in the last week of me working for MaidSafe, yes. After that you’ll see me on my personal handle again! thanks @Seneca

1 Like

OK thanks for the update and good luck in all!


Crust went from version 0.4.2 to 0.5.0 according to this link.


So, just Routing to be fixed then?


Nooooo! Don’t go!!! Will you be developing apps for the network?? You’re such an asset to the project, I appreciate your contributions to the libraries. But you’ll be starting your own safe pod and teaching others to commit to core libraries?


i hope so but i don’ see the progress of fixed routting on jira