Dev Update & 2nd Test Network Release :safe: 8th March 2016

N.B. The SAFE Demo Application has been updated to v0.2.1 since originally posting - link is updated

##SAFE Network Testing - Part 2

As part of the rolling release of the community test network, we are today releasing updated versions of the SAFE Launcher and the SAFE Demonstration Application binaries and resetting the testnet. This updated release includes improvements from issues we discovered ourselves from analysing logs and feedback from the community; for full details of changes check out the Client section of this update. Thank you for taking part in the first testing phase, your involvement helps a lot and with each iteration we are closer to final release. So please continue to test, create and provide feedback.

You can download these new binaries here:

SAFE Launcher v 0.4.0 x64
SAFE Demo Application v 0.2.1 x64

The original MaidSafe test network, consisting of 50 vault nodes to which the first SAFE Launcher and the SAFE Demonstration Application connected, will be brought down today and a new test network started. This testnet is again comprised of 50 vault nodes running on Digital Ocean droplets.

This means that:

  • Everything stored on the first network has been wiped.
  • Launcher v0.3.0 will no longer connect to the testnet - you will need to download the new SAFE Launcher (link above) to continue to participate in this testing phase.

The documentation is still here, we have added an improved walkthrough on setting up the proxy which we hope makes this process much clearer.

So time to recreate your anonymous IDs and get testing what we believe is the world’s first autonomous network. Looking forward to see what is created and shared on the SAFE Network this time around :slight_smile:

##Crust - uTP / API : Vinicius / Andrew / David

uTP support had previously been disabled to leave the Routing layer free of surprises while those guys were busy. We have now stabilised uTP support within Crust and it is now re-enabled.

Good progress has been made on the TCP hole punching front. TCP port mapping is now complete and a proof of concept example has been created for TCP hole punching. We are currently working on integrating this into Crust to expose this feature to upper layers. The library is now a lot more stable and we no longer have any ignored tests.

##Routing - Vault Integration : Andreas / Brian / David

We have implemented a framework for simulating the network, added lots of automated tests to the framework and we have already fixed a few bugs uncovered by it.
We have also designed and started the implementation of a system to work around failing direct connections without disturbing the Routing logic. This is part of our preparations for enabling users to run their own Routing nodes (Vaults) and should increase the amount of failing direct connections that the network will be able to tolerate: It is a workaround for cases where two nodes need to connect to each other and both are behind particularly uncooperative NAT devices.

##Vaults : Adam / Fraser / Qi

Further work on testing yielded a few more issues which were generally easy to resolve. More effort has gone into ensuring the personas all retain correct account information under churn (i.e. where peer Vaults join or leave the network). This work is ongoing, both in terms of implementing churn-handling code and testing the code itself. A debate remains about the level of inter-vault synchronisation that will be required, but we are almost in a position to settle such points by using the droplet-deployer tool (a Python script which allows easy set-up and teardown of a network of Vaults on remote VMs called droplets) which is scheduled to get an upgrade to allow us to easily induce churn on the VM testnet.

Further work remains in Vaults, but other than unit tests, much of this is optimisation or adding non-critical features. Given the recent testnet results, Vaults performed at least as well as anticipated - perhaps better. The expectation is that this will remain the case in future iterations as they are used in more realistic networks e.g. where they’re running behind home routers, or on lower-spec machines, or in a network where Vaults are joining and leaving continually.

##Client - Launcher : Krishna / Spandan / Shankar

As you have already read, the client guys have been super busy working on the updated releases of the SAFE Launcher and the SAFE Demo Application, specifically bug fixing and implementing enhancements that have been reported back to the team from you the community. Full changelogs can be found here:

SAFE Launcher v 0.4.0 changelog
SAFE Demo Application v 0.2.0 changelog

An example of an area of feedback the guys have been working on is implementing the network connection observer within safe_core which does pretty much what the name says: monitors the network connection between the Client and the SAFE Network. A new version of safe_core was published in version 0.9.0 and safe_ffi has been updated to work with this new version. Check out the changelogs for a complete list of updates.

Documenting the SAFE Launcher API is also ongoing, with good progress being made. So excellent work coming from the team here, the turnaround from receiving community testing feedback to implementing and rolling out new versions is, in my opinion, pretty impressive and a taste of things to come.

##UI Design : Scott

Work has been ongoing along with @Shankar and @Krishna_Kumar on improving the UX for the SAFE Launcher and the SAFE Demo Application. There have also been numerous small tweaks to the interface on both of these and there will be a lot more time spent on the design of these in the coming weeks and months. @Scott will specifically be looking at Launcher and how to make this experience more cohesive. Time has also been spent this week on researching and improving some of the documentation for the proxy setup to make this easier to follow. The first roadmap iteration was also reviewed, so there has been progress made here as well.

##Customer Support : Ross

As I posted as a reply to last week’s Dev Update, due to the number of limitations with JIRA Service Desk, mainly the inability to allow everyone visibility of all issues easily, we decided to stop using JIRA Service Desk. We created a project within our JIRA Core system called Customer Support and migrated all the issues from Service Desk into this new project. We have opened this project up to anyone, allowing everyone the ability to view all existing issues and create new issues anonymously. Click on the link to directly access the new JIRA Customer Support project. For bugs this is our preferred method to collect and manage issues.

Follow the link and click Create to raise an issue.

The new releases will address a lot of the Client side feedback we have already received in the forums and via JIRA and we shall go through all of the JIRA issues post release and update them to reflect this.

In the first phase of testing we gathered a lot of information and have used / are using it to keep pushing toward our ultimate end goal. You guys are now part of the development process and I think everyone is very happy that the line between MaidSafe and the SAFE community is blurring. We all thank you for playing your part and look forward to keeping the momentum going as progress is clear for all to see. Enjoy the latest test release and as always all feedback is extremely welcome!

Thanks again for the ongoing support, here is a link to the transcript.


Time for @happybeing to self-moderate and delete his posts with a bunch of invalid .safenet links :grin:

It’s puzzling that security related advice for DIY proxy setup (discussed on the forum in detail) hasn’t registered with the devs. The PAC file is still the primary approach.


Is there a recommended place to suggest improvements to things such as the launcher API and FFI or is here in the forum enough? I am afraid to open a half dozen JIRA issues that are not bugs unless y’all think it is ok? (obviously I would avoid political discussions and instead just open ones for marked improvements)

1 Like

Very nice update…it proof that SAFE is a stable network already and the client isn’t even out yet. Keep up the good work…i strongly support you guys (and ladies of course).


If you are ok with using Github, rfcs-repo is the best place to suggest these. The linked instruction mentions the details. This would allow devs to comment back and others to also contribute to a new feature discussion which can then get moved along the implementation process easier.


Has the upload limit been increased to 5mb as stated in another thread today?

I sure am. Thanks. I will try to consolidate like features into only a couple of RFC with complete technical details. Heck, I may implement it and send y’all a PR :slight_smile:


Yep. All changes should be documented with the github release itself


Looks like you didn’t read it. Yes it has been added.

Woo! Update! was looking forward to the messaging but I guess that won’t happen for another two weeks or so.


1 Like

It’s fast! Works like magic here on Win10 / 64bit.


Brilliant. Launcher seems faster, it’s clearer that the nets up and setting up an account makes more sense.


yes - faster indeed …

ps: ubuntu 14.04


Quick Update:

Windows 7 binaries have also been added to the Github releases.


Anyone know where to find the proxy file?

1 Like


Here you are pal -


thanks both :slight_smile:


not sure if my proxy is being whack or if bugging when trying to access public files uploaded.

Anyone got a sample site up yet? Or can you see: http://some.problems.safenet/ ?

1 Like