MaidSafe Dev Update :safe: 8th December 2015

Again this week the update is another collaborative affair, with contributions coming from the entire development team for their respective areas of expertise.


Last week @Fraser sincerely expected that next week’s update will contain news that we have implemented a working test network of Vault nodes! However, once we confirmed the routing tables getting populated as expected in the clean-up branch a lot of focus has gone into documenting the required structure of the routing library to facilitate security validations which previously was missing in the message flow through the network.

In the previous iteration, the main goal was to get rid of code complexities, needless indirections and constructs (such as unnecessary stateful containers) so that everyone could see the existent flow and uncover the hidden bugs. This was a success, because we did expose the bugs hidden in the complexities and now we have a simple but functional Routing network on the droplets as the previous Dev update stated. With that out of the way, we are at a much more comfortable spot to focus our attention to the code flow, making it as secure and maintainable as possible so that the users of routing (vault and client modules) benefit.

Moving forward, we will define an accurate set of messages for different purposes learning from the mistakes of the past which made us start the refactor in the first place. Once these messages are in place, the plan is to chalk out the flow that involves least (ideally none) amount of vagueness. This could be a precursory step towards a full fledged state machine which we ultimately plan Routing to behave as.

In parallel, we will be focussing on proper authority management and precise functional delegation based on it. The authority checks are vital and pivotal to the language of the network. Once done right, this allows Routing to guarantee the source type and destination type of every message and ensure it is 1: unique, 2: correct and 3: secure. This allows Vaults and Clients to react to logic without having to perform any validation checks on received messages. It is this logic that allowed us to reduce Vault code by 98% way back in March and this efficiency is something we very much strive to uphold.

The last pass would be to take a deep dive into the security auditing of what we have done so far to check if there are obvious loopholes.

For people wanting to delve deeper here are the latest Routing work-flow diagrams for
Bootstrapping and Node Discovery.


In Crust this week the focus has been on resolving testing issues. Network tests with rust-utp were failing. After investigation, we discovered the issue was due to missing uTP packages, which you would expect to happen in the wild when you use UDP. Tests on loopback network were failing due to the interval between the call to read and the handling of the result, a time in which we weren’t reading and could lose some packets. The congestion algorithm and the strategy of when to resend needs to be improved to definitively fix the issue. However, we are going to first write a mechanism in Crust itself to be more robust in this situation, by detecting connection loss itself and avoiding really long delays until a connection was detected to be lost.

In addition, we had a problem to sort out with some of the tests where they were written to expect a 100% throughput from utp tests, however, that wasn’t what we expected from uTP?. This issue has now been addressed and @qi_ma is now looking into an issue where some Crust tests are not completing in certain environments.


Last week an RFC for authenticated and unregistered access from Launcher was raised. This RFC outlines a proposed approach that will make the Launcher much more user friendly, without any application binaries needing to be configured. The suggested approach will make it simpler for users to get started with the SAFE Network.

This week we will finalise an approach for the add-on and this will be confirmed and standardised through an RFC. As explained in the last week’s Dev update, the standardisation is necessary at this stage so that developers will only have to follow one approach. All the browser extensions will work the same way across all supported browsers. So, for example the scheme SAFE: might not be used, this is because not all all browser extensions support custom scheme interception. We might be falling back to using http but the extensions / addon will intercept any requests which end with .safe. Meaning we might use instead of the current scheme of safe:maidsafe, this is just an example and nothing has been confirmed yet. The final approach will be decided on further analysis of the browser extension APIs for Chrome, Firefox, Safari and IE.

#MaidSafe Website

Last week the website was refined further from a design and user experience perspective, and a few minor style changes have also been implemented. A page to describe the job openings at MaidSafe, a very simple contact page and the most interesting company page with all our staff images was implemented last week.

This week will see the last wave of corrections and enhancements, enabling an internal review later this week. As we have previously mentioned, this new user focussed site is very much a starting point rather than the finished article. This does suggest that the project has been rushed through, on the contrary, a significant amount of work has gone into the new site. However, as the user base, community and range of network features grows so will the site and we would anticipate a web page that continues to evolve and improve over time.

@ioptio also posted up a new blog post this week which is well worth your attention, check it out if you have not already had a look.

Link to the Team Update


Yay first reply!

If I may ask this of the devs - more comments in the code please!

Other than that I’m very glad to hear that everything is progressing.


MaidSafe Dev Updates has become my favorite sci fi novel. There is always so much suspension…

While I can’t fully comprehend the code you guys write, these weekly words are powerful.

Really appreciate this and thanks for all your hard work Core devs :stuck_out_tongue:


"Last week @Fraser sincerely expected that next week’s update will contain news that we have implemented a working test network of Vault nodes! "

Why didn’t this happen instead of the documenting? This weeks update feels disappointing after the position we were in this time last week.


Thanks for the update!

1 Like

@Ross This allows Vaults and Clients to react to logic without having to perform any validation checks on received messages. This is HUGE CONGRATS!

1 Like

with every step the era of the creative is rising

1 Like

We talked about this one 6 months ago. If .safe works similar to .onion then it makes my job easier to explain navigation. You have my support on this one.


.safe is an already existing TLD though.


Sure? As a top-level domain, not for now.

I see SAFE in that list.

1 Like

It shouldn’t be a problem if it works like .onion addresses with the SAFE plugin.

.onion is a special-use top level domain suffix designating an anonymous hidden service reachable via the Tor network. Such addresses are not actual DNS names, and the .onion TLD is not in the Internet DNS root, but with the appropriate proxy software installed, Internet programs such as web browsers can access sites with .onion addresses by sending the request through the network of Tor servers.

The only issue I see is when someone tries to surf the DNS .safe address, while the SAFE plugin is active. In that case, they would have to turn off the plugin. Otherwise, they would end up in the SAFE Network.

Such addresses are not actual DNS names, and the .onion TLD is not in the Internet DNS root

My point is that the .safe TLD is in the internet DNS root.

1 Like

At the very least, it opens up the possibility of spoofed sites. You have a .safe site, and I buy the .safe domain name that matches that and spoof any visitors who try to go to your site, but who have a disabled plugin.

To protect from that, you now have to buy the corresponding .safe domain yourself, which breaks your anonymity.

Just as Tor does not use .tor as the extension, perhaps safe can use something else.


The documenting was necessary in order that the team fixing the library could understand what was going on within the code to allow them to fix it. To clarify, the team didn’t stop implementing fixes to write up documentation, rather the documentation was an essential early step in that process. I hope that makes sense.


I’m not disputing that.
As @Ross said, the plugin will “intercept” any requests which end with .safe

I did acknowledge this may conflict with an actual DNS .safe address.

1 Like

This is true…

But do we really think the regular internet will never make a DNS .onion?
Even if we picked something like .ZSXGFSD… they could just add it to disrupt/confuse new people away from our network.

If it makes things easier to launch, I would say “yeah”, let’s pick something not on the DNS root list. But I don’t see it as a permanent solution once the SAFE Network becomes popular.

1 Like

You right. I miss it.

Big problem…We need to find some else…

Exactly - that is a problem. But so is not being able to use “.safe”. The “safe:” is definitely better but, we absolutely need a consistent scheme across different browsers. :-/


I think we are all in favor of SAFE: scheme.

Unfortunately, it’s a problem with some browsers. The OP said we might fall back on .safe which has not been confirmed. This might be a good time to discuss solutions. Maybe move to an older thread or make a new one?

If we do decide to use the dot.extension we will need to decide on the name of that extension, if not .safe.