MaidSafe Dev Update :safe: 5th October 2015

Hello everyone,

So, we are on the cusp of beginning another sprint, as @Krishna_Kumar outlined in the previous dev update, last week was the second week of the RUST-5 planning and this has overrun a little into the middle of this week. We expect this sprint to kick off in the second half of this week and we anticipate that it will take around 3-4 weeks to complete. The deliverables and duration have yet to be fully finalised, so may still be tweaked and altered slightly, but I will set out in this update where we hope to be at the end of this RUST-5 sprint. The current deliverables and timeframes will be finalised once all the tasks have been transferred from the RFCs into JIRA tasks and time estimates associated with the same tasks added.

You can find all the RFCs here

Active (going ahead in this sprint)
UDP hole punching
Launcher as a service
Connection Management

Agreed (will be happening in future sprints)
MPID Messaging

Launcher not as a service
Address relocation

The team (MaidSafers and Community Safers) spent a lot of last week thinking, creating, debating and poking these RFCs, so they would be as detailed and complete as possible and ready to be implemented via the subsequently created JIRA tasks. As we learned from the last sprint, we need to make the task descriptions much more detailed in order that they are easier to understand. This will facilitate SAFE bounty hunters picking up and completing tasks, continuing the drive to increase community involvement in the development process. As ever, this process will continue to be fine-tuned and evolve and everyone’s feedback is welcome. For example, our RFC process has developed as we progressed through planning; improving commenting and implementation blueprints, so that with each iteration of the process we hope to make it easier to contribute and become involved in the people’s network.

The main theme of this sprint is delivering the ability for everyone to easily connect to a stable network remotely via their home desktop computer (tier-one OS only just now). So a lot of effort in RUST-5 will be working toward accomplishing this, whether these are tasks in crust regarding UDP-hole punching; routing tasks related to Connection Management or more general tasks that target overall network stability created from Github issues / bugs that have been found and logged by the community. After this sprint we aim to have a stable SAFE network that is constantly up and that is easily accessible by everyone via desktop installers. So this should be a really exciting one!

As if that is not enough, we also want to focus on making life easier for community SAFE app builders. This sprint deliverable is equally as important as the last and complements the main RUST-5 theme; to encourage and improve community engagement with the network in a stable way, with no dependency on any of the core libraries. This will make it possible for any app from any language to communicate with the App Launcher. The Client guys have been busy outlining this in the Launcher-as-a-service RFC. This is quite a paradigm shift so I had to turn to @ustulation to explain this to me (luckily he is patient) - here is how he explained it to me:

A feature of the Launcher is that an app has to re-negotiate security parameters every time a fresh connection is made. Therefore, apps have absolutely no incentive to cache those parameters for future use, easing revocation of permissions considerably. For example, once a user decides not to give an app permission to mutate the network on his / her behalf then the next time an app tries to negotiate security parameters, the handshaking would fail.

Also account creation and login happen only from Launcher, i.e. it is the SPOC (Single Point of Contact) for the SAFE Network. This means that no app gets to know user credentials and hence will never have any knowledge of a user’s MAID, MPID and other keys and cannot tamper with a user’s login session packet which would otherwise be disastrous as the session packet contains all information needed to know everything about a user on the SAFE network - signing keys, encryption/decryption keys, data, etc.

Another plus is that apps won’t need to interface with any of the MaidSafe rust libraries, they can be built without any knowledge of how to do operations (e.g. create a versioned private directory) on the SAFE network. They will just have to comply with a very friendly versioned Launcher document which exposes JSON structures for performing an action (i.e. create a directory) and parameters that are needed to perform the action (e.g. name of the directory, whether publicly shared or private, etc.) The onus will be on Launcher to do the translation, utilising the MaidSafe crates to complete all network operations, security operations (encryption / decryption, signing and stamping ownership, etc) and interpret data (versioned / unversioned, structured / unstructured, etc). So, this eases the life of app developers a lot! They will not have to overcome a steep learning curve to successfully code and contribute to SAFE.

It was decided to accept the Messaging RFC and this has been moved to Agreed, however a combination of limited resources and the fact that it is adding features and not fully in line with the overall theme of the RUST-5 objectives mean that this will be part of a future sprint, but not RUST-5. A lot of effort has gone into this RFC and this will not be lost, just slightly delayed. In other non-sprint news the renaming of the safe_client module to safe_? as mentioned here is still planned and will probably happen later this week once a new, more accurate name can be decided upon, so keep an eye out for that.

So, a really exciting few weeks ahead and one that will focus on inclusion of the whole community. Keep your eyes on JIRA to monitor our progress and claim one of the tasks if you feel sufficiently able.

Transcript of weekly catch-up


There is a lot here to be excited about. I want to emphasis these three points as they are all very major advances IMO:

  • delivering a live network anyone can participate in during the next sprint
  • providing a way for anyone to build apps very easily, and
  • improved security by keeping user credentials and keys confined to one trusted application (the “launcher as a service”).

As referred to by Ross here…

Great stuff guys. And many other great points like the improvements to the bounty system. Thank you. :smile:


Great work! Can’t wait to see us all connected on SAFE :sunglasses:
Wanna know more about the launcher?

This is how it works.
Here’s an old screenshot that shows how to log on to the network.

This is another mock-up which might give an idea how the different Apps will show up.

Here’s a great in-depth topic about the App Launcher.


@polpolrene true, but above MaidSafe have now deferred the Launcher in favour of “Launcher as a service” which I think means you’ll be able to launch a native shortcut for your app, which will connect to the launcher service directly (ie launch outside the launcher). I understand the launcher will either have to be running, or that there may be a way to create a shortcut which will start it if it is not already running.


great stuff! how is the new website coming along?
i’ve seen some exciting pictures…

very much looking forward to this. i’ve always felt that the current
website is a bit of an understatement for the project :wink:


What did this mean?

I didn’t really understand any of this. If apps launch outside the launcher, are they still secure?

Will ‘constantly’ here mean ‘forever’?

Like, this network won’t be taken down and replaced by a newer version, but instead it will stay up and just be updated over time?

Yes - it makes them more secure because they never have your credentials and the keys they have to give them access to the network on your behalf are temporary, so if they store them they won’t work later.

“Launcher as a service” means that rather than being an application that you run, and then use to launch your SAFE apps, launcher will run in the background. Any app wanting to access SAFE on your behalf will connect to it and you will be able decide whether or not the launcher should allow it to access the network. I imagine you might be able to say “just this once” or “always, until I say otherwise” etc. The difference is that the launcher becomes a jumping off point for the network, both for authorisation, and for the API. So an App will no longer need to be built using the SAFE API and libraries, it will be able to be built independently, and just talk to the launcher and use a simpler much easier to code API to do things on the network (such as store/retrieve data, send messages etc.)

Using “Launcher NOT as a service”, is still feasible (ie the old approach we’ve seen mock-ups of in the past - see @polpolrene’s post above) but development of that has been deferred.


Thanks a bunch, this really helped.

So basically, it will feel very much like today’s internet experience, where you just open an app like Skype or Photoshop on your computer, right? And all the launcher stuff is still happening but you don’t think about it or see it anywhere

If I’m understanding this right, then that sounds infinitely better, and easier for everyone (builders, the masses of end users) involved. Really can boost quick mass adoption. Right on!! Awesome news


No it means it would last unless we kill it. We will have to kill it though I imagine as we push safecoin in to play. There is also a very high chance something will change in data API before that, so don’t think data is safe forever just yet :wink: it will be encrypted etc. but this is all test at the moment. The update that launches the data forever will be a huge one :smiley: we won’t forget to mention that aspect I am sure.


That I’m sure

While reading the Update, it occurred to me that the oldest trick in the book, “pretending to be the authorised one” might be possible still. That is for a program/APP to present the login screen to the user pretending that its the actual login screen.

Is there any protection from this happening? Is it even possible to protect against? That is within reason.

Do you mean that this is only planned to work on Linux? (For the time being)


The website is coming along fine, although taking a bit longer than planned. Rather than launching both the new dev and end-user sites at the same time it looks like we will probably launch the end user site first, while we work on and finalise the material for the dev site.


The plan is for Linux, OS X and Windows. Minimum versions, etc are still to be finalised.


sorry to ruin your excitement here Mark :frowning:, but this isn’t gonna be the case at least with this sprint. The exact point you mention is currently documented as the first point in limitation and future scope in the rfc . This feature is something we definitely intend to provide “soon” for a seamless UX when dealing with apps representing a user on the network.

For now its easier to think of launcher “as a service” being something that handles all communication for an app with the network via itself. This helps users being able to pull access to the app as the launcher merely stops accepting any further requests from said app. Another really neat advantage of launcher being the service handling all communication is apps being disconnected to the core rust modules and not having to rely on a ffi interface to the core libs. This means once apps comply with the IPC mechanism exposed by the launcher as detailed here, they’re set to use the SAFE network without any further dependencies.


@Viv thanks for the clarification - I misunderstood [edit - twice, but got it now :-)]. It did get you to sprinkly more fairy dust though so thanks :-). I am still very excited about this sprint. The only downer is lack of messaging this sprint - I am very looking forward to being able to IRC chat over a live public network :smile:

(I’d love to hear your team’s ideas on how apps in a browser will work - specifically dynamic web apps as you know - so consider yourself reminded :smile: I think there will still be a need for a parameterised URL for both HTML CSSS/template and the data references, so don’t think the launcher service changes the core aim of my RFC on the topic).


Yeh should be a neat sprint indeed :smile: with a strong foundation from this sprint, bringing messaging in both from the network side and client side should be like any other feature and with an agreed RFC in place the whole process should be a quick one to get to implementation.

cheers for the reminder :wink: it’s something @Krishna_Kumar has been looking into as well. That RFC will be getting merged to the proposed section soon, so discussions for that should hopefully kick off in the repo itself. It’s a section that the launcher does not interfere with for now, but hopefully there should be some ease of use aspects to come in for the same too.


[quote=“dirvine, post:10, topic:5449”]We will have to kill it though I imagine as we push safecoin in to play.

Safecoin will NOT be in play in any form? Will proof of resource be used at all to start testing farming equipment?

Edit: Second quick question, before the network goes live forever (“launch” day) we’ll all get a 30 day heads-up of some sort? And will the test network on “launch” day be reset, or will the nodes just be updated?

Test safecon will need to be in use to test farming.

At some point test-safecoin will be deemed to be real safecoin. We could stop and wait 30 days to let everyone know but I am not sure what that would buy us really.


No, keep us all in suspense and farming like crazy without any pre-announcement :wink: [Edit: Once we have Odroid support I should say :-)]