Last week we shared the list of outstanding TODOs we still had to complete before the MVP was ready, so how are we doing with this?
- NAT Traversal integration into Crust (allows for people behind different types of routers to connect with each other and not just rely on direct connections between nodes in the network);
- Routing Integration with Refactored Crust;
- Churn Handling in the Vault library (showcasing with Routing and Vault examples);
Completing the Launcher updates from the client libraries.
Task four is complete. For tasks one and two the integration tasks have been completed and they are both in the final stages of testing; these shall be marked as complete as soon as the guys have finished and are happy with the testing results. The Vault guys are working on task three and are quite comfortable with churn handling from the Vault library, however, they are waiting on the Routing testing to complete successfully before signing off on this one.
The priority and focus of everyone on the team is getting the MVP into your hands. This will enable as many people as possible to be involved in testing the MVP, capturing your experiences and sharing these with the dev team, as the MVP evolves through each iteration.
##MVP
So a very exciting and manic week last week and more of the same this week; however, without being a party pooping spoil sport I think it is essential to set expectations. The MVP will initially come with a set of limitations; I am currently documenting these limitations and these shall be shared with everyone as documentation accompanying the actual release. The MVP will very much be a rolling release, with these limitations being crossed off the list with each software update, which at the outset will occur on a very frequent basis, driven by feature updates. Expect the network to be up and down, with software required to be updated and data stored on the network to be wiped during this community testing period. Initially this may not be for the faint-hearted and will require participants to closely follow updates from the team to stay on the latest network.
We are working just now on the best method of communicating these rolling updates with everyone involved and also on the easiest way to collect user feedback and analyse everyone’s findings. As you know the SAFE Network protects the privacy of everyone within it and therefore collecting this feedback presents its own challenges. So we need to rely on individuals recording and collecting their experiences and choosing to share those with us as we have no way of monitoring users on the network. Details of how to participate will follow within the MVP documentation and of course you do not need to share your experience, you can use the MVP and network as you wish.
##Crust - uTP / API : Vinicius / Andrew
The team has finished updating the Crust and nat_traversal crates to work properly together and updated the crust_peer example to demonstrate the library working. We have been testing the code and are confident it is behaving as expected, but we would like to add a few more tests before releasing a new Crust version and then start adding features to enable the nat_traversal crate to achieve a higher connection rate under more restrictive NAT setups. The Crust API also changed a little too after feedback provided by the Routing guys.
##Routing - Vault Integration : Andreas / Brian / Adam / Fraser / David
In the last week, our main focus has been working with the Crust maintainers to agree on the new API and to get to an initial version of Routing based on that API. This revealed a few issues with connections that were established using hole-punching. While work on UDP connections and NAT traversal is ongoing in Crust, we are currently debugging and fixing the remaining Routing and Vaults issues with a TCP-only Crust. One of the remaining tasks is to make nodes more resilient against malfunctions, for example, we currently allow only one node to join the network simultaneously through any given proxy node and if that node fails to complete its insertion into the network, it will indefinitely block that slot in the proxy. However, thanks to this limitation, we have already found another problem: even in small local test networks, we are still seeing nodes failing to join occasionally and not all connections that we would expect are actually established. This exemplifies the two fronts we are currently working on: making the network more resilient against malfunctions and fixing the malfunctions.
##Messaging : Qi / Brian
Messaging tests in Vault have been expanded to be part of the CI test over a local testnet. Churn handling for the MpidManager has also been added. The Client example of the messaging feature has also been implemented and is now under the procedure of integrated testing with the latest Vault, built with the latest Routing.
##Client - Launcher : Krishna / Spandan / Shankar
The Launcher tasks have been completed and are now being tested. We are also making a start on creating a demo app that will be a single application to demonstrate the features of the SAFE Network. Features like creating a public id, managing the services for the public id and private data storage are planned to be integrated into this demo application. This will prove extremely useful in a few key areas:
- To showcase the features list above;
- To illustrate how to use the APIs with Launcher integration; and
- To test with some real data.
Below are a few mockups of this demo application.
So, after almost exactly 10 years of work we are on the cusp of entering a new phase in the development of the network. We would be naive if we did not expect this journey to begin on a bit of a rocky road for the first few weeks as we fix the issues that you report and reduce the limitations. It is great to be able to report that the MVP delivery is still on target and to have you guys on this journey with us. Please keep your eyes peeled for that all important MVP documentation (this will come via the forum) and thanks again for all the support; here is a link to the transcript.
