MaidSafe Dev Update :safe: 8th June 2015

Hi everyone, I am Prakash. I have been working for MaidSafe since Jan 2011. I am part of core dev team and have had the opportunity to work in multiple libraries. The recent move to Rust has been really exciting for me. I still remember my first week with Rust, when myself and Peter started coding the Crust library. We had just one test and I was very sure that we wouldn’t be able to get any library to work on the very first attempt. However, I was very happy to be proved wrong! Obviously, I had trouble getting the code compiling as it was a brand new language to me. But the Rust compiler takes a lot of bugs away.

This week we are in mid sprint and it has been very busy indeed as this is the first sprint planned by library maintainers. We ended up adding over 25% extra work to the sprint, which is a sign of the maintainers getting used to planning. Last week we made that time up and more. We are all very confident we will finish this sprint early and then get onto planning sprint ‘rust-3’ which should see the addition of further features.

The roadmap should see the light of day this week and it may surprise many people. Not only the speed of delivery, but how we will deliver. There is no release date, we simply will add features and APIs for developers straight away. So this will be a rolling roadmap through what would be traditional launch and more. The reason for this is that we want the community to create apps as soon as possible and so will we. It’s not the network that will launch as such but the killer app and we must find that. It has been our goal and ambition to make this happen for sometime and it’s great that so many people are involved. From core developers to active community members to quiet supporters, each helping in their own way.

Community involvement in Sprints
The current sprint showed us that decentralising the knowledge makes the libraries very accurate and efficient. It’s also proving to be a much smoother process. The planning is more accurate and the reviews are more rigorous and faster. We are now taking this idea to next level by involving the community members / developers in the sprint execution. So, the next sprint will be open to all!!

We will publish the tasks required in the sprint and anybody can attempt a task and contribute to the libraries. To encourage and appreciate folks to contribute to our codebase, we will pay around $20 for each point (a point is approx 1 hour, but we find it is much less) achieved by the external developer. More details on the payment mode and process will be published soon by Nick. We are excited by this as we already have commits from the general community and the ability to work on a new language really appeals to many people, but if we can pay at least a little then it all becomes more engaging. We will of course review all work and be as critical as we are with ourselves (which is pretty critical). What a way to learn a language and a project as potentially as important as SAFE!

It may sound a bit difficult initially, but we will ensure that the tasks are well described and suitably specced. We will be happy to clarify doubts, review and also help you finish the tasks. We believe this is a huge step forward as it will spread the knowledge and make the community interact more closely, at code level.

Next Sprints roadmap
With another two very focused sprints we are aiming to have a feature complete system, which will include safecoin. After this we are planning to have a feature sprint and a technical debt sprint. Further sprints will then be focused on Apps and Examples.
Feature Sprint will be where we add features to the system. This will include feedback, compute, semantic data structures, private shares and more. These are what people will recognise as a typical sprint in the sense of agile development. i.e. this is what we have been doing so far.
Technical debt sprint will aim to improve the code quality and introduce good practices like use of advanced iterators, efficient patterns and algebraic data types in Rust. This will help in reducing the codebase size. Smaller code means less maintenance effort and less bugs. We are also aiming to boost team’s knowledge of rust programming in this Sprint.
Apps & example sprints will aim at releasing useful apps and examples based on different libraries. This is where we (MaidSafe team along with the community members) will come up with new app and example ideas and release it at the end of each sprint. Having multiple apps built on any library will force our APIs to be more usable. This means we will have API changes in libraries based on the needs of the app. This will help our APIs evolve naturally rather than the MaidSafe team thinking and acting on behalf of all the users :-). We will continue coming up with more example app and more features on every sprint.

Current Sprint progress …
Updates from Justine in the link here


I know when the devs speak, don’t ask to many questions, because this keeps them from coding. But I’m just SUPER EXITED about the Apps & example sprints annoucement. I wonder what the format will be?

  • Community members pick an app and it gets developed after voting
  • Community members pay the Maidsafe team money to have an app developed

@prakash Thanx for the update! Did anyone looked at a website like Topcoder where you can put up a “challenge” for coders to help out with code? Maybe worth looking at? Would be in line with incentive’s for coders.


This is a great update! I’m really looking forward to everything!


Is this just for the next sprint or is this going to be common?

1 Like

The process for this part still needs to be considered in more detail. The purpose of the update was to provide a high level overview of how we saw things moving forward. It is a very fair question though @19eddyjohn75. We’ll need to see how other projects have handled these issues to find a solution that works for us.


All things going well this should be a permanent feature.


This is us from now on :wink:


I thought compute was coming way later so does this mean that distributed computing will be a feature right from the get-go?! And semantics! I feel like screaming MAIDSAFE IS THE FUTURE!!! from the rooftops at this point


No, compute will be a later addition @Nigel, but please feel free to scream all the same :slight_smile:


It’s all getting into the pipeline now we can progress at speed. The language of the network issue means all of this becomes factors simpler to introduce now. You will see my repo’s starting to sketch a lot of this out (compute (version of bloom language dsl (bud), semantic data, sirius (separate project , but valuable if decentralised)) etc. Many of the other Engineers will have the same I am sure (but they are very busy getting version 1.0 out at the moment, my job is to investigate what happens in three months from now), yes I get the exciting part after all this time, which is very nice, it was 2007 when I last had the chance to really focus like this. Lets see what happens now when we take the full team and community, my feeling is we will see dramatic and possibly anonymous improvements fast.

Then the Engineers will get it and make it happen. I expect this all to take place at the same pace as we currently are working and perhaps faster as we build community involvement. So expect some previews of this in coming weeks/months as we get to feature complete. It’s a large part of the picture that will be what we envisioned for the project. A planetary sized network, for the people, by the people and unstoppable. It’s a nice goal and achievable now. Think of all the advances in medical end point devices to analyse all sorts of conditions passively. Add in some autonomous (human resistant) network to compute and store this info and then we will see what happens.

People will think, who do they think they are, trying to design everything from scratch, but it’s quite the opposite, all we are doing is planting the seeds and providing the amoeba. SAFE network version 1.0 is just that, a seed, when others add to it and projects then build on it and make it truly community driven, then I hope there are hundreds if not thousands of projects like I am currently looking at. I intend for us to show a glimpse of what is possible with this and let folks innovate at a pace never seen before, safely and very cheaply.

So it’s not us doing everything, we just point out what is possible and then, hopefully there will be thousands of projects using safe secure and private methods to improve the network.


I saw gaol in your repos too for sand boxing. I’d read on Sirius also after seeing it. Very exciting stuff for this project. I think the work the team is putting in adding these features and apps from the get go will really help in adoption, this is the next logical step. Congratulations on the swift progress


Yes this is destined for [edit] vaults, clients and launcher as soon as the next two sprints are there. It will allow more security and also configuration management. So a nice feature we can just grab and use. Makes life simpler as well.


Don’t have to speculate any longer :slight_smile: always improving

2 questions:

Suppose I know absolutely nothing but I want to help out with the coding. How do I get up to speed quickly? Is there a resource I can go to?

Also, at what stage does the farming get set up? I want to start farming.


Reading the system docs is a start (on website), if you code then looking at the Jira flow and grab a task, or even the gihub issues. If you are looking to start coding then there is a thread on here about that from a few weeks back which will help.

The network will have initial farming rate calculation this sprint. There are a few parts to farming so maybe next sprint complete, but perhaps it’s 2 sprints away to complete, lets see after next weeks planning. Our priority is a safe secure network to store / get data (messaging/public shares ) etc. first as that is critical, then farming as well as an awful lot of features. roadmap this week so you will see there what is in the channel


i’m getting the feeling the team really found its rhythm by now:

1 week planning → 3 weeks sprint

after doing this n times we’ll be there :wink:

looking fw!


“gaol”? Looking . . . haven’t found what this means.

GitHub - pcwalton/gaol: Cross-platform application sandboxing for Rust :wink:


Thanks. Rust just keeps on giving, doesn’t it!!