MaidSafe Dev Update :safe: 3rd November 2015

cheers, may Jesus help you guys to solve the bugs asap. :grin:


thanks for the reply, The launcher and the example apps will keep me more than busy :grin:

He’s at the Troon office already:


Sorry but that’s just disappointing… Maybe because today’s my birthday idk :smiley:


Thanks @anon86652309 and team for this extra deep and thorough update. I like having the extra detail on the libraries from those handling them.

I thought this was an extra ambitious sprint and am not surprised it was too much for the time allocated. If anything I’m surprised you came so close - literally a handful of bugs short off a full NAT handling public test network! That’s an amazing feat. What’s apparent is that decoupling the libraries and particularly the JSON API makes it much easier for the different teams to work independently which I guess is a boost to productivity.

I’m hungry for more as well! So some questions… :smile: Thanks for all the Apps to play with - I haven’t looked at them yet, so if any can answer my questions please say so and forgive me. Here goes:

  • regarding building apps, the Lancher JSON API remains limited to authentication and Drive I believe, which means I’m still stuck personally because I need to get to grips with other areas (Structured Data, messaging/notifications for a start). I haven’t grasped the power of Structured Data yet and need to play with it in the absence of more info, and due to build difficulties with safe_firefox_addon / safe_ffi have not managed to find a way to create a test App to play with it yet. I posted some details of these problems (see link) but am not sure the best way to move forward. It sounds like waiting for Launcher to expose these APIs is not happening soon, so can someone help us (me and @smacz if he’s still interested) build safe_firefox_addon / safe_ffi? The first question that might help help should be easy I think: what build environment you used, but obviously that might not be enough.

  • I’m assuming that the differences between mock and real routing are purely behind the scenes, and for an App the difference is going to be negligible. Is that accurate, and are there any things App Devs should be aware of that might affect us?

There, and I didn’t even mention ARM and temp_utp … oops! :wink:


Love these updates guys. It’s now so easy to tell what’s happening and what to expect.

The API is my main concern, and I will be pouring over the code to figure out what’s going on. When new APIs are added (and I have no doubt that more will be added if only out of pure necessity) will this RFC be updated, or will there be further documentation that will be maintained that I can refer to?


As for delivering user value, I viewed this sprint’s goal as allowing users to put up simple web pages on a real network. Is that looking feasible for the next sprint? I know you haven’t committed to anything yet or set a goal, I’m asking more because there’s a lot of moving parts and I can’t totally interpret how they fit together from the dev update. (Thanks! It feels weird being a clueless user for once.)

1 Like

Welcome to the forum.

This should come around when the bugs are out. So at this sprint, although nobody knows if it’s the coming days or maybe after a week or more.


Ok 26 likes in the first 3 hours is GARANTEE a new record!! :smiley:


9 new users today on the forum, that’s another record in months. But sssstttt don’t wake the mods, it’s off-topic from the OP :wink:


Oops, I figured the team jumped from one sprint to the next. Not sure what to expect then. It seems like the ability to create public web pages (on a non-mock-network) is held up by underestimated issues in the routing library. I just hope it comes together this year, because there’s really no user value until we can connect.

1 Like

Is it true he turned the doughnuts into yum-yums?


Happy Birthday :gift: I’m broke as a joke so I can only give you a digital gift :stuck_out_tongue:


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.