MaidSafe Dev Update :safe: 20th July 2015

Hi all!

This your second update during the rust-3 sprint. So a brief recap of the main objectives is a good place to start. The foundational objective is the implementation of unified structured data. These data types allow the network to better understand the data it is handling. They also allow the data to be cryptographically owned. As a consequence, the identification of clients can be simplified to nothing more than the public key with which they sign their content - gone are MAID, MPID, MSID; less complications, less overhead, more possibilities. We also push this change to nodes in order to better secure address relocation.

The third objective of the sprint is the decentralised naming service. This is a simple application of how the structured data allows the network to achieve new decentralised functions. As a final consequence of the structured data RFC, both Vaults and Client will have to update their existing functionality to the new fundamental data types. Parallel to this work, CRUST additionally introduces parallel bootstrapping and strict control over bootstrapping with a configuration file. CRUST also adds support for Universal Plug and Play (UPnP) to discover nodes. Lastly, and long awaited, routing plans to activate the Sentinel implementation as a cornerstone of the secure consensus algorithm.

So what is our progress eight days in? The dashboard shows we’re half-way there and on track! The development team have completed all major CRUST tasks for this sprint: parallel bootstrapping, UPnP. Routing has undergone a pretty significant refactor when implementing the first two RFCs. Work carried out so far includes: providing the three fundamental data types (plain data, immutable data and structured data), restructuring the messages to carry these data types (and how they are handled), and finally, changing the clients and nodes to be identified by their signing key. Both CRUST and Routing will publish a new minor version in the coming days.

Client and vaults have been strongly liaising with Routing to be ready for the new data types and likewise routing will have to adapt to the new procedures in the CRUST API. Client library has been separated from NFS and a new repository created. Also a new DNS crate has been started.

As I’m a Routing guy I’ll give you a short additional highlight from Routing. The introduction of the fundamental data types has enabled the simplification of the language of the network. With the new code, a message is considered to go from a source A to a destination B before a message could be sent on to a new persona. If B then sends more messages these will be considered as new messages, but with the ability to attach the original signed request message. For the technical folk, we will write < A | B > < B | C > from now on - no longer < A | B | C > as you might have seen before.

This change is a result from the big increase in security we have achieved by cryptographic ownership of the data and it is a big step towards the eventual consistency paradigm of the network.

In amongst all the development work, some of the team also found time to have a technical meeting with the Rust core development team. Their commitment and support is greatly valued and @ustulation and @Peter_Jankuliak are doing a great job representing MaidSafe in the Rust community.

On a final note we want to thank Niall for his many months of dedicated work and expertise. Niall has smoothed our transition over to Rust and we wish him every success as he continues his work with his much favoured C++.

Here’s the dev transcript

Cheers! See you all next week!


If you got rid of MPID, MAID and MSID then how are the logins, personas and all that organized now?

I would say “in exactly the same way, but with less work”, so

  1. there is still a login packet that allows you to save and restore your session.
  2. in the login packet, or in other structured data elements, clients can securely store encrypted keys to your entire kingdom; the network just no longer recognises them as MAID or MPID or … it just sees the public signing keys as the validation of ownership of data
  3. in previous days private and public keys were also much larger; but we switched to elliptic curve encryption which offers the same strength, faster encryption/decryption and smaller key sizes (keys are now 32 bytes, correct?)
  4. for functions like public data, or shared private data; these functions can be taken over by a combination of the new StructuredData and smarter clients, which helps us build a more secure network

No dev update for this week? (Jul 27th)