Summary
Here are some of the main things to highlight this week:
- @povilasb arrived in the office today and will be spending a couple of weeks working closely with Spandan and Nikita on Crust.
- The Crust test will be open to the community next week.
- Progress on PARSEC milestone 2 is continuing with the malice handling tasks.
- The SAFE Client Libs team is working on detecting mock authentication requests so that the Authenticator returns an error if an app built for the mock version of the network sends a request.
- The MaidSafe fork of Peruse will now be known as SAFE Browser.
Marketing
This week we’ve been focused on working through the communications around two areas - the road to Alpha 3 and the upcoming release of the Crust Test. That has involved writing content for various Medium blog posts and creating Crust reference material for the DevHub website. In addition, we’ve also been working on the help documentation so that those who want to get involved with the Crust test have the smoothest possible experience.
The Crust test will be going public next week and once again we would really appreciate your help in running the Crust binaries we put out to help us understand how successful our networking library is at connecting peers. Along with the test, we will also be including a dashboard that will display the connection attempts and provide our engineers with real-world experience that will be extremely useful moving forward. As mentioned previously this will be the first of several releases we have planned so it looks like being an exciting time with plenty of new SAFE toys to play with.
Recruitment
Yet again, all those involved in recruitment are being kept busy this week.
Marketing Strategist - @dugcampbell and @victoria have now completed all of the 2nd stage interviews for this role and they have now shortlisted the candidates for the final interview.
Executive Assistant - @Victoria has created a shortlist of potentially suitable candidates for this role from the applications received. She has started to conduct initial telephone interviews and is looking to conduct 2nd stage interviews this week.
Rust Engineer - as mentioned last week, we offered a candidate the role of Rust Engineer with the Routing Team and we can now confirm that he will commence employment with us on November 1 
Network Engineer - the team here and in Chennai are continuing to look for this elusive engineer and we will update you on this when there has been some progress.
Assistant Manager - we have started to receive some CVs for this role and on Friday @krishna, @nadia and @victoria will conduct the first couple of interviews for the role.
Software Test Engineer - unfortunately, we are not any further forward with this role than we were last week. This role has been more challenging than initially anticipated. Finding Test Engineers who have experience with writing automated test scripts and who are willing to travel outside the cities for work has been difficult, but we’ll persevere until we find the best candidate.
In other news, @povilasb arrived in the office today and will be spending a couple of weeks working with the team here at HQ. Welcome back Povilas :flag-scotland:
@victoria is away next week for a holiday in the 
but fear not another member of the team will pick up the recruitment update in her absence.
User Experience
This week @Shankar joined back the team after his wedding celebration. The Crust Testnet analytics dashboard is close to completion, and @JimCollinson is working closely with the Front-end and Crust teams in updating/enhancing its UX.
SAFE API & Apps
The MaidSafe fork of Peruse will now be known as SAFE Browser. Several enhancements have been made to stabilise the browser and to give a user experience that may be expected from other browsers. Even for the smallest of enhancements, much of our time is spent on developing a comprehensive test suite in order to assist in the process of stabilising SAFE Browser and to prevent potentially breaking changes in the future.
This last week has seen the addition of some much-needed end-to-end test suites, checking the ability to create accounts and save/receive data from the network. As well as adding in checks that this data cannot be accessed by another account.
We have completed the getting started guides for developing Java apps for SAFE and they are under review. We are now looking into improving our packaging and release process to help developers quickly get the safe_app library included in their development environment.
@happybeing has voiced his concerns about our engagement with the SOLID community in this post. Mark has made a really good point here and we will be stepping up our engagement with the SOLID team in the coming weeks. Both technologies complement each other extremely well and we are therefore really keen to maintain our collaboration as we believe it benefits both projects. This issue highlights our need to have better systems in place to ensure we are engaging sufficiently with third party developers, many thanks for the kick up the bum, Mark!
SAFE Client Libs
This week @marcin has been finishing up the move to case insensitive encodings for authorisation URIs, which involved writing some tests after @nbaksalyar did the initial implementation. This will be a breaking change, as the new version of the authenticator will be able to decode requests from old apps but it won’t encode responses using the old encoding. We also worked on detecting mock authentication requests so that the Authenticator returns an error if an app built for the mock version of the network sends a request.
Routing
The Routing team is continuing to implement the detection of various kinds of malice and writing functional tests for these scenarios. We’ve made good progress through the initial tranche of tasks, with several having been completed, and work ongoing for handling and testing more complex cases such as forks and invalid accusations of malice.
One of the larger parts that got completed this week is keeping track of peer lists of the other peers in the section. This will enable us to reliably judge whether all peers only accept events from valid senders and is an important piece in the whole malice detection picture.
It’s a strange phenomenon that much of the production code we’re writing here is designed to deter malicious users from ever calling it. For example, the fact that we detect and kick out a node which gossips a forked event means a hacker will see that it is futile to write an attack which creates such a fork, hence our fork-handling code should probably never be executed.
Crust
We’re continuing to work on bug fixes and tests for the NAT traversal. We have built a special version of the test binary to use the original P2P crate and we are comparing it against the newer P2P implementation. We have found some bugs in the bootstrapping process: as we’ll be using the same approach we used for Alpha 2 (i.e. registering on the invite server with your forum account to participate in the test), it requires to have a list of allowed IPs. Currently, the bootstrapper doesn’t work as expected though, and we’re trying to investigate the cause of it.
files:
) along with looking into its performance and possible optimisations.
