Hiya,
Last week was another busy week, after the sprint we have been working on different action points. Starting from the handover of @benjaminbollen, fixing issues in crust and routing, new RFCs etc.
As mentioned in the last week’s update from @anon86652309, the handover process from @benjaminbollen went as planned. Andrew has quickly got his head around the Routing implementation and with Andrew’s expertise, we can only expect the Routing library to get even better in the near future.
Andrew has also raised a WIP RFC to detail an approach to refactor the Crust code base, so that we can use stabler version of Rust rather than depending on the nightly version of Rust and also make the library efficient and easy to use as a generic transport lib. While Andrew is busy with the RFC and the handover process, @Peter_Jankuliak and @vinipsmaker have been resolving the bugs in the Crust library.
Unexpectedly @qi_ma was unwell and we were short of him for couple of days last week. Also, @brian_s would be away for the next two weeks on annual leave. Since both the maintainers of routing are not available this week (Andrew and Brian), the Client and Vault guys (@ustulation and @anon86652309) are stepping in to Routing to review the code and make improvements, assisted by David. When @qi_ma resumes work, he would also be working with Fraser and Spandan in the routing library.
While others are busy working on the core libraries, I get some space to do feasibility analysis for getting the add-on compatible with the launcher workflow. I completed a proof of concept to expose the network API from the add-on, so that the application developers would be able to interact with the network using the API. Once the analysis is complete I will detail more on how the API would be exposed for developers.
We would be continuing improving the libraries until the issues in Routing and Crust are addressed. This interim period will help us improve the code base without adding any feature as such.
This week we have the updates from the maintainers for certain modules that are being actively worked on:
Launcher (@ustulation and @krishna_kumar)
@ustulation had raised an RFC for unregistered client access. The primary objective of this is to allow the applications to access the network to fetch public (unencrypted) data. For example, in the proposed RFC, the Firefox addon will be able to read public data, such as websites, from the network through the launcher without authentication. It would only need an unregistered client to fetch the data from the network.
In addition, the RFC also details about the discovery mechanism, where the application would ping launcher for access rather than the launcher starting the application. At present the application is to be added/configured in the launcher and then the application should be started from the launcher. So an alternative approach is detailed in the RFC, where a discovery mechanism would be in place, through which the application will connect to the launcher. Once it connects the launcher will ask the user for his consent to allow the application to connect with the SAFE Network. We would definitely like to get input from the community on this proposal, so please feel free to comment on this RFC within GitHub.
The reason for the alternate approach of authorising the application is that there can be restricted environments in which the applications are being developed, such as with a Firefox add-on or Chrome extensions. They do not allow the extensions to intercept the command line arguments being passed and this may become an issue as we expand to other platforms of application development. Thus we are forced to search for an alternate approach for scalability.
Scott has been working on the mockups for the Launcher UI. The mockups may be updated based on the discovery mechanism once the design and approach is confirmed.
Crust (@Peter_Jankuliak and @vinipsmaker)
So from Crust’s perspective, last week was still about bug fixing. The first bug was quite an elusive one, it only showed up on Windows CI machines when running tests. On top of that, it wasn’t any single test that made this bug manifest itself, it was only when all the tests were run that we saw it. Luckily, @andrew found out that if we run the tests on a virtual machine we can reproduce it, from there, it was just a matter of hours for us to have a fix ready.
Later that day @anon86652309 went ahead and tried running the crust_peer example on multiple real network PCs (which we call droplets). He has done this before but this time he was testing Crust over the uTP protocol. Unfortunately, the results were not positive, only a few machines connected and some of them froze. After some investigation, the issue was traced to the rust-utp library. In particular, on few occasions, the library failed to send some packets. We managed to fix this problem (in the same PR) and we can now reliably connect two peers and exchange data using uTP, but yet again, our bug squashing quest is not over as we noticed that when using many (>10) uTP connections, they start to consume CPU heavily to the point where nothing gets sent over the channel. Peter is going to look at this this week, his suspicion is that there is a problem in rust-utp’s congestion control algorithm.
Routing (@anon86652309 and @ustulation)
With Ben’s departure at the end of last week and Brian being on leave for the next fortnight, Spandan and Fraser have taken on the task of looking at the ongoing Routing bug. Spandan has seen Routing from Client’s perspective while Fraser has seen it from the Vault one, but neither has had to dive into the inner working of Routing yet. So this is a good opportunity for consumers of the Routing library to see what goes on in there.
They’ll be starting by doing some housekeeping work (e.g. updating API functions to return errors where appropriate, and adding further log statements to help the debugging efforts) as well as creating a new common utility library to avoid duplicating helper functions across several libraries.
The hope is that over the next couple of days of housekeeping, they’ll become more familiar with the core Routing modules and will increase the “debuggability?!” of the library which should help nail the remaining bug(s). As mentioned above, during this time, Andrew will be finalising his RFC, after which he should be well placed to join Spandan and Fraser in the Routing bughunt.
Website (@Scott)
I’d first like to say Hi! 
This is my first update here and is probably the first time many of you have heard from me. My name’s Scott and I’m the UI Designer here at MaidSafe.
I don’t know how much you guys know about the new websites, but the plan for MaidSafe’s web presence is to have two connected websites; one for consumers and the other for developers. The consumer site is the one we’ve been working to get out first. The objectives of this site is to capture new visitors, get them up to speed on the project and allow them to easily join the network when launched. A lot of the design work for this site is almost complete and I’ve been working with Shankar to get it implemented. Over the next few weeks we’ll have the site ready and will launch it soon after!
Overall we obviously have another very busy week ahead of us. We are hopeful that we can quickly find and fix the bugs in the networking layers that will allow us to launch the network on droplets and release the deliverables of the last sprint. While we have a reduced team working this week, we do have MaidSafe’s most experienced heads giving this 100% of their time, so we are optimistic about resolving the issues as quickly as possible.
While we are very focussed on fixing the issues that are stopping us from getting the network up and running, the amount achieved by the core team in the past few weeks and months should not be overlooked. Once we have a strong and reliable network in place we will be able to move forward confident that we are building all the exciting new features on a very solid platform. The community support we continue to receive is nothing short of amazing and is a real motivation for the entire team, we are now getting very close and the future looks very bright for the SAFE Network and it’s amazing community.
Here is the weekly dev update
