Again this week the update is another collaborative affair, with contributions coming from the entire development team for their respective areas of expertise.
#Routing
Last week @anon86652309 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.
#Crust
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.
#Client
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 http://mysite.safe 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.
