MaidSafe Dev Update :safe: 27 October 2015

Yesterday we entered the third week of the Rust-5 sprint. As Ben nicely summarised last week, we’re concentrating at three main objectives:

  • UDP hole punching in Crust
  • Connection management in Routing
  • The SAFE Launcher in Client.

I’ll start with Crust as that is closest to me at this point. UDP hole punching is ready and we added some new functions to Crust which users can run; holes in NATs are created and we can send UDP datagrams from one peer to another, even if they are behind firewalls (this is testable with our modified crust_peer example). The next step was to use the punched holes with the rust-uTP library. There are some bugs here that we need to solve in Crust to be able to fully deliver this feature and we are working to solution those this week.

Another part of Crust/Rust-5 sprint was a tool to measure, report and test connection reliability. It was created by one of the guys from the community and Fraser, together with Krishna, were working on a deployment tool for this test. As expected, TCP connections are nice and stable and it has also helped us pinpoint some minor issues in the Rust-uTP library which the author of the library promptly fixed.

QA team also made a small but super useful tweak to the CI machines. For some time now, we’ve had the problem that we had to wait for CI machines, often as much as 2 hours, as devs often committed their new pull requests at the same time causing a few of the tests to halt and the default scripts took too long to kill them. Now, if a machine doesn’t finish within 10 minutes (which is more than enough), it reports an error and moves to another pull request. We already feel benefits of this change. On top of that, Ross also started working on building the software on odroids [ARM].

The Routing library still has a few tasks and issues (the issue needs to be resolved before we can test vaults/launcher against even a tcp network, Brian is looking at it now) to complete and this library has also been affected by hole punching, as now connection establishment necessarily needs to include one additional asynchronous step which is the act of figuring out our external endpoint. Yet again, a task which appears minor at first sight but is really a big change in the connection establishment logic, combined with safety guarantees that Routing needs to keep in mind, these guys have a hard nut to crack. The integration of uTP into Routing is blocked by the current bugs in Crust which emphasises the importance of solutioning the Crust issues.

The work on launcher is complete for the first iteration. It was a big deliverable for this sprint with more than 8000 lines of code being committed. In order to test Launcher, we have been writing a compatible test application in Nodejs which we will run against the Launcher CLI coded in the examples section and see how things fare. If everything is smooth and as expected, the first version of the Launcher can be considered to be completed. The CLI will act as an example front-end, a pre-cursor to the Launcher UI that will likely come up in next sprint.

The great news here is that the app-devs can start working on their apps right away! Launcher exposes JSON RPC like convention, so there is no need to know about the internal workings of the SAFE Network to build apps on it. One just needs to follow the JSON API documentation in the RFC.

So, we have made really good progress during this sprint. We spent a great deal more time on planning and this has not only enabled the community to become more involved than ever before, completing around 10% of the points, it has also allowed the MaidSafe team to stay ahead of schedule. The success of the sprint is now dependent on fixing the Crust and Routing bugs although it is great to be able to deliver the new Launcher API to the app devs.

And to be complete, here is also update from Justine.


So cool @Ross ! Count my odroid in for the tests !


Impressive and outstanding effort. :grinning:


Hey, that’s my line! :smile:

Good to know there are other Odroid folk out there. I was hardening my Odroid security at the weekend and, impatient as ever, also got Rust and Cargo (nightly) running on one!!! It was not actually very hard - there’s a post in the Odroid forum about it, but I plan to make a step by step guide if there are others who would use it - also on how to make your Odroid more secure from hacking. No point farming lots of Safecoin and then getting robbed!

Farming Guides?

I’m wondering if it is worth creating a farming resource based around different equipment.

For example, I’d be happy to create and maintain a how to guide for Odroid (how to set up security, install a vault and get farming Safecoin, how to automate monitoring etc.).

Would others be willing to commit to doing this for dedicated hardware such as Raspberry Pi, Beaglebone etc. and for generic but common platforms (Windows, Mac, Linux)?

If you’d be interested, join the discussion of farming guides and mention any platforms you might be willing to create support for.


I’m rather happy to see that the community has contributed significantly. Certainly there has been a progress made on that matter. Not too long ago the community was rather isolated from the code making, however I can’t help but wish it was even more engaged. If 90% of the code making is concentrated in the core development team, I think that makes the project vulnerable. I’m envisioning a level of engagement comparable to the level of engagement among the Linux users. I wanna see a community involved to an extend that even if the whole developers team suddenly disappeared the project would still launch. The more involved the community is, the faster the network will be delivered, the more decentralized it will be. I think that’s needed even more so now, when the price of MAID is really hurting.
I wonder what else could be done to recruit more code writers from across the globe to join the effort and finally bring the project to life.
Is there anyone on board working or at least pondering on that matter?
My heart is with MaidSafe, but I can only wish I had the skills to help the code building.

1 Like

I totally agree and increasing community involvement is always at the top (or near too :)) the top of our agenda. But I think given our current stage (on the cusp of enabling remote users to join the network) it would not be advisable to have a sudden and rapid shift to community development, there is still a decent amount of management (speccing tasks, reviewing and feeding back on PRs, reviewing RFCs…etc…) involved. IMHO a steady transition would be better and I think continuing to publicise the bounty program, getting back to holding hang outs (we will be doing this shortly) and working more closely to developers is a good way forward. We have seen really good progress in just 2 sprints and I suspect this will continue and grow.


i am sorry for my poor English, what do u mean "completing around 10% of the points? 10% of community join this project or this project has been done only 10%?

I very much agree, steady growth is the right approach. You need a solid foundation, and each layer added needs time to bed in, or the structure will fail.


At the end of the current Sprint, remote users will able to connect to the network?

No problem. The last time I checked (Friday last week) the MaidSafe community submitted pull requests representing 10% of the story points completed at that time. So 10% of the sprint work was completed by coders through the bounty programme. As of right now, 89% of the sprint has been completed.


All things going well yes, this is facilitated by integrating uTP in Crust and Routing. I think this was highlighted as one of the main objectives in earlier posts relating to the current sprint. If you’re looking for a bit more info about this I recommend the following RFC. Hope this helps.


definitely awesome, i wish i could be a good coder so i will help the project, but coding made me miserable when i studied in the university.


Yep, cool huh? :smile:

There will be some simple command line test apps, certainly storage, I’m guessing uploading & browsing websites, so get a static website ready to share!

Everyone Create A Simple Safe Homepage!!!

Hey, we should all create a homepage on SAFE, and we can link to each others pages as in the early days of the www - lots of sites joined “web rings”, so let’s do that! And someone will no doubt build an index page :smile:

Let’s Build It Together

For anyone unable to create a simple HTML page the community could volunteer to help, so everyone who wants to can join in The First SAFE Web!

See Let’s Create The First SAFE Web to get/offer help doing this.


31 likes in the first 4 hours is GARANTEE a new record


Cool times infinity maybe. :wink:


and the dump whales will cry soon, cause we will change the world soon


The topic has 244 views in a few hours and I also updated the page on bitcointalk which got over 50 views in the same few hours. We’re also seeing 2 new users every day again, which is a bit up from a month ago.


Keep up the good work!!


SAFE Apps!!! :smile:

The “JSON API” is a link to an API for app devs?? If so I’ll tell my coding buddies about it!! They’re very eager to start making some test apps!!!

1 Like

as the old saying goes … an image… would be great if more visual stuff was included for people who are more visual :slight_smile: