Hello,
As this is my first write-up here, I’ll just take a brief moment to introduce myself before jumping to the interesting part. My name’s Spandan Sharma, which bears little semblance to my username. I have been working for MaidSafe remotely from India and until recently I had been working as the front-end dev. As we have migrated to Rust, I am now making contributions to both the core and the front-end code :).
So with that out of the way, on with the update. We ended the second Rust sprint last week in which we had set out to create a simple working of Maidsafe DHT network (a very simple one is done, but we hope by today or tomorrow to have a better example for you to play with). It was an important and busy sprint with a feature complete CRUST module (for the planned DHT working model) being one of the major achievements. More work was carried out in Routing with some glitches being sorted out by the dev team, with a few devoting their weekends to make changes. Crust and Routing now look to be API compliant with some minor tidy up to be done there (we expose too much so will tidy this up). As you know by now clicking on the API documentation link on the repositories will show you the documented (and versioned via semver) API.
Sentinel (the module that confirms group based consensus on messages on the network) also received some TLC with further considerations being given to it’s design prior to implementation. Sentinel was also abstracted out as generic library and it now enjoys its own crate. The implementation that can now be seen has parametric polymorphism and can be pulled in from its own separate crate.
David has also migrated the code-base for all MaidSafe libraries in Rust from his repository to a newly created MaidSafe repository for Rust. From Github’s point of view there requires no change, contributors will now have to however modify the tracking upstream pointer in their local devices to point to the new location.
Apart from the main sprint, the previous week also saw a few equally important tasks being
carried out in tandem. For instance, exposing Rust code in the simplest maintainable way to other languages (with the purpose that ultimately the MaidSafe API will be available to the developers in a variety of languages), a POC setup for Highfive and nightly Jenkins build for maidsafe_vault. Highfive picks up reviewers for each pull request automatically and assigns it to them.
In a brief interlude from dev tasks, Ben delivered the keynote speech at the Amsterdam Bitcoin meetup, one of the largest in Europe. Ben’s 45 minute talk was well received and was attended by a few community members. While Ben had a good one in Amsterdam, Nick had no less in Las Vegas and just in case you missed it he published a trip report here.
Getting back to the libraries, with a view to continuing to decentralise responsibility of the underlying code throughout the core team, we have decided to implement specific library maintainers, essentially direct points of contact for specific library related queries. There will be two maintainers for almost all libraries, a primary maintainer and a secondary maintainer. The secondary will become active if the Primary is not available, here’s the distribution so far (Primary followed by secondary):
CRUST: Prakash, Niall
Routing: Ben , Peter
Vaults: Qi , @ustulation
Client: @ustulation , @Krishna_Kumar
Drive: Mahmoud, Brian
Self Encrypt: Brian, Qi
Sentinel: Peter, Ben
Types: Mahmoud
LRU, Accumulator and Message Filter: Prakash
This weeks focus lib is CRUST (connections in Rust) GitHub - maidsafe-archive/crust: Reliable p2p network connections in Rust with NAT traversal. One of the most needed libraries for any server-less / decentralised projects. This is an exciting library for any p2p project and we hope other projects will make use of it. Initially this uses TCP as the first protocol with Reliable UDP currently being added. This library has the ability to manage and maintain connections within any P2P network and remembers connections previously seen (and directly addressable, i.e. NAT traversed). At the moment it requires compiled via Rust nightly builds as it uses a Weak pointer like structure which is not yet cut over to beta.
To see it in action (for those who like to play) then it’s the usual (add in git clone/build/test instructions) and in the target/debug/examples folder you will find some example uses of the lib. There are a few files and to begin with you can run a simple receiver / sender pair. If you run the receiver and then in another terminal run the sender you will see data transfer (OK boring). For a more interesting example consider rust_node, this shows the ability for nodes to connect automatically to each other and create small self-connecting networks. You can run this on your own machine or several machines on the same network.
So start a node by typing ./crust_node and you will see it start a beacon listener. This means it’s listening for any new nodes starting and will answer them with it’s endpoints. These new nodes will then connect to this one. To see some data send/receive examples type crust_node -s 1000 and see the node connect, find the network and continually send / receive data. Set up several nodes and see them all interact.
This is important and as the README on the repo will show it is a great foundation for a self discovering network to start up. We then add further functionality via routing to create a neat secured DHT, but that is for next week 
and as we drive towards launch everyone will see all the pieces come together and why each is important.
CRUST still has a few to do’s, as can be seen from the README, but none that will affect the API.
Anyhow, I hope you enjoy playing with this example, the start of an autonomous network is coming to your computer right now, it’s going to be enlightening
So reflecting back, good progress overall and this week we turn our attention back to planning the next sprint, more details to follow on that next week. It’ll hopefully make an interesting future update !!
