MaidSafe Dev Update :safe: 5th April 2016

As everyone who regularly follows these updates will be aware, getting the MVP out is taking a bit longer than we all expected; just now this is mainly due to bugs that we are seeing with uTP, issues that are not reproduced using TCP. So as the Crust team continues to work on these issues the decision has been taken to slightly change direction with the MVP and initially release a TCP only MVP. This may require a little more manual set-up from the user side, but it was felt better to keep the rolling release schedule erm… rolling - rather than lose momentum,as the guys are currently testing this and seeing very positive results. So to be as transparent as we always try to be: the first MVP is going to be initially TCP only, with uTP support to follow.

As you may be aware uTP is a layer on UDP that allows reliable transfer of data, while also allowing better NAT traversal than TCP. Utorrent uses this, but many in that community still use TCP as it’s 20% quicker. uTP following TCP is therefore sensible and it allows all the other libraries and the resources we were pouring into Crust to be pushed into the Client APIs and Beta features (messaging / safecoin / advanced data handling, etc). This is now where we will once more see much faster delivery of components to the community, so we are delighted and excited to be again looking at the innovations and features that will make SAFE very complete and more efficient.

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

The Crust guys spent the week testing the latest Crust / uTP implementation, with a development version of Routing under various test conditions / environments. Then they focused on fixing bugs related to uTP bootstrap connections. The guys saw unexpected LostPeer events being raised under some systems and this is currently under investigation, with the aim to have it resolved this week. If everything goes well, we should have uTP enabled for Routing next week. The decision was made by the team to postpone the heartbeat implementation as Routing has implemented a similar mechanism.

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

The Routing team added a network-less test framework to the API, so Routing users can benefit from the faster tests too. The guys have also implemented a heartbeat to detect lost peers even if Crust doesn’t. Routing has gone through pretty extreme testing of overnight networks with high churn rates and then analysed for Kademlia invariant being maintained and it’s very impressive to see that all holding true under what is extreme churn.

##Vaults : Brian / Fraser / Qi

Most of the safe_vault personas have seen some work in the last week, the bulk of which has been applied to the ImmutableDataManager. Preparation for the farming rate calculation has been included, in conjunction with an RFC to Routing covering the various flavours of immutable data. Also implemented was the vault config file as per

Tests have now been upgraded covering the majority of code paths for each persona. Also, still on testing, Routing’s mock of the crust library has been integrated to allow full integration testing of safe_vault in a controlled network environment. This allows very quick accurate testing of vault logic (SD handling, messaging, safecoin and then on to…).

##Client - Launcher : Krishna / Spandan / Shankar

The logger in maidsafe_utilities was not as efficient as we wanted it to be, which was causing the tests to crash. @ustulation (currently flying as he and his wife relocate to Scotland) spent some time working in this area to get it fixed and we now have a complete asynchronous logging module. This change also includes the ability to write to a TCP stream, which can be used to send the logs to the visualiser. We have temporarily parked the visualiser and the focus is now on the dynamic data handling abilities of the network. Towards the tail end of last week we had a few good discussions and finally arrived at the possible approach on how this feature can be enabled. The approach is detailed with a simple use case and also there are few concerns in this approach which is also specified in the RFC. We are looking forward to input / discussion / debate from the community and you can make these within the discuss proposed github issue, or within the already active forum thread. At present, an RFC for exposing the Launcher APIs for structured data and immutable data is being worked on.

##UI Design : Scott / Shankar

We ran into some problems with the roadmap last week and are hoping to have those issues resolved soon. A lot of time has been spent collating the data to be used in the roadmap and once the above issue is resolved we can start to demo it; we look forward to receiving your feedback in due course.

Thanks for your support - here is the link to the weekly transcript



First in the dev update thread, a young mans’ dreams can come true :blush:


Without inspiration, innovation is dead.

step by step the era of the creative is rising
#the ants are coming


I think most users don’t mind to jump in some settings to test all out. Especially if we have several hundred people running Vaults and get some very nice info from that. Although I do understand you want to deliver a click-n-run version.

Are there any limitations when it comes to storage? like the 5mb. limit going off when we have Vaults in people’s hands?


:slight_smile: yes! Vaults are coming soon =) i like the decision to release the MVP with TCP-connectors only =)

I know it’s hard to step back and reconsider because things don’t work out as expected … Very Very cool you did it! :smirk_cat: vaaaaaaaults =D :nerd: :upside_down: :poop:

don’t forget to take some moments each day to enjoy the sun and just drink a cup of coffee with some cake =)


There will be a limit in the MVP but should be a more reasonable limit and then increase as we move on. The only real reason for a limit to remain at all is self encryption currently uses in memory resources to handle objects and it just needs to be more stream like. So the limit should increase a bit then vanish altogether.


I guess I am a bit lost on this one…

So a TCP MVP comes first, and then an MVP (or an update) with uTP.

Does the uTP being enabled for routing mean the uTP errors are fixed and should be expected in a MVP in the coming weeks, or is this just one area that uTP is involved in at the moment and there are additional areas that uTP needs to be integrated/bugged fixed/etc…?

1 Like

So, If i readed the technical update correct, we will see a TCP only MVP shortly. The only thing for you guys to release the TCP only MVP is to do some final testing??


Now we see not only how complicated inventing something new (actually quite a basket of things) is; but how involved a workable release can become. It is to the team’s credit that it is in tune with the feelings of its supporters that a change in the MVP is being made and I (and I would guess quite a few others) applaud the entire team for its constant effort and long work hours. Measuring twice so one can cut once takes longer; but the results are usually much more satisfying. I am quite confident such will be the case for us and the development team. We are behind you all. Believe in yourself’s as much as we believe in you and we will soon be looking back at this time in wonder as to how fast all this was accomplished. You all have much to be proud about.


Behind you guys all the way no matter how long it takes. Proud of all of you MAID safers. Thank you guys.


There will only be one MVP then we add in all features etc. to Beta. The MVP with Utp was soaking up waayy to many resources and detracted an awful lot form whats currently important to most. That is getting feature complete network running, “mostly” available fro everyone to run. As features come out this “ease” of running a vault will just get way simpler. Even before Utp we have some cunning plans :slight_smile: more very soon.


Can we clarify what MVP means?

Are we calling the weekly releases the MVP?

Or are we calling the official release 1.0 the MVP? (and if so what features will it have)

Or is the MVP when all the basic features are finally implemented? (safecoin, messaging, etc)

I think there’s been some unnoticed confusion using the term “MVP” and what context it’s being used in.


Ah sorry Minimum Viable Product - so there is only one, it’s when there is something worth saying this is a product. We feel the client examples came close but we still had the vaults ourselves, which is unacceptable. So we made MVP more difficult and refused to call it unless we could give everyone the ability to really run vaults (Even if it’s initially less automatic).


I like to think of it as a Lego set. Just adding things on as it takes shape.

Thanks again for everybody’s hard work and kudos to making the decision to release the TCP only version of the MVP.


Dude, the MVP is clearly the new sandwich at subway! :stuck_out_tongue_closed_eyes:
Powersign has clearly not been paying attention!

II zo. Mou sukoshi, mou sukoshi da…
Excellent. Just a little, a little bit more…


Thanks @Ross, great update. - so there are no issues with TCP - Do we get the TCP/RMVP (Rolling Minimal Viable Product) version today or?


It is good to love many things for therein lies the true strength and whosoever loves much performs much, and can accomplish much, and what is done in love is well done.
step by step the era of the creative is rising

#creation inspires creation


Great decision, imo. I am an admirer of the agile scrum process and this fits well. I am sure the shorter feedback loop will help to refine what is delivered more quickly too.